본문 바로가기

자격증

AWS SAA-C03 Dump 601-650

by 천뱅 2026. 2. 3.

AWS SAA-C03 Dump 601-650

Answer: B

요구사항
환경: Amazon RDS for PostgreSQL에서 중요 DB 운영
목표: Amazon Aurora PostgreSQL로 마이그레이션
제약: 가동 중지 시간과 데이터 손실 최소화
조건: 최소한의 운영 오버헤드로 위를 충족

B. RDS for PostgreSQL에서 Aurora 읽기 전용 복제본 생성 후, 해당 복제본을 새 Aurora PostgreSQL DB 클러스터로 승격
연속 복제: RDS PostgreSQL에서 Aurora 읽기 전용 복제본을 만들면 지속적으로 복제되므로, 승격 시점까지 데이터 손실을 최소화할 수 있음.
다운타임 최소: 애플리케이션을 RDS에서 Aurora로 전환하는 순간만 중단하면 되고, 스냅샷·덤프·복원 구간 동안의 긴 중단이 필요 없음.
운영 부담 최소: 복제본 생성 → 동기화 대기 → 승격(Promote) → 앱 연결 변경만 하면 되고, pg_dump·S3·스크립트 등 추가 작업이 적음.
표준 패턴: RDS PostgreSQL → Aurora 마이그레이션 시 읽기 복제본 생성 후 승격이 AWS에서 권장하는 방식임.

틀린 이유
A. RDS PostgreSQL DB 스냅샷을 만들어 새 Aurora 클러스터를 채우는 방식은, 스냅샷 생성·복원 시간 동안 애플리케이션 중단이 길어지고, 스냅샷 시점 이후 데이터는 손실되거나 추가 작업이 필요함. “다운타임·데이터 손실 최소”에는 B(복제본 후 승격) 가 더 적합함.
C. S3 데이터 가져오기로 마이그레이션하려면 내보내기 → S3 → 가져오기 단계가 필요하고, 그 동안 중단 시간이 길어지며 운영 단계도 많아져 “최소 운영·최소 다운타임” 요구를 충족하기 어려움.
D. pg_dump로 백업 후 Aurora에 복원하는 방식은 덤프·전송·복원 시간만큼 긴 다운타임이 발생하고, 일관된 백업을 위해 쓰기 중단이 필요할 수 있어, “다운타임·데이터 손실 최소”에는 B(복제본 후 승격) 가 더 적합함.

Answer: C

요구사항
환경: Amazon EBS를 쓰는 수백 대 Amazon EC2 인스턴스
목표: 재해 발생 후 모든 EC2 인스턴스를 복구할 수 있어야 함
제약: 위를 최소한의 노력으로 만족

C. AWS Backup으로 EC2 인스턴스 그룹 전체에 대한 백업 계획 설정, 복원 시 AWS Backup API/CLI로 다수 EC2 복원 속도 향상
한 번에 백업 계획: AWS Backup에서 백업 계획을 만들고, 태그 또는 리소스 ID로 EC2(및 EBS) 를 대상에 포함하면, 한 계획으로 수백 대 EC2를 자동 백업할 수 있음.
최소 노력: 스냅샷·AMI를 직접 스크립트로 돌리지 않고 관리형 서비스로 백업·보존 주기·리전 복사 등을 설정만 하면 됨.
대량 복원: 재해 후 AWS Backup API 또는 CLI로 여러 리소스를 한꺼번에 복원하거나 자동화할 수 있어, 수백 대 복구 속도를 높일 수 있음.
EC2 복구: AWS Backup은 EC2에 연결된 EBS를 백업하고, 복원 시 새 EBS·EC2(AMI 기반) 복구를 지원해 “모든 EC2 인스턴스 복구” 요구를 충족함.

틀린 이유
A. 인스턴스마다 EBS 스냅샷을 수동/스크립트로 관리하고, CloudFormation으로 복원하려면 수백 대 기준으로 템플릿·스냅샷 ID 관리가 복잡해지고, “최소한의 노력”에는 AWS Backup(C) 이 더 적합함.
B. Elastic Beanstalk은 애플리케이션 배포용이며, 수백 대 EC2의 재해 복구·EBS 스냅샷 기반 복원 워크플로를 제공하지 않음.
D. Lambda로 스냅샷·AMI 복사와 복원을 구현하면 개발·유지보수 부담이 커지고, “최소한의 노력”에는 관리형 AWS Backup(C) 이 더 적합함.

Answer: B

요구사항
환경: AWS로 마이그레이션한 회사
목표: 반구조화 데이터의 대규모 병렬·주문형 처리를 위한 서버리스 솔루션
데이터: Amazon S3에 저장된 로그, 미디어, 판매 거래, IoT 센서 데이터
처리: 데이터 세트의 수천 개 항목을 병렬로 처리
제약: 위를 가장 운영 효율적으로 만족

B. AWS Step Functions 맵 상태를 분산 모드로 사용해 데이터를 병렬 처리
분산 모드: 맵 상태를 분산 모드로 두면 항목마다 자식 실행을 생성해, 수천 개 항목을 병렬로 처리할 수 있음. 인라인 모드는 동시 분기 수 제한(예: 40)이 있어 수천 개에는 부적합함.
서버리스: Step Functions + Lambda(또는 기타 통합)로 클러스터·서버 없이 주문형 병렬 처리가 가능함.
운영 효율: 오케스트레이션·재시도·상태 관리를 Step Functions가 담당해, 직접 큐·워커·스케줄러를 만들 필요가 없음.
S3 연동: S3 객체 목록을 입력으로 받아 맵으로 넘기거나, 이벤트 기반으로 Step Functions를 시작하는 등 S3 데이터와 연동 가능함.

틀린 이유
A. 맵 상태 인라인 모드는 동일 실행 내에서만 분기를 돌리므로 동시 병렬 수에 제한이 있고, 수천 개 항목을 효율적으로 병렬 처리하기에는 분산 모드(B) 가 맞음.
C. AWS Glue는 배치 ETL용이라, “주문형·수천 항목 병렬”을 서버리스 오케스트레이션으로 처리하는 용도에는 Step Functions 맵 분산 모드(B) 가 더 적합하고, 운영 효율 측면에서도 B가 요구사항에 맞음.
D. Lambda 여러 개로 병렬 처리할 수는 있으나, 수천 개 항목을 누가 오케스트레이션할지(호출·재시도·완료 추적)를 직접 구현해야 함. Step Functions 맵(B) 이 이 오케스트레이션을 관리해 운영 효율이 더 큼.

Answer: D

요구사항
데이터: 10PB를 Amazon S3로 마이그레이션
기한: 6주
네트워크: 데이터 센터 인터넷 업링크 500Mbps, 다른 온프레미스 앱과 공유
제약: 이 일회성 마이그레이션에 인터넷 대역폭의 80%만 사용 가능 → 실질 400Mbps

D. AWS Snowball 디바이스를 여러 대 주문 → 데이터를 디바이스에 복사 → AWS로 반송 후 S3에 적재
인터넷으로는 불가: 400Mbps로 6주(약 362만 초) 전송 시 이론상 약 181TB 수준. 10PB(10,000TB) 를 6주 안에 인터넷으로 올리는 것은 불가능에 가깝다.
오프라인 전송: Snowball(또는 10PB 규모면 Snowmobile)으로 데이터를 물리 디바이스에 복사한 뒤 AWS로 배송하면, 인터넷 대역폭 제한을 받지 않는다.
6주 내 완료: 여러 Snowball을 동시에 채우고 순차 배송·적재하거나, 10PB 단일 이전이면 Snowmobile 한 대로 계획하면 6주 일정에 맞출 수 있다.
공유 링크 보호: 마이그레이션 트래픽이 인터넷을 거의 쓰지 않아, 다른 온프레미스 애플리케이션의 업링크 사용에 영향을 주지 않는다.

틀린 이유
A. AWS DataSync는 네트워크(인터넷 또는 Direct Connect) 로 전송하므로, 실질 400Mbps 제한이 그대로 적용된다. 10PB를 6주 안에 올리는 것은 불가능하다.
B. rsync로 S3에 직접 전송해도 인터넷을 사용하므로, 400Mbps 제한으로 10PB·6주 요구사항을 충족할 수 없다.
C. AWS CLI와 여러 복사 프로세스도 인터넷 전송이므로, 대역폭 제한이 동일해 10PB·6주 조건을 만족할 수 없다.

Answer: D

요구사항
환경: 온프레미스 iSCSI 네트워크 스토리지 서버 여러 대
목표: AWS로 전환해 온프레미스 서버 수 감소
제약: 자주 쓰는 데이터에 대해 짧은 대기 시간 제공, 인프라 변경 최소로 온프레미스 서버 의존도 감소

D. 캐시된 볼륨(Cached Volume)으로 구성한 AWS Storage Gateway 볼륨 게이트웨이 배포
iSCSI 유지: Volume Gateway는 iSCSI 볼륨을 온프레미스에 노출하므로, 기존 iSCSI 사용 앱·서버를 그대로 두고 최소 인프라 변경으로 전환할 수 있음.
자주 쓰는 데이터 저지연: 캐시된 볼륨은 전체 데이터는 S3에 두고, 자주 접근되는 데이터만 Gateway 로컬 디스크에 캐시함. 따라서 자주 사용하는 데이터는 로컬 캐시에서 읽어 짧은 대기 시간을 제공함.
온프레미스 의존 감소: 주 데이터는 S3(클라우드) 에 있으므로, 온프레미스는 Gateway + 캐시만 두면 되어 스토리지 서버 수를 줄일 수 있음.
Stored Volume과 구분: Stored Volume(C)은 전체 데이터가 온프레미스에 있어 의존도가 크고, Cached Volume(D)은 데이터는 S3, 캐시만 온프레미스라 요구사항에 맞음.

틀린 이유
A. S3 File Gateway는 NFS/SMB 파일 공유용이며, iSCSI(블록) 를 제공하지 않음. 기존 iSCSI 앱을 그대로 쓰려면 Volume Gateway(D) 가 필요하고, “최소 인프라 변경”에는 D가 맞음.
B. EBS는 AWS 내부에서만 붙일 수 있어, 온프레미스에서 iSCSI로 그대로 접근할 수 없음. 온프레미스 iSCSI 의존을 줄이면서 iSCSI 인터페이스를 유지하려면 Volume Gateway(D) 가 맞음.
C. Stored Volume은 전체 데이터를 온프레미스에 두고 S3는 백업/스냅샷용이라, “온프레미스 서버 의존 감소” 요구를 충족하지 못함. Cached Volume(D) 이 데이터를 S3에 두고 캐시만 온프레미스에 두어 의존도를 줄임.

Answer: B

요구사항
기능: 비즈니스 사용자가 Amazon S3에 객체 업로드
내구성: 객체 내구성을 극대화
가용성: 객체는 언제든지 쉽게 사용 가능해야 함
접근 패턴: 업로드 후 처음 30일은 자주 접근, 30일 초과 객체는 접근 가능성 낮음
목표: 위를 가장 비용 효율적으로 만족

B. 모든 객체를 S3 Standard에 저장하고, 30일 후 S3 Standard-IA로 전환하는 수명 주기 규칙 사용
내구성 극대화: S3 Standard와 S3 Standard-IA 모두 11 nines 내구성, 다중 AZ로 동일한 수준의 내구성을 제공함.
언제든 사용 가능: Standard·Standard-IA 모두 즉시 조회 가능(복원 대기 없음). “언제든지 쉽게 사용” 요구를 충족함.
비용 효율: 처음 30일은 자주 접근하므로 Standard 유지, 30일 이후는 접근이 적으므로 Standard-IA로 전환해 저장 비용을 줄임.
수명 주기: S3 수명 주기 규칙으로 30일 후 Standard-IA 전환만 설정하면 되고, 운영 부담이 적음.

틀린 이유
A. S3 Glacier로 전환하면 검색(Retrieval) 이 필요해 수 분~수 시간이 걸릴 수 있음. “객체는 언제든지 쉽게 사용할 수 있어야 함” 조건을 Glacier는 충족하지 못함.
C. S3 One Zone-IA는 단일 AZ 저장이라 다중 AZ 대비 내구성이 낮음. “객체 내구성을 극대화” 요구에는 다중 AZ인 Standard-IA(B) 가 맞음.
D. S3 Intelligent-Tiering에 모두 넣고 30일 후 Standard-IA로 전환하는 구성은, Intelligent-Tiering 모니터링 비용이 발생하고, “처음 30일은 자주 접근” 패턴에는 Standard → 30일 후 Standard-IA(B) 가 더 단순하고 비용 효율적임.

Answer: C

요구사항
환경: 온프레미스 → AWS로 2계층 애플리케이션 마이그레이션
데이터 계층: Amazon RDS for Oracle 다중 AZ, 12TB 범용 SSD(EBS)
애플리케이션: 평균 6MB BLOB로 문서를 DB에 저장·처리
문제: DB 크기 증가 → 성능 저하, 스토리지 비용 증가
목표: DB 성능 개선, 가용성·탄력성 확보, 가장 비용 효율적으로 만족

C. Amazon S3 버킷 생성, 앱은 문서를 S3에 저장하고 기존 DB에는 객체 메타데이터만 저장
BLOB를 DB에서 분리: 문서(대용량 BLOB) 는 S3에 저장하고, 문서 ID·S3 키·메타데이터만 기존 RDS에 두면 DB 크기·I/O가 줄어 성능이 개선됨.
비용 효율: 대용량 바이너리를 S3에 두면 RDS 스토리지보다 저렴하고, “가장 비용 효율적” 요구에 맞음.
가용성·탄력성: S3는 고가용·내구성과 용량 탄력성을 제공하고, RDS 다중 AZ는 메타데이터만 담당해 유지 가능함.
최소 변경: Oracle 스키마·트랜잭션 모델은 유지하고, 저장 위치만 BLOB → S3, 메타데이터 → DB로 바꾸면 됨.

틀린 이유
A. 인스턴스 축소 + 스토리지 24TiB + 마그네틱은 성능을 악화시키고, BLOB가 DB에 그대로 있어 근본 원인을 해결하지 못함. “비용 효율”도 마그네틱·대용량 RDS 스토리지로는 달성하기 어려움.
B. 인스턴스 확대 + 24TiB + 프로비저닝된 IOPS는 비용이 크게 증가하고, BLOB를 계속 DB에 두면 성능·비용 문제가 반복됨. “가장 비용 효율적”이 아님.
D. DynamoDB는 아이템당 400KB 제한이 있어 6MB BLOB를 그대로 넣을 수 없고, BLOB는 결국 S3 등에 두어야 함. Oracle 전체를 DMS로 DynamoDB로 옮기는 것은 변경 범위·비용이 크고, “BLOB 분리 + 기존 DB로 메타데이터”인 C가 더 비용 효율적이고 적합함.

Answer: A

요구사항
환경: 전 세계 20,000개 이상 소매점에 서비스, ALB 뒤 EC2에서 HTTPS(443) 제공
통신: 소매점이 공용 인터넷으로 웹 앱 접근, 각 소매점이 현지 ISP가 할당한 IP를 등록 가능
보안 요구: 등록된 IP 주소로만 접속을 제한해 엔드포인트 보안 강화
목표: 위를 만족하는 설계

A. ALB에 AWS WAF 웹 ACL 연결, IP 규칙 세트로 트래픽 필터링, 등록된 IP만 허용하도록 규칙 업데이트
WAF = IP 기반 필터링: AWS WAF의 IP Set에 등록된 소매점 IP를 넣고, 해당 IP에서 오는 요청만 허용(또는 나머지 차단)하는 규칙을 두면, ALB 앞단에서 등록 IP만 통과시킬 수 있음.
ALB 연동: 웹 ACL을 ALB에 연결하면, ALB로 들어오는 HTTPS(443) 트래픽이 WAF를 먼저 거쳐 IP 규칙으로 필터링됨.
규모 대응: WAF IP Set은 많은 IP를 지원하므로, 수천~수만 개 소매점 IP 등록이 가능함. NACL은 규칙 수 제한(예: 20개)이 있어 수만 개 IP에는 부적합함.
운영: 소매점 IP가 바뀔 때 IP Set만 갱신하면 되고, ALB·EC2 구조는 그대로 둠.

틀린 이유
B. Firewall Manager는 여러 계정/리소스에서 WAF·방화벽 규칙을 중앙 관리하는 용도이며, “등록 IP만 허용”이라는 규칙 내용은 WAF(A) 에서 정의함. 단일 ALB에 IP 제한만 두는 경우 WAF 웹 ACL(A) 를 ALB에 붙이는 것이 직접적인 방법임.
C. ALB에는 Lambda 권한 부여자(Lambda authorizer) 가 없음. Lambda 권한 부여자는 API Gateway 기능이라, ALB 앞단에서 “요청 IP 검사”를 Lambda로 하려면 구조 변경(API Gateway 추가 등)이 필요하고, IP 기반 제한에는 WAF(A) 가 적합함.
D. NACL은 규칙 수 제한(예: 인바운드 20개 등)이 있어 20,000개 이상 소매점 IP를 각각 규칙으로 넣을 수 없고, NACL만으로 “등록된 IP만 허용”을 구현하는 것은 확장성에서 맞지 않음. WAF IP Set(A) 가 맞음.

Answer: B

요구사항
환경: AWS Lake Formation으로 데이터 분석 플랫폼 구축
데이터: Amazon S3, Amazon RDS 등 다양한 소스에서 수집
보안 요구: 중요/민감 정보가 포함된 데이터 일부에 대한 접근을 차단하는 보안 솔루션 필요
목표: 위를 만족하는 방식

B. 데이터 필터를 만들어 행 수준 보안·셀 수준 보안 적용
행 수준 보안(Row-level): Lake Formation 데이터 필터로 “특정 조건을 만족하는 행만 허용”하도록 설정하면, 사용자·역할별로 접근 가능한 행을 제한할 수 있음. 민감한 행은 조건에서 제외해 접근을 막을 수 있음.
셀 수준 보안(Cell-level): 열(컬럼) 단위로 접근을 제한하거나 마스킹하면, 민감한 열(예: PII)만 차단하고 나머지 데이터는 분석에 사용할 수 있음.
Lake Formation 네이티브: 데이터를 삭제하지 않고 접근 제어만으로 “민감한 부분에 대한 접근 방지”를 구현하는 표준 방식임.
세밀한 제어: IAM 역할만으로는 “테이블 전체 허용/거부” 수준이지만, 데이터 필터(B) 로 행·열 단위 제어가 가능함.

틀린 이유
A. IAM 역할로 Lake Formation 테이블 접근 권한을 주면 테이블 단위 허용/거부만 가능하고, 특정 행·열(민감한 부분) 만 차단하는 세밀한 제어는 할 수 없음. “데이터 일부에 대한 접근 방지”에는 데이터 필터(B) 가 맞음.
C. Lambda로 수집 전 민감 정보 제거는 원본/수집 데이터를 변경하는 방식이라, (1) 해당 데이터가 필요한 정당한 접근까지 불가능해지고, (2) Lake Formation의 접근 제어(데이터 필터) 로 해결하는 B가 더 적합함.
D. Lambda로 주기적으로 쿼리해 민감 정보 제거도 데이터 삭제에 가깝고, 권한이 있는 사용자도 해당 데이터를 쓸 수 없게 됨. “접근 방지”는 데이터 필터(B) 로 구현하는 것이 맞음.

Answer: B

요구사항
환경: VPC 내 Amazon EC2 배포, EC2가 소스 데이터를 Amazon S3에 적재 후 처리
규정: 데이터가 공용 인터넷을 통해 전송되면 안 됨
추가: 온프레미스 데이터 센터 서버가 EC2 애플리케이션 출력 사용
목표: 위를 만족하는 솔루션

B. Amazon S3용 게이트웨이 VPC 엔드포인트 배포, 온프레미스와 VPC 간 AWS Direct Connect 구성
EC2 ↔ S3(공용 인터넷 미경유): S3용 게이트웨이 VPC 엔드포인트를 VPC에 두면, EC2에서 S3로 가는 트래픽이 인터넷 게이트웨이를 타지 않고 AWS 내부 네트워크로만 전달됨. 따라서 “데이터가 공용 인터넷을 통해 전송되지 않음”을 만족함.
온프레미스 ↔ VPC(공용 인터넷 미경유): AWS Direct Connect로 온프레미스와 VPC를 전용 회선으로 연결하면, 온프레미스 서버가 EC2 출력을 받는 트래픽이 공용 인터넷을 거치지 않고 전용 링크로 전달됨.
규정 준수: S3 적재·조회와 온프레미스–EC2 간 데이터가 모두 공용 인터넷을 통과하지 않으므로 규정 요구를 충족함.

틀린 이유
A. EC2용 인터페이스 VPC 엔드포인트는 EC2 제어 API(DescribeInstances 등)용이며, S3로 데이터를 적재/조회하는 트래픽과는 무관함. S3 트래픽이 공용 인터넷을 타지 않게 하려면 S3용 VPC 엔드포인트(B) 가 필요함.
C. Transit Gateway는 VPC–VPC, VPC–온프레미스(VPN/DX) 연결용이며, S3 버킷으로의 연결을 제공하지 않음. VPC에서 S3 접근은 S3 VPC 엔드포인트로 해야 하고, Site-to-Site VPN은 터널이 공용 인터넷 위에 있어 “공용 인터넷 미경유” 규정과 맞지 않을 수 있음.
D. NAT 게이트웨이를 통해 S3에 접근하면 트래픽이 인터넷 게이트웨이와 공용 인터넷을 경유하므로, “데이터가 공용 인터넷을 통해 전송되지 않아야 함”이라는 규정을 충족하지 못함. S3 접근은 게이트웨이 VPC 엔드포인트(B) 로 해야 함.

Answer: A

요구사항
환경: REST 기반으로 제3자 공급업체에서 거의 실시간 데이터 수신, 수신 후 처리·저장해 분석
현재: Amazon EC2에서 애플리케이션 실행
문제: 타사가 데이터를 보낼 때 503 Service Unavailable 다수 발생. 데이터 볼륨 급증 시 컴퓨팅 한도에 걸려 모든 요청 처리 불가
목표: 더 확장 가능한 솔루션 설계

A. Amazon Kinesis Data Streams로 데이터 수집, AWS Lambda로 처리
수집·처리 분리: 타사 데이터를 Kinesis Data Streams로 먼저 수집(버퍼) 하고, Lambda가 스트림에서 읽어 처리·저장하면, 수신 단과 처리 단이 분리되어 503을 줄일 수 있음.
버퍼링: 볼륨이 급증해도 스트림에 적재만 되고, 수신 API는 즉시 응답할 수 있어, EC2가 꽉 찼을 때의 503을 피할 수 있음.
확장성: Kinesis는 샤드 수로 수집 용량을 늘리고, Lambda는 동시 실행 수가 자동으로 늘어나 처리가 스케일됨. “데이터 볼륨 급증”에 대응하기 좋음.
거의 실시간: 스트림 수집 + Lambda 트리거로 초 단위 처리 가능해 “거의 실시간” 요구를 만족함.

틀린 이유
B. API Gateway + 사용량 계획·할당량은 요청을 제한하는 용도라, 볼륨 급증 시 거절(429/503) 이 늘어날 수 있음. “확장 가능한 솔루션”이 아니라 부하 제한에 가깝고, 수집 버퍼 + 처리 스케일(A) 이 더 적합함.
C. SNS로 수신하고 ALB + EC2 Auto Scaling으로 처리하면, EC2 스케일 아웃 지연 동안에는 여전히 처리 지연·실패가 날 수 있고, 버퍼가 없어 503을 근본적으로 줄이기 어렵음. Kinesis + Lambda(A) 가 수집 버퍼·처리 확장 측면에서 더 나음.
D. ECS + Auto Scaling으로 컨테이너를 늘려도, 요청-응답 구조가 그대로라 스케일 아웃 전에 한도에 걸리면 503이 발생할 수 있음. 수집을 스트림으로 버퍼링하고 처리만 스케일(A) 하는 설계가 “확장 가능” 요구에 더 맞음.

Answer: D

요구사항
프라이빗 서브넷의 EC2에서 애플리케이션 실행
Amazon S3 버킷의 민감한 정보 처리
S3 버킷 접근 시 인터넷을 사용하지 않아야 함

D. VPC 엔드포인트(Gateway Endpoint for S3) 구성 후, S3 버킷 정책에서 해당 엔드포인트만 허용하고, 애플리케이션은 기존 S3 엔드포인트 그대로 사용(코드 변경 최소화).
VPC 엔드포인트(S3 Gateway Endpoint)는 VPC와 S3 간 트래픽을 퍼블릭 인터넷이 아닌 AWS 내부 네트워크로만 전달합니다.
프라이빗 서브넷 라우팅 테이블에 S3 접두사(prefix)에 대한 대상으로 VPC 엔드포인트를 지정하면, EC2 → S3 트래픽이 인터넷/IGW/NAT를 거치지 않고 AWS 백본으로만 이동합니다.
S3 버킷 정책에서 특정 VPC·VPC 엔드포인트에서의 액세스만 허용할 수 있어, 민감 데이터에 대한 접근 제어와 규정 준수에 적합합니다.
별도 NAT, VPN, 인터넷 게이트웨이가 필요 없고, 애플리케이션은 기존 S3 API/엔드포인트 주소를 그대로 사용할 수 있습니다.

틀린 이유
A. 인터넷 게이트웨이는 VPC를 퍼블릭 인터넷에 붙이는 것이므로, S3 접근도 인터넷을 경유하게 되어 “인터넷 미사용” 요구에 맞지 않습니다.
B. VPN은 주로 온프레미스–VPC 연결용이며, S3로 가는 트래픽이 VPN 터널 밖으로 나가면 여전히 인터넷을 사용할 수 있어, “인터넷 미사용”을 보장하는 직접적인 방법이 아닙니다.
C. NAT 게이트웨이는 프라이빗 서브넷의 아웃바운드를 퍼블릭 IP로 인터넷에 나가게 하므로, S3 접근도 인터넷을 경유하게 되어 요구사항을 충족하지 못합니다.

Answer: B

요구사항
Amazon EKS에서 컨테이너 애플리케이션 실행
Kubernetes Secret 객체에 민감 정보 저장
해당 정보가 암호화되었는지 확인하고 싶음
최소한의 운영 오버헤드로 위 요구사항 충족

B. EKS 클러스터에서 AWS KMS를 이용한 비밀(Secrets) 암호화를 활성화한다.
EKS의 Secrets 암호화(Secrets encryption) 기능을 사용하면, 클러스터의 Kubernetes Secret이 etcd에 저장될 때 KMS CMK로 암호화됩니다.
클러스터 생성 시 또는 기존 클러스터 설정에서 한 번 활성화하면 되며, 애플리케이션은 기존처럼 Kubernetes Secret API만 사용하면 됩니다.
애플리케이션 코드 변경·추가 서비스 연동·Lambda/Parameter Store 도입 없이, EKS와 KMS만으로 “비밀 객체가 암호화되어 있는지” 요구사항을 충족할 수 있어 운영 오버헤드가 가장 적습니다.

틀린 이유
A. 컨테이너 애플리케이션에서 직접 KMS를 호출해 암호화하면, 모든 관련 앱을 수정·배포하고 키 사용 로직을 유지보수해야 하므로 운영 부담이 큽니다.
C. Lambda로 암호화를 처리하는 방식은 Lambda 개발·배포·모니터링이 추가되고, EKS의 Secret 객체를 저장소(etcd) 수준에서 암호화하는 기본 기능을 대체하지 못해 “최소 오버헤드”에 맞지 않습니다.
D. Parameter Store는 별도 서비스이며, EKS의 Kubernetes Secret 객체 자체를 암호화하는 기능이 아닙니다. 앱을 Parameter Store 조회 방식으로 바꿔야 해서 변경 범위와 운영 부담이 커집니다.

Answer: D

요구사항
웹·앱 서버: EC2 + Auto Scaling 그룹
데이터: Amazon RDS
웹 서버만 애플리케이션 서버에 접근할 수 있도록 제한

D. 애플리케이션 서버 ASG를 대상 그룹으로 하는 ALB를 두고, 보안 그룹으로 웹 서버만 앱 서버에 접근하도록 구성한다.
ALB를 앱 서버 ASG 앞에 두면, 웹 서버는 ALB의 DNS/주소로만 요청을 보내고, ALB가 앱 서버로 분산합니다.
보안 그룹으로 “웹 서버만 앱 서버에 접근”을 구현할 수 있습니다. 앱 서버(또는 ALB) 인바운드에 웹 서버 보안 그룹을 소스로 허용하면, 해당 SG를 가진 인스턴스(웹 서버)만 트래픽을 보낼 수 있습니다.
보안 그룹은 인스턴스/ENI 단위이고 상태 저장(stateful)이라, IP가 바뀌어도 웹 서버 SG만 허용하는 규칙이 유지됩니다. ALB는 HTTP/HTTPS 웹·앱 계층에 일반적으로 사용되는 구성입니다.

틀린 이유
A. PrivateLink는 다른 VPC나 고객에게 서비스를 비공개로 노출할 때 쓰는 구성입니다. 같은 VPC 안에서 웹 계층만 앱 계층에 접근하게 하는 용도가 아니며, NACL은 서브넷·IP 기준이라 “웹 서버 보안 그룹만 허용”처럼 인스턴스 단위로 제한하기엔 보안 그룹이 더 적합합니다.
B. VPC 엔드포인트는 S3·DynamoDB 같은 AWS 서비스 API용(Gateway/Interface Endpoint)입니다. 우리가 만든 EC2 앱 서버 앞에 “VPC 엔드포인트를 배포한다”는 식의 구성은 해당하지 않습니다.
C. NLB + 대상 그룹 구성은 가능하지만, “웹 서버만 접근”은 NACL이 아니라 보안 그룹으로 하는 것이 적절합니다. NACL은 서브넷·IP 범위 기준이고, 보안 그룹은 소스 보안 그룹으로 웹 서버만 정확히 허용할 수 있어 요구사항에 더 잘 맞습니다.

Answer: D

요구사항
Amazon EKS에서 고객용 중요 애플리케이션 실행
마이크로서비스 아키텍처
중앙에서 애플리케이션 지표·로그를 수집·집계·요약하는 솔루션 필요

D. 기존 EKS 클러스터에 Amazon CloudWatch Container Insights를 구성하고, CloudWatch 콘솔에서 지표와 로그를 본다.
CloudWatch Container Insights는 컨테이너 워크로드(EKS, ECS) 전용으로, 클러스터·노드·파드·컨테이너의 지표와 로그를 자동 수집합니다.
EKS에 Agent(Fluent Bit 등)를 배포해 로그와 메트릭을 CloudWatch로 보내고, 수집·집계·요약된 뷰를 CloudWatch 콘솔(메트릭, 대시보드, Logs Insights)에서 한 곳에서 볼 수 있습니다.
EKS/컨테이너 리소스를 자동 발견하고, CPU·메모리·네트워크·디스크 등 메트릭과 애플리케이션 로그를 함께 다루기에 적합합니다.

틀린 이유
A. CloudWatch 에이전트만 실행하는 것은 수집 수단일 뿐이고, EKS 전체에 대한 자동 발견·집계·요약 기능을 포함한 전체 솔루션은 Container Insights(D)입니다.
B. App Mesh는 서비스 메시(트래픽·보안·일부 메트릭)용이며, EKS 애플리케이션의 지표·로그를 중앙에서 수집·집계·요약하는 전용 솔루션이 아닙니다.
C. CloudTrail은 AWS API 호출 이벤트를 기록하는 서비스로, EKS 파드/앱에서 나오는 애플리케이션 지표·로그를 수집하는 용도가 아닙니다.

Answer: C

요구사항
NLB + Auto Scaling 그룹, S3에 객체 저장
악의적 공격 경험 → 지속 모니터링 필요
모니터링 대상: AWS 계정 내 악의적 활동, 워크로드, S3 버킷 액세스 패턴
의심스러운 활동을 보고하고 대시보드에 표시

C. Amazon GuardDuty를 구성해 결과를 모니터링하고, AWS Security Hub에 보고하도록 한다.
GuardDuty는 위협 탐지 서비스로, AWS 계정·워크로드·S3에 대한 악의적·비정상 활동을 지속적으로 분석합니다.
CloudTrail, VPC Flow Logs, DNS 로그 등으로 계정/워크로드 위협 탐지
S3 데이터 이벤트로 S3 액세스 패턴·의심스러운 접근 탐지
GuardDuty 결과(발견 항목)를 AWS Security Hub로 보내면, Security Hub가 중앙 보안 대시보드에서 GuardDuty·Macie·Inspector 등 여러 소스의 발견 항목을 한곳에 모아 보여 주고, 보고·알림 설정이 가능합니다.

틀린 이유
A. Macie는 S3의 민감 데이터·정책에 초점을 맞춘 서비스로, 계정 전반의 악의적 활동·워크로드 위협을 지속 모니터링하는 용도가 아니며, Config는 구성/컴플라이언스용이라 “의심스러운 활동 대시보드” 요구를 충족하지 못합니다.
B. Inspector는 취약점 스캔(CVE, 패키지 등)용이라, 악의적 활동·S3 액세스 패턴을 지속 모니터링하는 GuardDuty에 비해 요구사항에 덜 부합합니다.
D. Config는 리소스 구성·규칙 준수 모니터링용이며, 악의적 활동·S3 액세스 패턴 탐지가 아니고, EventBridge는 이벤트 라우팅용이라 “대시보드에 정보 표시”를 제공하지 않습니다.

Answer: B, E

요구사항
온프레미스 데이터 센터 → AWS 마이그레이션
NFS 기반 파일 시스템, 200GB 데이터
기존 서비스 중단 없이 데이터 마이그레이션
AWS의 여러 리소스가 NFS 프로토콜로 데이터 접근
가장 비용 효율적인 단계 2개 선택

B. Amazon EFS 파일 시스템을 생성한다.
EFS는 AWS에서 제공하는 관리형 NFS 파일 시스템으로, 여러 EC2·Lambda·온프레미스 등이 NFS 프로토콜로 마운트해 공유 접근할 수 있습니다.
200GB 규모의 일반 파일 공유에는 FSx for Lustre보다 EFS가 더 비용 효율적이며, 다중 AZ·자동 확장을 지원해 마이그레이션 후 NFS 요구사항을 충족합니다.
E. 온프레미스에 AWS DataSync 에이전트를 설치하고, 온프레미스 위치와 AWS 간 DataSync 작업을 사용한다.
DataSync는 온프레미스(NFS/SMB)와 AWS(EFS, S3, FSx 등) 간 지속·증분 복사를 위한 관리형 서비스로, 에이전트 설치 후 소스(온프레미스 NFS) → 대상(예: EFS) 작업을 만들면 됩니다.
초기 전송 후에도 증분 동기화로 “서비스 중단 없이” 마이그레이션하고 컷오버할 수 있어, 수동 복사보다 안전하고 운영 부담이 적습니다. 전송 최적화·압축으로 비용 효율적입니다.

틀린 이유
A. FSx for Lustre는 HPC/대용량 연산용 고성능 파일 시스템으로, 200GB NFS 공유만 필요할 때는 EFS보다 비용이 높아 “가장 비용 효율적”인 조합에 맞지 않습니다.
C. S3는 객체 스토리지로 NFS 프로토콜을 지원하지 않습니다. “NFS로 접근” 요구사항을 충족하려면 EFS(또는 NFS를 제공하는 다른 서비스)가 필요합니다.
D. OS 복사 명령(rsync 등)은 수동·반복 작업이 필요하고, 증분/지속 동기화와 “서비스 중단 최소화” 측면에서 DataSync보다 비효율적이며 비용 효율적인 “관리형” 조합이 아닙니다.

Answer: C

요구사항
us-east-1에서 FSx for Windows File Server(SMB) 사용
RPO 5분 (계획된 유지보수·계획되지 않은 중단)
파일 시스템을 us-west-2로 복제
복제된 데이터는 5년 동안 어떤 사용자도 삭제 불가

C. us-east-1에 다중 AZ FSx for Windows 파일 시스템을 만들고, AWS Backup으로 일일 백업을 us-west-2로 복사하는 백업 계획을 구성한 뒤, us-west-2 대상 볼트에 규정 준수(Compliance) 모드로 Vault Lock을 걸고 최소 보존 기간 5년으로 설정한다.
다중 AZ 배포: FSx for Windows를 다중 AZ로 구성하면 두 AZ에 동기 복제되어, 한 AZ 장애·유지보수 시에도 짧은 RPO로 복구할 수 있어 “5분 RPO” 요구에 부합합니다. 단일 AZ 2는 한 AZ 내 두 서브넷이라 다중 AZ만큼의 복제·장애 조치를 제공하지 않습니다.
AWS Backup + us-west-2 복사: 백업 규칙에서 크로스 리전 복사 대상으로 us-west-2를 지정하면, 백업이 us-west-2로 복제되어 리전 간 복제 요구를 충족합니다.
Vault Lock 규정 준수 모드: 규정 준수(Compliance) 모드로 잠그면 보존 기간 동안 root 포함 어떤 사용자도 잠금 해제·삭제·덮어쓰기를 할 수 없습니다. 거버넌스 모드는 권한이 있는 사용자가 정책을 변경할 수 있어 “5년 동안 어떤 사용자도 삭제 불가”를 보장하지 못합니다.
최소 보존 기간 5년: Vault Lock 최소 보존 기간을 5년으로 설정하면 5년간 삭제·변경이 불가능합니다.

틀린 이유
A. 단일 AZ 2 배포는 다중 AZ가 아니라, 5분 RPO와 계획/비계획 중단 대응에는 다중 AZ가 적합합니다. 규정 준수 모드는 맞습니다.
B. 거버넌스 모드는 권한 있는 사용자가 잠금을 완화할 수 있어, “5년 동안 어떤 사용자도 삭제 불가”를 보장하지 못합니다. 다중 AZ는 맞습니다.
D. 단일 AZ 2는 A와 동일한 이유로 RPO·복제 측면에서 부적합하고, 거버넌스 모드는 B와 동일한 이유로 5년 삭제 방지 요구를 충족하지 못합니다.

Answer: C

요구사항
AWS Organizations로 개발자에게 계정별 개별 AWS 계정 제공
표준 보안 제어 유지
개발자는 자신의 계정에 대해 루트 사용자 수준 액세스
새 개발자 계정에 적용된 필수 CloudTrail 구성이 수정되지 않도록 보장

C. CloudTrail 변경을 금지하는 서비스 제어 정책(SCP)을 만들고, 해당 SCP를 개발자 계정(또는 개발자 OU)에 연결한다.
SCP는 Organizations에서 OU 또는 계정 단위로 적용되며, 해당 계정 내 모든 주체(루트 사용자 포함)에 상한 권한을 적용합니다.
루트 사용자는 IAM 정책으로는 제한할 수 없지만, SCP는 루트를 포함한 계정 전체에 적용되므로, CloudTrail 삭제·수정·이벤트 선택자 변경 등을 Deny하는 SCP를 걸면 개발자 계정의 루트도 해당 CloudTrail 구성을 바꿀 수 없습니다.
그래서 “표준 보안 제어 유지 + 루트급 개발자 계정에서도 필수 CloudTrail이 수정되지 않게” 하려면 SCP로 CloudTrail 변경 금지가 적합합니다.

틀린 이유
A. IAM 정책을 “루트 사용자에게 연결”하는 방식으로는 루트를 제한할 수 없습니다. 루트는 IAM 정책을 우회할 수 있어, 개발자 계정 루트가 CloudTrail을 수정하는 것을 막지 못합니다.
B. 개발자 계정에 조직 추적 옵션으로 새 CloudTrail 추적을 만드는 것은 “추적 존재”만 다루는 것이고, 루트가 그 추적을 삭제·수정하는 것을 막는 메커니즘이 없어 요구사항을 충족하지 못합니다.
D. CloudTrail용 서비스 연결 역할에 “마스터 계정 ARN에서만 변경 허용” 조건을 거는 것은, 누가 CloudTrail을 변경할 수 있는지를 제한하는 것이며, 개발자 계정 내부에서 루트가 CloudTrail을 건드리지 못하게 하는 조직 수준 제어(SCP)와는 다릅니다. 개발자 계정에서의 수정 방지는 SCP로 해야 합니다.

Answer: C

요구사항
AWS에 중요한 애플리케이션 배포
내구성 있는(durable) 스토리지
일관되고 지연 시간이 짧은 성능

C. 프로비저닝된 IOPS SSD(io1/io2) Amazon EBS 볼륨을 사용한다.
프로비저닝된 IOPS SSD EBS(io1/io2)는 IOPS와 처리량을 지정해 사용하는 블록 스토리지로, 일관된·예측 가능한 성능을 제공합니다.
SSD 기반이라 지연 시간이 짧고(보통 1자리 ms 수준), 중요한 DB·I/O 집약 워크로드에 적합합니다.
EBS는 AZ 내 복제로 내구성이 있고, 스냅샷으로 S3에 보관하면 리전 간 복구도 가능해 내구성 요구를 충족합니다.

틀린 이유
A. 인스턴스 스토어는 임시(ephemeral) 스토리지로, 인스턴스 중지·장애 시 데이터가 사라질 수 있어 “내구성 있는 스토리지” 요구에 맞지 않습니다.
B. ElastiCache Memcached는 인메모리 캐시로, 캐시 노드 장애 시 데이터가 유실될 수 있어 “내구성 있는 스토리지”가 아니라 캐시 용도입니다.
D. 처리량 최적화 HDD(st1)는 대용량 순차 I/O·처리량용이라 지연 시간이 높고, “일관되고 지연 시간이 짧은” 성능에는 프로비저닝된 IOPS SSD가 적합합니다.

Answer: A

요구사항
us-west-1 S3 버킷에 사진 저장
모든 새 사진의 사본을 us-east-1에 저장
최소한의 운영 노력으로 충족

A. us-east-1에 두 번째 S3 버킷을 만들고, S3 교차 리전 복제(CRR)로 기존 버킷의 사진을 해당 버킷으로 복제한다.
S3 Cross-Region Replication(CRR)은 리전 간 자동 복제용 관리형 기능으로, 소스 버킷(us-west-1)에 올라온 객체를 대상 리전(us-east-1) 버킷으로 자동 복사합니다.
버전 관리 활성화 후 복제 규칙만 설정하면 새 객체가 자동으로 us-east-1 버킷에 복제되며, Lambda 작성·운영·재시도 로직이 필요 없어 운영 부담이 가장 적습니다.

틀린 이유
B. CORS는 브라우저에서 다른 오리진(도메인)이 버킷에 요청할 수 있게 하는 설정입니다. 리전 간 데이터 복제와는 무관하며, AllowedOrigin에 us-east-1을 넣어도 객체가 us-east-1로 복사되지 않습니다.
C. S3 수명 주기 규칙은 스토리지 클래스 전환(Standard → IA → Glacier) 또는 만료용입니다. 다른 리전의 두 번째 버킷으로 “저장”하는 복제 기능은 없으며, 리전 간 복제는 CRR로 해야 합니다.
D. S3 이벤트로 Lambda를 호출해 복사하는 방식은 Lambda 코드·IAM·에러 처리·재시도 등을 직접 구현·유지해야 해서, CRR 한 번 설정하는 것보다 운영 노력이 훨씬 큽니다.

Answer: A, D

요구사항
구독자용 웹 앱: 정적 단일 페이지 + 영구 DB
트래픽: 아침 4시간은 수백만, 나머지는 수천 (변동 큼)
스키마를 빠르게 발전시킬 수 있어야 함
위를 만족하면서 가장 뛰어난 확장성 (2개 선택)

A. Amazon DynamoDB를 DB로 쓰고, 온디맨드 용량을 사용한다.
DynamoDB는 스키마가 유연해서, 컬럼 추가·변경 시 ALTER TABLE 같은 마이그레이션 없이 속성만 추가해도 되므로 “스키마를 빠르게 발전”에 적합합니다.
온디맨드는 용량을 미리 정하지 않고 트래픽에 맞춰 자동으로 스케일하므로, 아침에 수백만·나머지 시간 수천 명 같은 급격한 변동에도 가장 잘 맞고 확장성이 뛰어납니다.

D. 정적 콘텐츠를 Amazon S3에 두고, S3를 오리진으로 하는 Amazon CloudFront 배포를 만든다.
정적 단일 페이지는 S3 + CloudFront 조합이 표준입니다. S3와 CloudFront가 트래픽에 따라 자동으로 확장되므로 정적 웹에 대한 확장성이 가장 좋습니다.
전 세계 엣지에서 캐시되어 지연 시간이 줄고, 서버(EC2)를 관리할 필요가 없어 운영 부담도 적습니다.

틀린 이유
B. Aurora Serverless도 스케일은 되지만, 관계형 DB라 스키마 변경 시 ALTER TABLE·마이그레이션이 필요해 “스키마를 빠르게 발전”에는 DynamoDB보다 불리합니다. 이 문제의 “DB + 확장성” 요구에는 A가 더 적합합니다.
C. DynamoDB + Auto Scaling(프로비저닝 모드)도 가능하지만, “아침 수백만 / 나머지 수천”처럼 급변하는 트래픽에는 온디맨드(A)가 스파이크를 즉시 받아 주어 확장성 측면에서 더 적합합니다.
E. 정적 콘텐츠를 EC2 + EFS로 서빙하면 인스턴스·ASG·EFS 동기화를 직접 관리해야 하고, S3 + CloudFront(D)보다 확장성과 운영 효율이 떨어집니다.

Answer: B

요구사항
Amazon API Gateway로 타사가 접근하는 REST API 운영
SQL 인젝션(SQLi) 및 크로스 사이트 스크립팅(XSS) 으로부터 API 보호
가장 운영 효율적인 방법으로 충족

B. AWS WAF를 구성해 API Gateway에 연결한다.
AWS WAF는 웹 ACL과 규칙으로 요청 내용(헤더, 쿼리, 바디) 을 검사해, SQL 인젝션·XSS 패턴을 차단할 수 있습니다. AWS 관리형 규칙(AWS Managed Rules, Core Rule Set, Known bad inputs 등)을 쓰면 SQLi/XSS 방어를 바로 적용할 수 있어 운영이 쉽습니다.
WAF는 API Gateway REST API에 직접 Web ACL을 연결할 수 있어, CloudFront를 추가하지 않고 API Gateway만으로도 SQLi/XSS 방어가 가능합니다. 구성 요소가 적어 가장 운영 효율적입니다.

틀린 이유
A. AWS Shield는 DDoS 방어용 서비스입니다. SQL 인젝션·XSS 같은 애플리케이션 계층 공격을 막지 못하므로 요구사항을 충족하지 못합니다.
C. CloudFront 앞에 Shield만 두는 구성은 DDoS 대응용이며, SQLi/XSS 방어 기능은 없어 요구사항을 충족하지 못합니다.
D. CloudFront를 API Gateway 앞에 두고 CloudFront에 WAF를 붙이면 SQLi/XSS 방어는 가능하지만, CloudFront 배포·오리진·캐시 동작 등을 추가로 구성·유지해야 합니다. WAF만 API Gateway에 붙이는 B보다 구성 요소가 많아 “가장 운영 효율적”이라고 보기 어렵습니다.

Answer: D

요구사항
사용자에게 AWS 리소스 액세스 제공
1,500명 사용자, 온프레미스는 Active Directory 사용자 그룹으로 리소스 액세스 관리
사용자가 AWS용으로 별도 ID(계정/비밀번호)를 갖지 않도록 해야 함
온프레미스 액세스는 그대로 두고, 동일한 AD ID로 AWS 액세스도 관리

D. SAML 2.0 기반 페더레이션을 구성하고, 적절한 정책이 붙은 IAM 역할을 만든 뒤, 그 역할을 Active Directory 그룹에 매핑한다.
SAML 2.0 페더레이션을 사용하면 사용자가 기존 AD 계정(또는 AD와 연동된 SSO) 으로 로그인해 AWS에 접근할 수 있습니다. 별도 IAM 사용자나 AWS 전용 비밀번호가 필요 없어 “다른 ID를 유지하지 않는다”는 요구를 충족합니다.
IdP(예: AD FS)가 AD와 연동되어 인증하고, SAML assertion에 AD 그룹 정보를 담아 보냅니다. AWS 측에서는 SAML attribute(그룹) 에 따라 서로 다른 IAM 역할을 부여하도록 매핑하면, “AD 그룹 → AWS 역할”로 권한을 일치시킬 수 있습니다.
온프레미스 리소스는 기존처럼 AD 그룹으로 관리하고, AWS 리소스는 “같은 AD 그룹에 매핑된 IAM 역할”로 관리하는 패턴이 됩니다.

틀린 이유
A. 사용자마다 IAM 사용자를 만들면 1,500개의 별도 AWS ID가 생깁니다. 회사가 원하는 “리소스 액세스를 위해 다른 ID를 유지하지 않는다”는 요구에 맞지 않습니다.
B. Cognito는 주로 고객/앱 사용자(B2C)나 소셜 로그인용이며, 기존 기업 AD 1,500명 + AD 그룹 기반 AWS 역할 매핑에는 AD와 연동된 SAML 페더레이션(D) 이 표준입니다. “AD 그룹에 역할 매핑”도 SAML assertion의 그룹 속성으로 처리하는 방식이 일반적입니다.
C. 교차 계정 역할은 AWS 계정 간 권한 위임용입니다. AD 사용자가 어떤 ID로 로그인해 그 역할을 쓰는지를 해결하지 못합니다. AD 그룹과 역할만 매핑한다고 해도, SAML(또는 유사) 페더레이션이 없으면 사용자가 AD 자격 증명으로 AWS에 로그인할 수 없어 요구사항을 충족하지 못합니다.

Answer: C

요구사항
여러 Application Load Balancer 뒤에서 웹사이트 호스팅
콘텐츠에 대해 지역별로 서로 다른 배포 권한(라이선스·권리) 보유
배포 권한을 위반하지 않고, 사용자에게 해당 지역에 맞는 콘텐츠만 제공

C. Amazon Route 53을 지리적 위치(Geolocation) 라우팅 정책으로 구성한다.
Geolocation 라우팅은 사용자의 지리적 위치(국가·대륙) 에 따라 라우팅합니다. DNS 조회 시 사용자 위치(리졸버/IP 기반)를 기준으로, “미국 → 미국용 ALB”, “유럽 → 유럽용 ALB”, “아시아 → 아시아용 ALB”처럼 지역별로 다른 ALB로 보낼 수 있습니다.
배포 권한이 “지역(국가/대륙)별로 다르다”는 전제에 맞게, 국가·대륙 단위로 명시적으로 어느 ALB로 보낼지 정할 수 있어, “올바른 콘텐츠만 제공하고 배포 권한을 위반하지 않는다”는 요구를 충족합니다.

틀린 이유
A. CloudFront + WAF는 캐시·보안용이며, “지역별 배포 권한에 맞는 ALB로 라우팅”을 하는 기능이 아닙니다.
B. ALB + WAF도 보안용이라, 지역별 권한에 따른 라우팅 요구사항을 해결하지 못합니다.
D. 지리 근접(Geoproximity) 라우팅은 지리적으로 가장 가까운 리소스로 보내는 방식입니다. 권한 경계(국가·지역) 가 아니라 거리/위치 기준이라, 가까운 데이터 센터가 다른 권한 지역일 수 있어 배포 권한을 보장하기 어렵습니다. “지역별 배포 권한”을 지키려면 지리적 위치(Geolocation) 정책이 적합합니다.

Answer: B

요구사항
데이터를 온프레미스에 저장 중, 용량 초과로 증가
온프레미스 → Amazon S3로 마이그레이션
전송 후 데이터 무결성을 자동으로 검증하는 솔루션 필요

B. 온프레미스에 AWS DataSync 에이전트를 설치하고, S3 버킷으로의 온라인 전송을 수행하도록 DataSync 작업을 구성한다.
DataSync는 온프레미스(NFS/SMB)와 AWS(S3, EFS, FSx) 간 자동 데이터 전송 서비스로, 전송 시 체크섬으로 데이터 무결성을 자동 검증합니다.
전송 전후에 소스·대상 데이터를 비교해, 전송 후 자동으로 무결성 검증을 수행하므로 “전송 후 데이터 무결성 자동 검증” 요구를 충족합니다.
네트워크를 통한 온라인 전송을 지원하고, 증분 전송·재시도·진행 상황 모니터링도 제공합니다.

틀린 이유
A. Snowball Edge는 대용량 오프라인(또는 하이브리드) 전송용 장비입니다. 온라인 전송도 가능하지만, 전송 후 자동 무결성 검증이 DataSync처럼 기본 동작으로 포함된 서비스는 아닙니다.
C. S3 File Gateway는 S3를 파일 공유(NFS/SMB) 로 쓰기 위한 게이트웨이로, 마이그레이션 후 파일 단위 무결성 자동 검증 워크플로를 제공하지 않습니다.
D. S3 Transfer Acceleration은 업로드 속도 향상용이며, 전송 완료 후 자동 무결성 검증 기능은 없습니다.

Answer: D

요구사항
DNS 서버 2대를 AWS로 마이그레이션
약 200개 영역 호스팅, 일 평균 약 100만 건 요청
가용성 최대화
두 서버 관리와 관련된 운영 오버헤드 최소화

D. 두 개의 가용 영역에 걸친 Auto Scaling 그룹에서 EC2 인스턴스를 띄우고, 영역 파일을 가져온 뒤, 원하는 용량 1·최대 3으로 두고 CPU 사용률 기반으로 스케일 알람을 구성한다.
두 AZ에 걸친 Auto Scaling 그룹으로 인스턴스를 분산하면 한 AZ 장애 시에도 다른 AZ에서 DNS 서비스를 유지할 수 있어 가용성을 높일 수 있습니다.
원하는 용량 1, 최대 3 + CPU 기반 스케일 아웃으로, 평소에는 1대로 비용을 줄이고 부하 시에만 2~3대로 늘리며, 인스턴스 장애 시 ASG가 자동으로 교체하므로 두 대를 수동으로 관리하는 부담을 줄일 수 있습니다.
기존 DNS 서버(영역 파일)를 그대로 EC2로 옮기는 방식이라, “두 대의 DNS 서버를 마이그레이션”하면서 가용성과 운영 효율을 동시에 만족시키는 구성입니다.

틀린 이유
A. Route 53에서 200개 호스트 영역을 만들고 영역 파일을 가져오는 것은 서버를 마이그레이션하는 것이 아니라 관리형 DNS로 전환하는 방식입니다. 문제는 “두 대의 DNS 서버를 AWS로 마이그레이션”하고 그 서버 관리 오버헤드를 줄이는 것이므로, EC2 + ASG로 서버 워크로드를 옮기는 D가 요구사항에 더 맞습니다.
B. 단일 EC2 인스턴스 한 대만 쓰면 장애 시 서비스 중단이 발생해 가용성 최대화를 만족하지 못합니다. 알람은 다운타임을 알려줄 뿐, 고가용성 구성을 대신하지 않습니다.
C. AWS SMS로 서버를 EC2로 옮기는 것만으로는, 여러 AZ에 분산·자동 복구·스케일링이 포함되지 않습니다. 두 서버 관리와 장애 대응을 ASG로 줄이는 내용이 없어, “가용성 최대화 + 운영 오버헤드 최소화”에는 D가 더 적합합니다.

Answer: C

요구사항
AWS Organizations의 여러 AWS 계정에서 애플리케이션 실행
멀티파트 업로드로 여러 리전의 여러 S3 버킷에 업로드
비용 준수를 위해 불완전한 멀티파트 업로드에 대해 보고 필요
최소한의 운영 오버헤드로 충족

C. 불완전한 멀티파트 업로드 객체 수를 보고하도록 S3 Storage Lens를 구성한다.
S3 Storage Lens는 조직·계정·버킷 단위로 S3 스토리지 메트릭을 한곳에 모아 보여 주는 분석 서비스입니다. 불완전한 멀티파트 업로드 개수와 그로 인한 스토리지 비용을 메트릭으로 제공하므로, 비용 준수용 보고에 바로 쓸 수 있습니다.
Organizations와 연동해 여러 계정·여러 리전·여러 버킷을 한 대시보드에서 조회할 수 있고, 설정만 하면 대시보드·S3 내보내기로 보고가 가능해 운영 부담이 적습니다.

틀린 이유
A. AWS Config는 리소스 구성·규칙 준수용입니다. “불완전한 멀티파트 업로드 개수”를 보고하는 기본 규칙은 없고, 커스텀 규칙(예: Lambda)을 만들면 개발·유지보수 부담이 커져 “최소 운영 오버헤드”에 맞지 않습니다.
B. SCP는 권한 상한을 정하는 정책입니다. 메트릭을 수집하거나 보고하는 기능이 없어, “불완전한 멀티파트 업로드 객체 수를 보고”하는 용도로 사용할 수 없습니다.
D. S3 Multi-Region Access Point는 요청을 여러 리전 버킷으로 라우팅하는 엔드포인트입니다. 스토리지 메트릭·불완전한 멀티파트 업로드 보고 기능은 없습니다.

Answer: D

요구사항
Amazon RDS for MySQL 프로덕션 DB 운영
보안 규정 준수를 위해 DB 버전 업그레이드 필요
중요 데이터 포함 → 데이터 손실 없이 업그레이드·테스트
빠르게 진행하고 최소한의 운영 오버헤드로 수행

D. Amazon RDS 블루/그린 배포를 사용해 프로덕션 변경을 배포하고 테스트한다.
RDS Blue/Green 배포는 현재 프로덕션(블루)과 동일 엔진의 새 버전이 적용된 그린 환경을 만들고, 블루와 동기화된 복제본으로 유지합니다.
그린에서 새 버전으로 업그레이드·기능 테스트를 한 뒤, 문제 없을 때 전환(cutover) 하면 다운타임을 짧게 가져가면서 데이터 손실 없이 버전 업그레이드가 가능합니다.
블루/그린 생성·동기화·전환을 RDS가 관리하므로, 스냅샷 복원·DMS 설정 등 직접 작업이 적어 운영 오버헤드가 적고, “빠르게 업그레이드하고 테스트” 요구에 맞습니다.

틀린 이유
A. 수동 스냅샷 후 같은 인스턴스 인플레이스 업그레이드는 프로덕션을 직접 올리는 방식이라, 새 버전을 먼저 테스트할 수 없고 업그레이드 중 다운타임·롤백 위험이 있습니다.
B. 백업 후 새 버전 인스턴스로 복원하는 방식은 백업 시점 이후 변경분이 반영되지 않아 데이터 손실 없이 전환하려면 추가 작업이 필요하고, 동기화·전환 절차를 직접 구성해야 해 최소 오버헤드에 맞지 않습니다.
C. DMS로 새 버전 RDS에 복제하는 것도 가능하지만, 복제 태스크·모니터링·스키마 처리 등 설정·운영 부담이 크고, RDS 버전 업그레이드 전용인 블루/그린(D) 이 더 단순하고 오버헤드가 적습니다.

Answer: D

요구사항
매일 한 번 실행되는 데이터 처리 작업
완료까지 최대 2시간 소요
중단되면 처음부터 재시작해야 함
가장 비용 효율적인 방식으로 해결

D. Amazon EventBridge 예약 이벤트로 트리거되고, Amazon EC2에서 실행되는 Amazon ECS 작업을 사용한다.
EventBridge 스케줄로 매일 한 번 ECS 작업을 실행하고, 그 작업을 EC2 인스턴스에서 돌리면 2시간 제한에 걸리지 않습니다. 필요할 때만 EC2를 띄워서 작업을 돌리고, 끝나면 인스턴스를 종료하는 패턴으로 작업 시간(약 2시간)만 과금할 수 있습니다.
EC2는 Spot 또는 On-Demand를 쓰고, 작업이 없을 때는 인스턴스 수를 0으로 두면 24시간 상시 가동이 아니므로, Reserved Instance로 24시간 켜 두는 것(A) 보다 비용 효율적입니다.
Lambda(B)는 최대 실행 시간 15분이라 2시간 작업에는 사용할 수 없습니다.

틀린 이유
A. 예약 인스턴스에서 크론으로 스크립트를 돌리면, 인스턴스는 24시간 가동이 되어 매일 2시간만 쓰더라도 전체 시간에 대해 비용이 발생합니다. “가장 비용 효율적”이라기보다는 상시 서버가 필요한 경우에 맞는 방식입니다.
B. Lambda는 실행 제한 15분이므로, 최대 2시간 걸리는 작업을 한 번에 실행할 수 없어 요구사항을 충족하지 못합니다.
C. Fargate 작업도 2시간 실행은 가능하지만, 같은 2시간 워크로드에 대해 EC2(특히 Spot)로 ECS를 돌리는 D가 일반적으로 시간당 비용이 더 낮아 “가장 비용 효율적”인 선택에 더 가깝습니다.

Answer: B

요구사항
사용자 프로필·관계·상호작용 데이터를 AWS에 저장
DB 변경 사항을 모니터링하는 애플리케이션 필요
데이터 엔터티 간 관계 분석 후 사용자에게 권장 사항 제공
최소한의 운영 오버헤드로 충족

B. Amazon Neptune에 정보를 저장하고, Neptune Streams로 DB 변경 사항을 처리한다.
Neptune은 그래프 DB로, 사용자(노드)·관계·상호작용(엣지)을 저장하고 “친구의 친구”, “추천 친구” 같은 관계 분석·권장에 적합합니다.
Neptune Streams는 Neptune의 변경 데이터 캡처(CDC) 로, 추가·수정·삭제를 스트림으로 내보냅니다. 별도 Kinesis·Lambda 파이프라인 없이 Neptune 안에서 변경 모니터링을 처리할 수 있어 운영 부담이 적습니다.

틀린 이유
A. Neptune 저장은 맞지만, 변경 처리를 Kinesis Data Streams로 하려면 Neptune 변경을 Kinesis로 보내는 구성을 직접 만들어야 합니다. Neptune 전용 CDC인 Neptune Streams(B) 를 쓰는 편이 더 단순하고 오버헤드가 적습니다.
C, D. QLDB는 원장(레저) 용도로, 감사·불변 이력에 적합합니다. “엔터티 간 관계 분석·추천” 같은 그래프 질의에는 Neptune이 맞고, Neptune Streams는 Neptune 전용이라 QLDB와 함께 쓰는 D는 성립하지 않습니다.

Answer: C

요구사항
대량의 데이터 저장
데이터는 매시간 분석됨
여러 가용 영역에 있는 여러 Amazon EC2 Linux 인스턴스가 데이터를 수정
필요한 저장 공간이 향후 6개월 동안 계속 증가

C. Amazon Elastic File System(Amazon EFS)에 데이터를 저장하고, 애플리케이션 인스턴스에 해당 파일 시스템을 마운트한다.
EFS는 NFS 기반 공유 파일 시스템으로, 여러 AZ에 있는 여러 EC2 인스턴스가 동시에 같은 파일 시스템을 마운트해 읽기·쓰기(수정) 할 수 있습니다. “여러 AZ의 여러 EC2가 데이터를 수정” 요구에 맞습니다.
저장 용량이 자동으로 늘어나 6개월 동안 증가하는 요구를 만족하고, 매시간 분석처럼 자주 접근·수정하는 워크로드에 적합합니다.

틀린 이유
A. S3 Glacier는 아카이브·장기 보관용으로, 검색 지연·비용이 있고 “매시간 분석·인스턴스가 수정”하는 용도가 아닙니다.
B. EBS 볼륨은 한 번에 한 EC2 인스턴스에만 연결되며, 다른 AZ의 인스턴스에는 붙일 수 없습니다. 여러 AZ의 여러 인스턴스가 같은 스토리지를 공유해 수정하는 시나리오에는 맞지 않습니다.
D. EBS(프로비저닝된 IOPS 포함)는 한 AZ에만 존재하고, 여러 인스턴스가 여러 AZ에서 하나의 EBS를 공유해 읽기/쓰기하는 구성은 지원되지 않습니다. “여러 AZ의 여러 EC2가 수정”에는 EFS가 적합합니다.

Answer: C

요구사항
PostgreSQL 다중 AZ DB 인스턴스용 Amazon RDS에 데이터 저장
트래픽 증가로 성능 문제 발생
DB 쿼리가 성능 저하의 주요 원인으로 판단
애플리케이션 성능 개선 필요

C. 원본 DB 인스턴스에서 읽기 전용 복제본(Read Replica) 을 만들고, 읽기 트래픽은 읽기 복제본으로 보낸다.
RDS Read Replica는 기본(primary) DB의 비동기 복제본으로, 읽기 전용 쿼리를 복제본으로 분산하면 기본 인스턴스 부하가 줄어듭니다.
읽기 비중이 큰 경우 “DB 쿼리가 주요 원인”인 성능 저하를 완화할 수 있어, 애플리케이션 성능 향상에 직접적으로 기여합니다.

틀린 이유
A. 다중 AZ 대기(standby) 복제본은 장애 조치용이며, 읽기 트래픽을 제공할 수 없습니다. 읽기 부하 분산에는 사용할 수 없습니다.
B. Transfer Acceleration은 S3용 기능입니다. RDS에는 Transfer Acceleration 설정이 없어 이 요구사항과 무관합니다.
D. Kinesis Data Firehose는 스트리밍 데이터를 S3·Redshift 등으로 적재하는 서비스입니다. 애플리케이션–RDS 사이의 DB 요청 동시성 향상이나 읽기 부하 분산 용도가 아니므로, “DB 쿼리 성능 저하” 해결에는 맞지 않습니다.

Answer: C

요구사항
매일 10GB 원격 측정 데이터를 소스 데이터 계정의 S3 버킷에 저장
여러 컨설팅 기관이 분석에 사용, 각 기관의 분석가가 읽기만 필요
보안과 운영 효율을 최대화하면서 소스 데이터 계정의 데이터 공유

C. 대행사가 소유한 AWS 계정에 대해 S3 버킷의 교차 계정 액세스를 구성한다.
소스 계정은 버킷을 비공개로 두고, 버킷 정책(또는 리소스 기반 정책)으로 대행사 계정에만 읽기 권한을 부여합니다. 각 대행사는 자사 계정의 IAM(사용자/역할)으로 분석가 접근을 관리합니다.
보안: 버킷을 공개하지 않고, 외부에 대한 IAM 사용자를 소스 계정에 두지 않으며, 필요한 계정에만 읽기 권한을 줍니다.
운영 효율: 소스 계정이 “분석가마다” IAM 사용자를 만들 필요가 없고, “대행사 계정 단위”로만 권한을 주면 되어 관리가 단순합니다.

틀린 이유
A. “S3 글로벌 테이블”은 존재하지 않습니다(글로벌 테이블은 DynamoDB). 대행사별로 데이터를 복제하면 저장 비용과 관리가 늘어나 “운영 효율·보안 극대화”에는 교차 계정 액세스(C)가 더 적합합니다.
B. S3 버킷을 제한된 시간이라도 공개하면 URL을 아는 누구나 접근 가능해 보안을 극대화할 수 없습니다.
D. 소스 데이터 계정에 각 분석가마다 IAM 사용자를 만들면 사용자 생성·권한·퇴사 시 회수 등을 모두 소스 계정에서 해야 해 운영 부담이 크고, 외부 기관 인원을 한 계정에 두는 것은 보안·관리 측면에서 C(계정 단위 교차 계정 액세스)보다 불리합니다.

Answer: C

요구사항
기본 리전에서 FSx for NetApp ONTAP로 CIFS·NFS 파일 공유 사용
EC2 애플리케이션이 해당 파일 공유에 접근
보조 리전에 스토리지 재해 복구(DR) 필요
보조 리전의 복제 데이터는 기본 리전과 동일한 프로토콜(CIFS/NFS) 로 접근 가능해야 함
최소한의 운영 오버헤드로 충족

C. 보조 리전에 FSx for ONTAP 인스턴스를 만들고, NetApp SnapMirror로 기본 리전에서 보조 리전으로 데이터를 복제한다.
SnapMirror는 NetApp/FSx for ONTAP의 리전 간 복제 기능입니다. 기본 리전 FSx를 소스, 보조 리전 FSx를 대상으로 SnapMirror를 설정하면 지속적으로 복제되며, DR 시 보조 리전 FSx를 그대로 CIFS/NFS로 마운트해 사용할 수 있습니다.
보조 리전도 FSx for ONTAP이므로 CIFS·NFS 그대로 사용 가능해 “동일 프로토콜” 요구를 충족하고, Lambda·수동 백업/복원 없이 FSx·SnapMirror만으로 구성할 수 있어 운영 오버헤드가 적습니다.

틀린 이유
A. Lambda로 S3에 복사하고 S3를 보조 리전으로 복제하면, 보조 리전 데이터는 객체 스토리지(S3) 입니다. CIFS/NFS로 접근하려면 별도 파일 시스템(FSx 등)으로 복원·구성이 필요해, “동일 프로토콜”과 “최소 오버헤드” 모두에서 C보다 불리합니다.
B. AWS Backup으로 FSx 볼륨 백업 후 보조 리전으로 복사하고, 그 백업에서 새 FSx를 만드는 방식은 주기적 백업/복원에 가깝습니다. 지속 복제·빠른 전환이 되는 SnapMirror(C)보다 RPO·운영 부담 측면에서 불리합니다.
D. EFS는 NFS만 지원하고 CIFS는 지원하지 않습니다. 기본 리전이 CIFS·NFS를 쓰므로 “동일 프로토콜”을 만족하지 못하고, FSx → EFS 전환은 “복제”가 아니라 마이그레이션에 가깝습니다.

Answer: C

요구사항
Lambda 기반 이벤트 드리븐 애플리케이션
S3 버킷에 파일 추가 시 이벤트 발생
현재 S3 이벤트 대상을 SNS로 구성
S3 이벤트를 확장 가능한 방식으로 처리해야 함

C. 이벤트를 Amazon SQS로 보내는 SNS 구독을 만들고, SQS 큐가 Lambda를 트리거하도록 구성한다.
SNS → SQS → Lambda 패턴으로, SQS가 버퍼 역할을 합니다. Lambda가 일시적으로 느리거나 스로틀되더라도 이벤트가 SQS에 쌓이고, 큐 깊이에 따라 Lambda가 자동으로 스케일되며 메시지를 처리합니다.
SQS는 재시도·DLQ로 실패 메시지를 관리할 수 있어, S3 이벤트를 유실 없이·확장 가능하게 처리하는 데 적합합니다.

틀린 이유
A. S3 이벤트를 “Lambda 실행 전에 ECS에서 처리”하도록 하면, 이벤트 버퍼·재시도·Lambda 스케일링을 위한 표준 구조가 아니고, “S3 이벤트를 확장 가능하게 처리”하는 일반적인 방법은 SQS + Lambda(C)입니다.
B. EKS를 끼워 넣는 것도 A와 마찬가지로, S3 이벤트 처리의 확장성·단순성 측면에서 SQS + Lambda보다 유리하지 않습니다.
D. AWS SMS(Server Migration Service)는 서버 마이그레이션용이며, S3 이벤트를 보내거나 Lambda가 “SMS 이벤트”를 폴링하는 구조는 S3 이벤트 처리와 맞지 않습니다.

Answer: B, C

요구사항
Amazon API Gateway 기반 새 서비스 설계
요청 패턴 예측 불가: 초당 0건 → 500건 이상으로 급증 가능
백엔드 DB: 총 데이터 크기 1GB 미만, 향후 증가 불명
단순 키-값 요청으로 쿼리

B. AWS Lambda
Lambda는 동시 실행 수가 0에서 수천까지 자동 스케일되며, 용량을 미리 프로비저닝할 필요가 없습니다.
API Gateway에서 Lambda를 백엔드로 직접 호출하면, “0 → 500+ RPS”처럼 급변하는 트래픽을 계산(compute) 계층에서 처리하기에 적합합니다.

C. Amazon DynamoDB
DynamoDB는 키-값·문서 모델의 NoSQL DB로, 단순 키-값 조회에 맞습니다.
스토리지와 처리량이 자동으로 확장되며, 온디맨드 모드로 예측 어려운 요청 패턴을 처리할 수 있어, “1GB 미만·증가 불명·키-값” 요구를 DB 계층에서 충족합니다.

틀린 이유
A. Fargate는 컨테이너 실행용입니다. 0→500+ RPS 급증에 대비하려면 태스크 수·스케일 정책을 직접 관리해야 하고, Lambda(B)가 더 빠르게 스케일되고 운영 부담이 적습니다.
D. EC2 Auto Scaling은 인스턴스 기반이라 스케일 아웃에 수 분 걸립니다. “갑자기 500+ RPS”에는 Lambda(B)처럼 초 단위 스케일이 더 적합합니다.
E. Aurora MySQL은 관계형(SQL) DB입니다. “단순 키-값”은 가능하지만, 키-값·예측 불가 트래픽·자동 확장에는 DynamoDB(C)가 더 잘 맞고, Aurora는 용량·스케일 계획이 더 필요합니다.

Answer: A

요구사항
연구 데이터 수집 후 전 세계 직원과 공유
데이터를 S3 버킷에 저장하고 AWS에서 처리
직원과 데이터 공유
안전하면서 운영 오버헤드가 최소인 AWS 솔루션

A. AWS Lambda로 S3 사전 서명 URL(Presigned URL) 을 생성하고, 직원에게 해당 URL 사용을 안내한다.
Presigned URL은 일정 시간만 유효한 임시 URL로, 직원이 AWS 콘솔·IAM 자격 증명 없이 브라우저나 클라이언트로 특정 객체/버킷에만 접근할 수 있게 합니다.
Lambda(또는 기존 API)에서 권한·만료 시간을 제어해 URL만 발급하면 되므로, 직원별 IAM 사용자·게이트웨이·SFTP 인프라를 만들 필요가 없어 운영 오버헤드가 적습니다.

틀린 이유
B. 직원마다 IAM 사용자를 만들고 콘솔을 쓰게 하면, 전 세계 직원의 생성·권한·퇴사 시 회수 등 관리 부담이 커지고, “데이터 공유”만 할 때는 Presigned URL(A)보다 단순하지 않습니다.
C. S3 File Gateway는 게이트웨이와 공유 마운트를 구성·유지해야 하고, 네트워크(VPN 등) 접근도 필요해 운영 오버헤드가 Presigned URL(A)보다 큽니다.
D. Transfer Family SFTP + 사용자 지정 ID 공급자 + Secrets Manager는 SFTP 서버·자격 증명을 운영하는 구조라, “URL 하나로 임시 접근”하는 A보다 구성·운영 부담이 큽니다.

Answer: A

요구사항
가구 재고 앱: 여러 AZ에 걸친 여러 EC2, ALB 뒤에 배치
문제: 들어오는 트래픽이 한 EC2 인스턴스에 몰려, 일부 요청에 지연 발생

A. ALB에서 세션 선호도(스티키 세션) 를 비활성화한다.
스티키 세션이 켜져 있으면 같은 클라이언트의 요청이 항상 같은 인스턴스로 가서, 트래픽이 한 인스턴스에 몰리고 그 인스턴스만 지연이 생깁니다.
스티키 세션을 끄면 ALB가 요청을 여러 인스턴스에 골고루 분산(라운드 로빈 등)하므로, 한 인스턴스에만 몰리는 현상이 줄어들고 지연이 완화됩니다.

틀린 이유
B. ALB를 NLB로 바꿔도 트래픽이 한 인스턴스에 몰리는 원인(세션 선호도)은 그대로일 수 있어, “한 인스턴스에 편중” 문제를 직접 해결하지 못합니다.
C. 인스턴스 수를 늘리면 전체 용량은 늘지만, 스티키 세션이 켜져 있으면 여전히 특정 인스턴스에 트래픽이 몰릴 수 있어, 편중·지연의 근본 원인을 없애는 것은 A(스티키 세션 비활성화)입니다.
D. 대상 그룹 상태 확인 빈도는 비정상 인스턴스 감지 속도만 바꿀 뿐, 트래픽 분산 방식은 바꾸지 않아 “한 인스턴스에 편중” 문제를 해결하지 못합니다.

Answer: C, E

요구사항
Lambda: S3에서 파일 다운로드 후 복호화
파일은 AWS KMS 키로 암호화됨
필요한 권한이 올바르게 설정되도록 해야 함 (2개 선택)

C. KMS 키 정책에서 Lambda(실행 역할 또는 함수) 에 대해 kms:Decrypt 권한을 부여한다.
KMS 키는 키 정책으로 “누가 이 키를 사용할 수 있는지”를 제어합니다. Lambda가 KMS로 복호화하려면 키 정책에서 Lambda가 사용하는 실행 역할(또는 해당 principal) 에 kms:Decrypt(및 필요 시 kms:DescribeKey)를 허용해야 합니다.
E. kms:Decrypt 권한이 있는 IAM 역할을 만들고, 이 역할을 Lambda 함수의 실행 역할로 연결한다.
Lambda가 S3에서 KMS 암호화 객체를 받아 복호화할 때는 Lambda 실행 역할이 KMS에 Decrypt를 호출할 수 있어야 합니다. 실행 역할에 kms:Decrypt가 포함된 정책을 부여(직접 또는 별도 정책 첨부)하고, 그 역할을 Lambda 실행 역할로 지정해야 합니다.
C = KMS 쪽에서 “Lambda가 쓰는 principal” 허용, E = Lambda 쪽에서 “실행 시 쓰는 역할에 Decrypt 권한 부여”. 둘 다 있어야 Lambda로 KMS 복호화가 동작합니다.

틀린 이유
A. Lambda 리소스 정책은 “누가 이 Lambda를 호출할 수 있는지”만 제어합니다. kms:Decrypt는 KMS API이므로 Lambda 리소스 정책에 넣어도 KMS 복호화 권한이 되지 않습니다.
B. “KMS 키 정책에서 Lambda IAM 역할에 복호 해독 권한 부여”는 기술적으로 맞는 설정입니다. 정답이 C, E로 주어진 경우, C는 “키 정책에서 Lambda 관련 principal에 복호화 허용”을, E는 “실행 역할 생성·연결”을 각각 가리키는 조합으로 보면 됩니다.
D. kms:Decrypt가 있는 IAM 정책을 “Lambda 함수에 첨부”한다고 했지만, 권한을 받는 주체는 IAM 역할이고, 그 역할을 Lambda 실행 역할로 지정해야 합니다. 정책만 만들고 “함수에 붙인다”는 표현은 부정확하고, 역할을 만들고 그 역할을 Lambda 실행 역할로 연결(E)이 올바른 방법입니다.

Answer: B

요구사항
재무 검토를 위해 AWS 비용 모니터링
조직 관리 계정에서 모든 구성원 계정의 비용·사용량 보고서를 쿼리하는 아키텍처
한 달에 한 번 쿼리 실행, 청구서에 대한 자세한 분석 제공
가장 확장 가능하고 비용 효율적인 방법

B. 관리 계정에서 비용 및 사용량 보고서(CUR) 를 켜고, 보고서를 Amazon S3로 전달한 뒤, Amazon Athena로 분석한다.
관리 계정에서 CUR를 활성화하면 조직 전체(모든 구성원 계정) 비용·사용량을 한 보고서로 수집할 수 있어, “관리 계정에서 모든 구성원 계정 보고서 쿼리” 요구에 맞습니다.
CUR는 S3로 전달(Parquet/CSV)하는 방식이 표준이며, 한 달에 한 번 쿼리하는 용도에는 실시간 스트리밍(Kinesis)이 필요하지 않습니다.
Athena는 서버리스, 쿼리당 과금이라 월 1회 분석만 할 때 클러스터를 상시 운영할 필요가 없어 Redshift·EMR보다 비용 효율적이고, 용량 프로비저닝 없이 확장 가능합니다.

틀린 이유
A. CUR는 일반적으로 S3로 전달되며, Kinesis로 보내는 구성은 표준이 아닙니다. EMR은 클러스터를 띄워야 해서 월 1회 쿼리에는 비용·운영 부담이 커 Athena(B)보다 비효율적입니다.
C. CUR를 구성원 계정마다 켜고 S3로 보내면, 관리 계정에서 “한 번에 모든 구성원 계정 쿼리”를 하려면 보고서를 따로 모아야 합니다. 관리 계정 한 곳에서 CUR를 쓰는 B가 더 단순합니다. Redshift는 클러스터 비용이 발생해 월 1회 분석에는 Athena보다 비용 효율이 떨어집니다.
D. 구성원 계정별 CUR + Kinesis는 CUR 배포 방식으로 일반적이지 않고, 월 1회 상세 분석에는 S3 + Athena(B) 조합이 더 적합합니다.

Answer: A

요구사항
Auto Scaling 그룹의 EC2에서 게임 애플리케이션 실행
애플리케이션은 UDP 패킷으로 데이터 전송
트래픽 증감에 따라 스케일 아웃·스케일 인되며, 트래픽이 확장·축소된 인스턴스로 분산되어야 함

A. Auto Scaling 그룹에 Network Load Balancer(NLB) 를 연결한다.
NLB는 4계층(Layer 4) 로 TCP·UDP·TLS를 지원하므로 UDP 트래픽을 그대로 전달·분산할 수 있습니다.
NLB의 대상 그룹에 Auto Scaling 그룹을 등록하면, ASG에서 인스턴스가 늘어나거나 줄어들 때 대상이 자동으로 갱신되고, 들어오는 트래픽이 현재 건강한 인스턴스들에 분산됩니다. 그래서 “UDP + 스케일 인/아웃 + 트래픽 분산” 요구를 충족합니다.

틀린 이유
B. Application Load Balancer(ALB)는 HTTP/HTTPS(Layer 7) 전용이라 UDP를 지원하지 않아, UDP 기반 게임 트래픽에는 사용할 수 없습니다.
C. Route 53 가중치 정책은 DNS 응답을 여러 IP로 나누는 방식입니다. ASG 인스턴스 수·IP가 바뀌어도 DNS만으로는 자동으로 대상이 갱신되지 않고, “로드 밸런서 + 대상 그룹 + ASG” 패턴만큼 스케일·헬스체크와 잘 맞지 않습니다. UDP 트래픽 분산·스케일링에는 NLB(A)가 적합합니다.
D. NAT 인스턴스는 아웃바운드(인스턴스 → 인터넷) 용이며, 인바운드 트래픽을 여러 EC2에 분산하는 로드 밸런싱 역할을 하지 않습니다. “트래픽이 증가·감소에 따라 확장·축소된 인스턴스로 라우팅” 요구를 충족하지 못합니다.

Answer: A

요구사항
여러 브랜드의 여러 웹사이트가 AWS에서 운영됨
각 사이트가 매일 수십 GB 수준의 웹 트래픽 로그 생성
모든 웹사이트에 걸쳐 트래픽 패턴 분석이 가능한 확장 가능한 솔루션
몇 달에 걸쳐 주 1회, 온디맨드 분석
표준 SQL로 쿼리 가능해야 함
가장 비용 효율적인 방법

A. 로그를 Amazon S3에 저장하고, Amazon Athena로 분석한다.
S3는 대용량 로그 저장에 적합하고, 용량이 늘어나도 저장 비용이 낮고 별도 프로비저닝 없이 확장됩니다.
Athena는 서버리스, 쿼리당 과금이라 주 1회 온디맨드 분석에는 클러스터를 상시 운영할 필요가 없어 비용이 적습니다. 표준 SQL로 쿼리할 수 있어 “표준 SQL 지원” 요구를 충족합니다.
로그를 S3에 모아 두고 Athena로 여러 사이트를 한 번에 쿼리하면, “모든 웹사이트에 걸친 트래픽 패턴 분석”을 가장 비용 효율적으로 구현할 수 있습니다.

틀린 이유
B. RDS는 트랜잭션 DB용으로, 매일 수십 GB씩 쌓이는 로그를 저장하면 스토리지·용량 비용이 크고 확장도 비쌉니다. 대용량 로그 분석에는 비용 효율이 떨어집니다.
C. OpenSearch Service는 검색·로그 분석에 쓰이지만, 클러스터를 돌리므로 주 1회만 쿼리할 때는 상시 운영 비용이 듭니다. S3 + Athena(A)보다 비용 효율이 낮습니다.
D. EMR은 클러스터(Hadoop/Spark 등)를 띄우는 서비스로, 로그를 “EMR 클러스터에 저장”하면 클러스터 비용이 계속 발생합니다. 주 1회 SQL 분석만 할 때는 쿼리당 과금인 Athena(A)가 비용 효율이 더 좋습니다.

Answer: A, E

요구사항
국가별 하위 도메인: example.com, country1.example.com, country2.example.com
워크로드는 Application Load Balancer 뒤에 있음
전송 중 웹사이트 데이터 암호화 (HTTPS)
위를 만족하는 단계 조합 2개 선택

A. AWS ACM 콘솔에서 최상위 도메인 example.com용 공개 인증서와 \*.example.com용 와일드카드 인증서를 요청한다.
인터넷에 공개되는 웹사이트(example.com, country1.example.com 등)를 ALB에서 HTTPS로 서비스하려면 공개(Public) ACM 인증서가 필요합니다.
example.com( apex )은 와일드카드로 커버되지 않으므로, example.com용 인증서와 \*.example.com용 와일드카드 인증서를 요청하면 모든 하위 도메인과 apex를 암호화할 수 있습니다.

E. DNS 공급업체에 ACM이 안내하는 필수 DNS 레코드를 추가해 도메인 소유권 검증을 완료한다.
ACM 공개 인증서를 발급받으려면 도메인 소유권 검증이 필요합니다. DNS 검증 시 ACM이 제공하는 CNAME(또는 해당) 레코드를 DNS 공급업체에 추가하면 검증이 완료되고 인증서가 발급됩니다.

틀린 이유
B. 비공개(Private) 인증서는 VPC 내부·사내용 엔드포인트용입니다. 공개 웹사이트(example.com, country1.example.com)를 암호화하는 용도에는 공개 인증서(A) 가 맞습니다.
C. example.com에 대해 “공개 + 비공개” 인증서를 둘 다 요청할 필요는 없고, 공개 웹사이트 암호화에는 공개 인증서(A) 만 있으면 됩니다.
D. 이메일로 먼저 검증한 뒤 DNS 검증으로 “전환”하는 선택 사항이고, 요구사항을 충족하는 필수 조합은 “공개·와일드카드 인증서 요청(A)” + “DNS 레코드로 도메인 소유권 검증(E)”입니다.

Answer: B

요구사항
온프레미스 키 관리자의 암호화 키를 반드시 사용해야 함
키 관리자는 규제·규정 준수 때문에 AWS 클라우드 밖에 있어야 함
AWS 밖에 보관된 키로, 여러 공급업체의 다양한 외부 키 관리자를 지원하면서 암·복호화를 관리하고 싶음
최소한의 운영 오버헤드로 충족

B. 외부 키 관리자가 지원하는 AWS KMS 외부 키 저장소(External Key Store) 를 사용한다.
KMS External Key Store는 암호화 키를 AWS 밖(온프레미스·타사 HSM 등) 에 두고, KMS가 그 외부 키 관리자와 연동해 암·복호화 요청만 보내는 방식입니다. 키는 외부 키 관리자를 벗어나지 않습니다.
규제로 “키를 AWS 밖에 둬야 한다”는 요구를 그대로 지키면서, KMS를 통해 AWS 서비스(S3, EBS 등)의 암호화를 그 키로 통일할 수 있어 운영 부담이 적습니다.

틀린 이유
A. CloudHSM 키 저장소는 AWS CloudHSM 클러스터(AWS 내 HSM)를 사용합니다. 키가 AWS 안에 있으므로 “키 관리자를 AWS 밖에 둔다”는 요구를 충족하지 못합니다.
C. 기본 KMS 관리형 키 저장소는 키를 AWS KMS 안에서 생성·보관합니다. “키를 AWS 밖에 보관” 요구와 맞지 않습니다.
D. 사용자 지정 키 저장소도 CloudHSM 클러스터(AWS 내 HSM)를 쓰므로, 키가 AWS 내부에 있어 “온프레미스·AWS 밖 키 관리자” 요구를 충족하지 못합니다.

Answer: C

요구사항
AWS에서 HPC(고성능 컴퓨팅) 워크로드 호스팅
수백 대 EC2에서 실행, 대용량 데이터의 분산 처리를 위해 공유 파일 시스템에 대한 병렬 액세스 필요
여러 인스턴스가 동시에 데이터 세트 접근
1ms 이내 액세스 지연 시간 필요
처리 완료 후 엔지니어가 수동 후처리를 위해 데이터 세트에 접근해야 함

C. 공유 파일 시스템으로 Lustre용 Amazon FSx를 쓰고, 후처리를 위해 파일 시스템을 Amazon S3 버킷에 연결한다.
FSx for Lustre는 HPC·병렬 파일 시스템용으로, 수백 대 EC2가 동시에 같은 파일 시스템에 병렬 I/O로 접근할 수 있고, 1ms 이하 지연 시간을 목표로 할 수 있어 “1ms 이내 액세스 지연”과 “병렬 액세스” 요구를 충족합니다.
Lustre 파일 시스템을 S3 버킷과 연결하면, 처리용 데이터를 S3↔Lustre 간에 옮기고, 처리 후 데이터를 S3로 내보낼 수 있어, 엔지니어가 후처리 시 S3(또는 Lustre 마운트)로 데이터에 접근할 수 있습니다.

틀린 이유
A. EFS는 일반 공유 파일 시스템용이며, HPC용 1ms 이내 지연·대규모 병렬 I/O에는 FSx for Lustre만큼 적합하지 않습니다. 지연 시간 요구를 충족하기 어렵습니다.
B. S3는 객체 스토리지로, 요청당 지연이 수 ms~수십 ms 이상이라 1ms 액세스 지연 요구를 만족하지 못하고, S3를 파일 시스템처럼 마운트해도 HPC 수준의 병렬 성능을 기대하기 어렵습니다.
D. AWS RAM은 리소스 공유(예: 서브넷·트랜짓 게이트웨이)용이며, S3를 “마운트용 공유 파일 시스템”으로 쓰게 해주는 서비스가 아닙니다. S3 자체도 1ms 지연·HPC 병렬 파일 시스템 요구를 충족하지 못합니다.

Answer: A

요구사항
VoIP(Voice over IP) 기반 애플리케이션
전 세계 사용자에게 트래픽 제공
여러 AWS 리전에 걸친 자동 장애 조치로 고가용성 필요
사용자 대기 시간 최소화, 단 사용자 기기 IP 캐싱에 의존하지 않음

A. 상태 확인(헬스 체크) 이 있는 AWS Global Accelerator를 사용한다.
Global Accelerator는 고정 애니캐스트 IP 2개를 제공합니다. 클라이언트는 항상 이 같은 IP로 접속하고, 어느 리전으로 보낼지는 Global Accelerator가 엣지에서 판단해 AWS 백본으로 전달합니다. 그래서 “사용자 기기에서 리전별 IP를 캐싱할 필요”가 없고, IP 캐싱에 의존하지 않고 라우팅·장애 조치가 이루어집니다.
헬스 체크로 리전/엔드포인트 상태를 보고, 장애 시 다른 리전으로 자동 전환되므로 리전 간 자동 장애 조치 요구를 충족합니다.
트래픽이 가장 가까운 AWS 엣지로 들어와 백본으로 전달되므로 지연 시간 최소화에 유리하고, UDP/TCP를 지원해 VoIP 트래픽에 적합합니다.

틀린 이유
B. Route 53 지리적 위치 라우팅은 DNS 기반이라, 클라이언트/리졸버가 DNS 결과를 캐싱할 수 있어 “사용자 기기 IP 캐싱에 의존하지 않는다”는 요구와 맞지 않습니다. 고정 IP로 라우팅·장애 조치를 하는 Global Accelerator(A)가 더 적합합니다.
C. CloudFront는 HTTP/HTTPS(및 일부 웹 프로토콜)용이며, VoIP에 흔히 쓰이는 UDP(RTP) 를 지원하지 않아 VoIP 요구사항을 충족하지 못합니다.
D. ALB는 리전 단위이며 경로 기반 라우팅은 HTTP용입니다. 전 세계 사용자·리전 간 자동 장애 조치·VoIP용 글로벌 지연 최소화를 담당하는 구성이 아니므로 요구사항을 충족하지 못합니다.

Answer: B

요구사항
수백 GB 데이터를 밀리초 미만 지연으로 처리
데이터 센터 HPC 환경을 갖추고, 예보 기능 확장 목표
대량의 지속적인 처리량을 견디는 고가용성 클라우드 스토리지 필요
수천 대 컴퓨팅 인스턴스가 동시에 전체 데이터 세트에 접근·처리 가능해야 함

B. Lustre 퍼시스턴트 파일 시스템용 Amazon FSx를 사용한다.
FSx for Lustre는 HPC·병렬 파일 시스템으로, 수천 대 인스턴스가 동시에 같은 데이터 세트에 병렬 I/O로 접근할 수 있고, 밀리초 미만 지연과 대용량 지속 처리량에 적합합니다.
퍼시스턴트(Persistent) 배포는 데이터 복제·내구성을 제공해 고가용성 요구를 충족합니다. Scratch는 단기·임시용이라 장애 시 데이터 손실 가능이 있어 “고가용성”에는 퍼시스턴트(B)가 맞습니다.

틀린 이유
A. Lustre Scratch는 단기·임시 워크로드용이며, 복제가 없어 고가용성이 아니고 장애 시 데이터 손실 위험이 있어 “고가용성 클라우드 스토리지” 요구를 충족하지 못합니다.
C, D. EFS(버스팅·프로비저닝 모드)는 일반 공유 파일 시스템용이며, 밀리초 미만 지연과 수천 대 HPC 인스턴스의 동시 병렬 액세스에는 FSx for Lustre(B)만큼 적합하지 않습니다.

Answer: C

요구사항
온프레미스 PostgreSQL → Amazon RDS for PostgreSQL 마이그레이션
온프레미스는 고 IOPS EBS 블록 스토리지 사용
일일 피크 I/O는 15,000 IOPS 이하
디스크 스토리지 용량과 무관하게 디스크 IOPS를 프로비저닝하고 싶음
가장 비용 효율적인 방법

C. 범용 SSD(gp3) EBS 볼륨 스토리지 유형을 쓰고, 15,000 IOPS를 프로비저닝한다.
gp3는 스토리지 크기와 분리해서 IOPS(및 처리량)를 지정할 수 있습니다. 작은 볼륨이라도 15,000 IOPS만 따로 프로비저닝할 수 있어 “디스크 용량과 무관하게 IOPS 프로비저닝” 요구를 충족합니다.
io1도 IOPS를 독립적으로 설정할 수 있지만, 같은 IOPS 기준으로 gp3가 io1보다 저렴해 “가장 비용 효율적”인 선택은 gp3(C) 입니다.

틀린 이유
A. gp2는 IOPS가 용량에 연동됩니다(3 IOPS/GB). 15,000 IOPS를 내려면 약 5,000 GB가 필요해, “디스크 용량과 무관하게 IOPS 프로비저닝”을 만족하지 못합니다.
B. io1은 IOPS를 독립적으로 프로비저닝할 수 있지만, 동일 IOPS 대비 비용이 gp3보다 높아 “가장 비용 효율적”이라고 보기 어렵습니다.
D. 마그네틱 볼륨은 성능이 낮아 15,000 IOPS나 “최대 IOPS” 요구를 충족하지 못합니다.

Answer: A

요구사항
온프레미스 Microsoft SQL Server Enterprise Edition DB를 AWS로 마이그레이션
온라인 애플리케이션이 이 DB로 트랜잭션 처리
데이터 분석 팀이 동일한 프로덕션 DB로 보고·분석 실행
관리형 서비스로 전환해 운영 오버헤드를 최소화

A. Microsoft SQL Server용 Amazon RDS로 마이그레이션하고, 보고용으로 읽기 복제본을 사용한다.
RDS for SQL Server는 관리형 서비스로, OS·패치·백업·고가용성 등을 AWS가 담당해 운영 부담이 적습니다. 기존 SQL Server 워크로드를 그대로 옮기기 때문에 엔진·애플리케이션 변경이 최소화됩니다.
프로덕션은 RDS 기본 인스턴스에서 트랜잭션 처리하고, 보고·분석은 읽기 복제본에서 실행하면 프로덕션 부하를 줄이면서 “트랜잭션 + 보고” 요구를 충족합니다.

틀린 이유
B. EC2 위에 SQL Server를 직접 설치하면 OS·SQL Server·패치·백업·Always On 구성 등을 직접 관리해야 해 운영 오버헤드가 RDS(A)보다 큽니다.
C. DynamoDB는 NoSQL이라 스키마·쿼리·애플리케이션을 전면 변경해야 하고, “SQL Server용 보고 복제본” 개념과도 다릅니다. 운영 부담 최소화·기존 SQL Server 유지 요구에 맞지 않습니다.
D. Aurora MySQL은 MySQL 엔진이라 SQL Server와 호환되지 않습니다. 마이그레이션 시 스키마·쿼리·앱 수정이 크게 필요해 “운영 오버헤드 최소화 + SQL Server 마이그레이션”에는 RDS for SQL Server(A)가 적합합니다.

'자격증' 카테고리의 다른 글

AWS SAA-C03 Dump 551-600 (0)	2026.02.03
AWS SAA-C03 Dump 501-550 (0)	2026.02.02
AWS SAA-C03 Dump 451-500 (0)	2026.02.02
AWS SAA-C03 Dump 401-450 (0)	2026.02.02
AWS SAA-C03 Dump 351-400 (0)	2026.02.01

티스토리툴바