AWS SAA-C03 Dump 451-500
Answer: B, C, F
요구사항
애플리케이션·DB를 AWS로 마이그레이션, Amazon ECS, AWS Direct Connect, Amazon RDS 사용
운영 팀이 담당하는 활동 3개 선택 (공유 책임 모델 기준)
B. RDS DB 인스턴스 생성 및 예약 유지 관리 기간 구성
RDS 인스턴스 생성과 예약 유지 관리 기간 설정은 고객(운영 팀) 이 콘솔/CLI/CloudFormation 등으로 수행함.
AWS는 인프라·엔진 패치를 관리하고, “언제 유지보수할지”는 고객이 정함.
C. ECS에서 모니터링·패치·로그·호스트 침입 탐지용 추가 소프트웨어 구성
ECS 제어 평면·기반 인프라는 AWS가 관리하고, 모니터링 에이전트·패치·로그 수집·호스트 침입 탐지 등 추가 소프트웨어 구성은 고객(운영 팀) 이 담당함.
F. Direct Connect를 통해 전송되는 데이터의 암호화
Direct Connect 구간의 전송 중 데이터 암호화(TLS, VPN 등) 적용 여부와 구성은 고객(운영 팀) 이 결정·관리함.
틀린 이유
A. RDS 인프라·OS·플랫폼 관리는 AWS 책임이다. RDS는 관리형 서비스라 고객이 인프라·OS를 관리하지 않음.
D. RDS 마이너·메이저 버전 패치 설치 및 적용은 AWS가 수행한다. 고객은 업그레이드 시점·버전 선택만 하고, 실제 패치 설치·적용은 AWS가 함.
E. 데이터 센터 내 RDS 인프라의 물리적 보안은 AWS 책임이다. 고객 운영 팀이 담당하는 활동이 아님.
Answer: B
요구사항
EC2에서 Java 기반 작업 실행
매시간 실행, 10초 소요, 1GB 메모리
예약 간격으로 실행, CPU는 짧은 순간만 높고 대부분 낮은 사용률
작업 실행 비용 최적화 목표
B. 1GB 메모리 Lambda 함수에 코드 배치, EventBridge 예약 규칙으로 매시간 실행
Lambda는 호출당·실행 시간(GB-초) 만 과금되므로, 매시간 10초 × 1GB만 사용하면 매우 저렴함.
EC2는 24시간 켜두면 대부분 유휴인데 비용이 나가고, Lambda는 실행한 10초만 과금되어 비용 최적화에 맞음.
EventBridge 예약 규칙으로 매시간 Lambda를 호출하면 “매시간 실행” 요구를 충족함.
Java 런타임·1GB 메모리 모두 Lambda에서 지원함.
틀린 이유
A. Fargate는 태스크당 최소 1분 단위 과금이라 10초만 돌려도 1분 비용이 나감. 매시간 10초 작업에는 Lambda가 Fargate보다 비용·구성 모두 유리함.
C. 기존 AMI에 컨테이너를 두고 스케줄로 중지하는 방식은 결국 EC2(또는 EC2 위 컨테이너) 를 쓰는 구조라, 10초/시간 작업에 EC2를 상시 또는 주기적으로 켜두면 유휴 비용이 커져 비용 최적화에 맞지 않음.
D. 작업 끝나면 EC2 중지, 다음 작업 전에 다시 시작하는 방식은 EC2 시작/중지 오버헤드·관리 복잡도가 있고, 매시간 몇 분씩만 켜도 Lambda 10초 실행보다 비용·운영 측면에서 불리함.
Answer: D
요구사항
EC2 데이터와 여러 S3 버킷에 대한 백업 전략 수립
규정 요구: 특정 보유 기간 동안 백업 보존
보유 기간 동안 백업 파일 변조 불가(immutability)
D. AWS Backup으로 규정 준수 모드 볼트 잠금이 있는 백업 볼트 생성, 필요한 백업 계획 생성
AWS Backup은 EC2(EBS 스냅샷) 와 S3 등 여러 리소스를 한 백업 계획으로 관리할 수 있어, “EC2 + 여러 S3 버킷” 요구를 충족함.
볼트 잠금(Vault Lock) 을 규정 준수(compliance) 모드로 두면, 보유 기간 동안 루트 계정을 포함해 누구도 복구 포인트를 삭제·변경할 수 없어 변조 불가를 보장함.
“규정 요구 사항”과 “보유기간 동안 변조 불가”에는 규정 준수 모드가 필요하고, 거버넌스 모드는 특정 권한으로 우회 가능해 충족하지 못함.
틀린 이유
A. 거버넌스(governance) 모드 볼트 잠금은 특정 권한이 있으면 삭제·우회가 가능해 엄격한 변조 불가를 보장하지 못함. 규정·변조 불가 요구에는 규정 준수(compliance) 모드(D)가 맞음.
B. Data Lifecycle Manager는 EBS 스냅샷(EC2) 용이라 S3 버킷 백업을 다루지 않음. “EC2 + 여러 S3 버킷” 전략과 “볼트 잠금 기반 변조 불가”를 함께 만족하려면 AWS Backup(D)이 맞음.
C. S3 File Gateway는 온프레미스→S3 파일 공유용이고, EC2·S3 통합 백업 전략·볼트 잠금 기반 변조 불가를 제공하지 않음. S3 수명 주기만으로는 WORM(변조 불가) 를 보장하지 못함.
Answer: C
요구사항
여러 AWS 리전·계정에 리소스 보유
이전 직원이 리소스 인벤토리 상세를 남기지 않음
모든 계정에서 다양한 워크로드의 관계를 구축·매핑해야 함
운영상 가장 효율적인 방법 선택
C. Workload Discovery on AWS로 워크로드 아키텍처 다이어그램 생성
Workload Discovery on AWS는 여러 계정·리전에 걸친 워크로드를 자동으로 탐색하고, 리소스 간 관계를 바탕으로 아키텍처 다이어그램을 생성하는 데 적합함.
“모든 계정에서 워크로드 관계 세부 정보 구축·매핑”을 자동 탐색·다이어그램 생성으로 처리해, 수동 인벤토리·수동 다이어그램 작성보다 운영 효율이 높음.
인벤토리 부재 상황에서 운영상 가장 효율적인 대응은 C(Workload Discovery)임.
틀린 이유
A. Systems Manager Inventory는 관리형 인스턴스(EC2 등) 의 소프트웨어·패치 인벤토리 수집용이라, 여러 계정·리전의 워크로드 관계를 구축·매핑하거나 아키텍처 다이어그램을 만드는 용도가 아님.
B. Step Functions로 워크로드 세부 정보를 수집하고 아키텍처 다이어그램을 수동으로 작성하는 방식은 수동 작업이 많아 “운영상 가장 효율적인 방식”이 아님. C는 자동 탐색·다이어그램 생성으로 더 효율적임.
D. X-Ray는 앱 요청 추적(tracing) 과 서비스 맵용이라, X-Ray가 적용된 애플리케이션의 런타임 관계만 보여줌. 모든 계정의 다양한 워크로드를 탐색·매핑하는 인벤토리·다이어그램 용도가 아니며, “운영상 가장 효율적인” 요구를 충족하려면 Workload Discovery(C)가 맞음.
Answer: B, D, F
요구사항
AWS Organizations 사용
계정별로 다른 예산으로 운영
특정 기간 동안 할당된 예산 임계값 도달 시 → (1) 알림 수신, (2) 추가 리소스 프로비저닝 자동 차단
위를 만족하는 솔루션 조합 3개 선택
B. AWS Budgets로 예산 생성, 필요한 계정의 결제 대시보드에서 예산 금액 설정
AWS Budgets에서 계정별 예산을 만들고 예산 금액(임계값) 을 정하는 곳은 Billing and Cost Management(결제 대시보드) 이다.
비용 및 사용 보고서(CUR)는 예산 설정이 아니라 데이터 내보내기용이라, 예산 금액 설정은 B가 맞다.
D. AWS Budgets 예산 작업을 실행할 권한이 있는 IAM 역할 생성
예산 임계값 도달 시 예산 작업(Budget action) 이 리소스 프로비저닝 차단 등을 수행하려면, 예산이 Assume할 IAM 역할이 필요하다.
해당 역할에 예산 작업 실행 권한과, 필요 시 “프로비저닝 거부”용 정책을 붙인다. 예산 작업은 IAM 사용자가 아니라 IAM 역할을 사용하는 구성이 맞다.
F. 계정이 예산 임계값에 도달할 때 알림 추가, SCP로 프로비저닝을 제한하는 정책을 적용하는 예산 작업 추가
알림: 예산 임계값 도달 시 SNS/이메일 등으로 알림을 보내도록 예산 알림을 설정한다.
프로비저닝 방지: 조직 단위에서 SCP(서비스 제어 정책) 로 특정 프로비저닝 API를 거부하고, 예산 작업에서 임계값 도달 시 해당 SCP를 적용·활성화하거나, 이미 설계된 SCP와 연동하는 방식으로 추가 리소스 프로비저닝을 차단한다.
“적절한 SCP로 생성된 IAM 자격 증명을 선택하는 예산 작업”은, 예산 기반으로 SCP 적용/선택을 통해 프로비저닝을 막는 구성을 의미하는 것으로 보면 된다.
틀린 이유
A. 예산 금액(임계값) 설정은 비용 및 사용 보고서(CUR) 섹션에서 하는 것이 아니다. 예산 생성·금액 설정은 결제 대시보드(Billing) 에서 하므로 B가 맞다.
C. 예산 작업을 실행할 때 사용하는 것은 IAM 사용자가 아니라 IAM 역할이다. 서비스가 대신 실행하는 예산 작업에는 역할(D)이 적합하다.
E. “구성 규칙(Config 규칙)으로 생성된 IAM 자격 증명”으로는 추가 리소스 프로비저닝 방지를 구현하기 어렵다. Config 규칙은 설정 평가·감지용이고, 프로비저닝 차단은 IAM 정책/역할 또는 SCP로 하는 것이 맞다. 따라서 프로비저닝 방지 측면에서는 F(SCP 기반 예산 작업)가 맞다.
Answer: C
요구사항
한 리전의 Amazon EC2에서 애플리케이션 실행
두 번째 리전에 EC2 백업 필요
두 번째 리전에서 EC2 리소스 프로비저닝 및 한 AWS 계정에서 EC2를 중앙 관리
가장 비용 효율적인 방법 선택
C. AWS Backup으로 백업 계획 생성, EC2에 대한 두 번째 리전 교차 리전 백업 구성
AWS Backup은 한 계정·한 곳에서 백업 계획을 만들고, 여러 리전·리소스(EC2/EBS 등)를 중앙에서 관리할 수 있어 “한 계정에서 중앙에서 EC2 인스턴스 관리”에 맞음.
교차 리전 백업으로 EC2(EBS) 스냅샷을 두 번째 리전으로 복사해 “두 번째 리전에 백업”을 충족하고, 필요 시 해당 리전에서 복원(프로비저닝) 하면 “두 번째 리전에서 EC2 리소스 프로비저닝”을 만족함.
두 번째 리전에 EC2를 상시 가동하지 않고 백업(스냅샷)만 두고, 재해 시 복원하는 방식이라 가장 비용 효율적임.
틀린 이유
A. 두 번째 리전에 비슷한 수의 EC2를 두는 DR 계획은 두 리전 모두 EC2 상시 운영이 되어 계산 비용이 두 배에 가깝고, “가장 비용 효율적으로” 충족하지 못함.
B. EBS 스냅샷 생성 후 주기적으로 두 번째 리전에 복사하는 방식은 가능하지만, 한 계정에서 중앙 관리·자동화·라이프사이클은 AWS Backup(C)이 더 잘 제공해, 운영·비용 측면에서 C가 더 비용 효율적임.
D. 두 번째 리전에 EC2를 배포하고 DataSync로 데이터 전송하면 두 리전 모두 EC2 상시 운영이 되어 비용이 높음. 백업만 두고 필요 시 복원하는 C가 더 비용 효율적임.
Answer: C
요구사항
제조업체에 데이터를 전송하는 애플리케이션 구축
자체 IdP(Identity Provider) 보유
사용자가 앱으로 데이터를 전송할 때 IdP가 사용자 인증하도록 함
AS2(Applicability Statement 2) 프로토콜 사용 필수
C. AWS Transfer Family로 데이터 전송, IdP 인증용 Lambda 함수 생성
AS2는 B2B EDI용 전자 데이터 교환 프로토콜이다. AWS에서 AS2 기반 관리형 파일 전송을 지원하는 서비스는 AWS Transfer Family(Transfer for AS2)이다. 따라서 “AS2 프로토콜을 사용해야 합니다” 요구는 Transfer Family로 충족한다.
자체 IdP 인증: Transfer Family는 커스텀 IdP 연동을 지원하며, Lambda를 커스텀 IdP로 사용해 회사 IdP와 연동할 수 있다. Lambda에서 IdP를 호출해 사용자를 인증하면 “IdP가 애플리케이션 사용자를 인증” 요구를 만족한다.
따라서 AS2 + 자체 IdP 인증을 동시에 만족하는 답은 C이다.
틀린 이유
A. DataSync는 스토리지 간 대량 이전·동기화용이며 AS2 프로토콜을 지원하지 않는다. “AS2를 사용해야 합니다” 조건을 충족하지 못한다.
B. AppFlow는 SaaS·애플리케이션 간 데이터 플로우 연동용이며 AS2를 지원하지 않는다. AS2 필수 요구를 충족하지 못한다.
D. Storage Gateway는 하이브리드 스토리지(온프레미스↔S3) 용이며 AS2를 지원하지 않는다. Cognito는 AWS IdP이므로 “자체 IdP로 인증” 요구와 맞지 않고, AS2 요구도 충족하지 못한다.
Answer: B, C
요구사항
API Gateway에서 REST API 설계 (현금 회수 서비스)
컴퓨팅: 메모리 1GB, 스토리지 2GB
데이터: 관계형(relational) 형식
최소한의 관리 노력으로 위를 만족하는 추가 AWS 서비스 2개 선택
B. AWS Lambda
API Gateway → Lambda는 REST API용 서버리스 표준 구성이라, 서버 관리가 없어 “최소한의 관리 노력”에 맞음.
Lambda는 메모리 최대 10GB, 에피머럴 스토리지(/tmp) 최대 10GB 지원하므로, 1GB 메모리·2GB 스토리지 요구를 충족함.
C. Amazon RDS
“데이터가 관계형 형식이어야 합니다”는 관계형 DB 요구이므로 Amazon RDS(MySQL, PostgreSQL 등)가 적합함.
RDS는 관리형 서비스(패치·백업 등 AWS 담당)라 관리 노력을 줄이는 데 맞음.
틀린 이유
A. EC2는 OS·패치·스케일링 등 인스턴스 관리가 필요해, “최소한의 관리 노력”에는 Lambda(B)보다 부담이 큼.
D. DynamoDB는 NoSQL이라 관계형 요구를 충족하지 못함. 관계형 데이터에는 RDS(C)가 맞음.
E. EKS는 클러스터·노드·파드 관리로 관리 부담이 크고, “최소한의 관리 노력”과 맞지 않음. Lambda + RDS가 더 단순함.
Answer: A
요구사항
AWS Organizations로 여러 AWS 계정에서 워크로드 운영
태깅 정책으로 리소스 생성 시 부서 태그를 리소스에 추가
회계팀이 EC2 소비 지출을 파악해야 함
계정과 무관하게 비용 책임 부서를 구분해야 함
회계팀은 조직 내 모든 계정에 대해 Cost Explorer 접근·모든 보고서 접근 필요
운영상 가장 효율적인 방법 선택
A. 조직 관리 계정 청구 콘솔에서 "부서" 사용자 정의 비용 할당 태그 활성화, Cost Explorer에서 태그별 그룹·EC2 필터로 보고서 생성
비용 할당 태그를 켜야 Cost Explorer에서 태그별(부서별) 비용을 볼 수 있음. “부서”는 회사 태깅 정책으로 붙이는 사용자 정의 태그이므로 사용자 정의 비용 할당 태그로 활성화해야 함.
조직 관리 계정(Management Account) 의 청구(Billing) 콘솔에서 비용 할당 태그를 활성화하면, 통합 결제로 모든 멤버 계정 비용이 한곳에 모이고, 회계팀이 계정과 관계없이 부서별·EC2별로 볼 수 있음.
Cost Explorer에서 태그(부서)별 그룹 + EC2 필터로 한 보고서만 만들면 “EC2 소비 지출”과 “비용 책임 부서”를 운영상 가장 효율적으로 파악할 수 있음.
틀린 이유
B. “부서”는 회사가 정의한 사용자 정의 태그이지 AWS 정의 태그가 아님. AWS 정의 비용 할당 태그를 활성화하는 것은 이 요구와 맞지 않음.
C. 멤버 계정 청구 콘솔에서만 활성화하면 계정마다 반복해야 하고, 조직 전체를 한 번에 보려면 관리 계정에서 활성화하는 A가 운영상 더 효율적임.
D. 활성화 위치는 멤버 계정이 아니라 관리 계정이 맞고, “부서”는 사용자 정의 태그이므로 AWS 정의로 활성화하는 설명은 틀림.
Answer: C
요구사항
Salesforce(SaaS) 와 Amazon S3 간 데이터 안전 교환
저장 데이터는 AWS KMS 고객 관리형 키(CMK) 로 암호화
전송 중 데이터 암호화
Salesforce 계정에 API 액세스 활성화됨
C. Amazon AppFlow 흐름을 만들어 Salesforce에서 S3로 데이터를 안전하게 전송
Amazon AppFlow는 Salesforce 등 SaaS와 S3·Redshift 등 AWS 간 관리형 데이터 전송 서비스로, “Salesforce ↔ S3 데이터 안전 교환”에 맞는 서비스임.
저장 암호화: AppFlow에서 S3 대상을 설정할 때 KMS CMK 기반 서버 측 암호화(SSE-KMS)를 지정할 수 있어 “KMS 고객 관리형 키로 저장 데이터 암호화”를 충족함.
전송 암호화: AppFlow는 TLS로 전송 중 데이터를 암호화함.
Salesforce는 내장 커넥터로 지원되므로, 사용자 지정 커넥터·Lambda 개발 없이 운영 부담을 줄이면서 요구사항을 충족함.
틀린 이유
A. Lambda로 Salesforce API 호출 후 S3에 기록하는 방식은 인증·페이징·오류 처리·암호화 설정 등을 직접 구현·유지보수해야 해 운영 부담이 큼. Salesforce↔S3 전송에는 AppFlow(C)가 관리형으로 더 적합함.
B. Step Functions로 워크플로를 정의해도, 실제 전송은 Lambda 등 태스크 구현이 필요해 A와 유사한 부담이 있음. SaaS↔AWS 전용 관리형 서비스인 AppFlow(C)가 더 적합함.
D. Salesforce용 사용자 지정 커넥터를 만들면 개발·유지보수가 필요함. AppFlow는 Salesforce 네이티브 커넥터를 제공하므로 사용자 지정 커넥터 없이 C로 요구사항을 충족할 수 있음.
Answer: B
요구사항
단일 리전에서 모바일 게임 앱 개발
Auto Scaling 그룹의 여러 EC2에서 실행, DynamoDB에 데이터 저장
사용자–서버 간 TCP·UDP 트래픽 사용
전 세계 사용, 가능한 가장 낮은 지연 목표
B. Global Accelerator로 가속기 생성, TCP·UDP 수신 NLB를 가속기 엔드포인트로 두고, ASG를 NLB에 등록
전 세계 저지연: AWS Global Accelerator는 애니캐스트 IP와 글로벌 네트워크로, 사용자가 가장 가까운 엣지로 들어와 AWS 백본으로 리전까지 가므로 글로벌 사용자 기준 지연을 줄이는 데 적합함.
TCP·UDP: ALB는 HTTP/HTTPS(L7) 만 지원해 UDP를 처리하지 못함. NLB는 TCP·UDP(L4) 를 지원하므로 “TCP 및 UDP 트래픽” 요구에는 NLB가 맞음.
가속기 엔드포인트 뒤에 NLB를 두고 TCP·UDP 포트에서 수신하도록 하면, 게임 트래픽(TCP+UDP)에 맞는 구성이 됨.
틀린 이유
A. ALB는 HTTP/HTTPS 전용이라 UDP를 지원하지 않음. “TCP 및 UDP” 요구를 충족하지 못함.
C. CloudFront는 HTTP/HTTPS(및 WebSocket) 용 CDN이라, 일반 TCP·UDP 게임 트래픽을 프록시하지 않음. TCP·UDP 기반 게임에는 Global Accelerator + NLB(B)가 맞음.
D. CloudFront는 TCP·UDP 미지원이고, ALB는 UDP 미지원이라 C·D 모두 “TCP·UDP + 전 세계 저지연” 요구를 충족하지 못함.
Answer: B
요구사항
고객 주문 처리 애플리케이션
EC2에서 실행, 주문을 Amazon Aurora에 저장
트래픽이 높을 때 주문을 충분히 빠르게 처리하지 못함
가능한 한 빨리, 안정적으로 데이터베이스에 주문을 기록할 방법 선택
B. 주문을 SQS 대기열에 넣고, ALB 뒤 ASG의 EC2가 SQS에서 읽어 DB에 처리
SQS에 주문을 쓰면 버퍼가 생겨, 트래픽이 몰려도 주문이 유실되지 않고 대기열에 쌓임 → 안정적으로 기록할 수 있음.
ASG의 EC2가 SQS에서 메시지를 풀해서 Aurora에 쓰면, 대기열 길이에 따라 인스턴스 수를 늘려 처리량을 키울 수 있어 가능한 한 빨리 DB에 기록하는 데 유리함.
ALB 뒤 ASG로 워커를 두고, SQS 기반 스케일링(대기열 크기 등)을 쓰면 고트래픽 시에도 안정적·신속한 주문 기록이 가능함.
틀린 이유
A. SNS는 퍼블/서브라 “데이터베이스 엔드포인트를 구독”한다고 해도 DB가 직접 SNS를 구독할 수 없음. SNS는 큐가 아니라 구독자에게 푸시하므로, 구독자가 없거나 과부하면 메시지 유실 가능성이 있어 “안정적으로 기록”에는 SQS(B)가 맞음.
C. SNS에 주문을 쓰고 “DB 엔드포인트 구독”은 위와 같이 DB 직접 구독 불가이고, SNS만으로는 백프레셔·대기열·스케일링 구조를 만들기 어려움. 안정적·신속 기록에는 SQS + 워커(B) 패턴이 적합함.
D. “EC2가 CPU 임계값에 도달할 때만” SQS에 쓴다는 조건은 일반 시에는 직접 DB 등 다른 경로를 쓰게 되어 경로가 나뉘고 복잡해짐. “예약된 조정”은 시간대별 고정 스케일용이라, 트래픽/대기열에 반응하는 스케일링에는 SQS 기반 스케일링(B)이 더 적합함.
Answer: C
요구사항
IoT 매트리스 센서가 수면 데이터 수집 → S3로 전송
매트리스당 매일 약 2MB 데이터
매트리스별로 데이터 처리·요약 필요
결과는 가능한 한 빨리 제공
처리에 1GB 메모리, 30초 이내 완료
가장 비용 효율적인 방법 선택
C. Python 스크립트와 AWS Lambda 사용
S3 이벤트로 새 객체(매트리스·밤별 데이터) 업로드 시 Lambda를 즉시 호출하면, 데이터 도착 직후 처리해 가능한 한 빨리 결과를 낼 수 있음.
Lambda는 메모리 최대 10GB, 실행 시간 최대 15분 지원하므로 1GB 메모리, 30초 요구를 충족함.
매트리스당 2MB·1회/일 수준이면 호출당·실행시간(30초×1GB) 과금으로 비용이 적고, Glue·EMR 같은 배치/클러스터보다 가장 비용 효율적임.
틀린 이유
A, D (AWS Glue): Glue는 배치 ETL용이라 작업 시작까지 DPU 프로비저닝 등으로 지연이 있고, “가능한 한 빨리”에는 불리함. 매트리스당 2MB 같은 소량·파일 단위 처리에는 Glue 비용(DPU 분)이 과하고, Lambda가 더 비용 효율적임.
B (Amazon EMR + Spark): EMR 클러스터 기동에 수 분 걸려 “가능한 한 빨리”를 만족하기 어렵고, 2MB/매트리스 규모에 Spark 클러스터를 쓰는 것은 과한 구성이라 비용 효율이 떨어짐. Lambda(C)가 더 적합함.
Answer: A
요구사항
온라인 쇼핑 앱, 모든 주문을 RDS for PostgreSQL 단일 AZ DB 인스턴스에 저장
단일 실패 지점 제거 목표
애플리케이션 코드 변경 없이 DB 다운타임 최소화할 방법 선택
A. DB 인스턴스 수정 시 다중 AZ 옵션 지정해 기존 인스턴스를 다중 AZ 배포로 전환
RDS는 기존 단일 AZ 인스턴스를 수정(Modify) 해 Multi-AZ로 전환할 수 있음. 콘솔/CLI에서 Multi-AZ 옵션만 바꾸면, AWS가 다른 AZ에 스탠바이 복제본을 만들고 자동 장애 조치를 제공함.
엔드포인트(DNS) 가 그대로이므로 애플리케이션 연결 문자열·코드 변경이 필요 없음.
새 인스턴스 생성·데이터 이전·엔드포인트 변경 없이 기존 인스턴스만 수정하므로 다운타임을 최소화할 수 있음.
틀린 이유
B. 새 다중 AZ 배포를 만들고 스냅샷 복원 후 전환하면 새 엔드포인트로 바꿔야 해 애플리케이션 설정(연결 문자열) 변경이 필요하고, 스냅샷 시점 이후 변경분 처리·전환 절차로 다운타임·복잡도가 커짐. “코드 변경 없이, 다운타임 최소화”에는 A가 맞음.
C. 읽기 전용 복제본은 읽기만 분산할 수 있고 쓰기(주문 저장) 는 프라이머리만 가능함. Route 53으로 요청을 나눠도 쓰기 SPOF는 그대로이며, 자동 장애 조치는 Multi-AZ처럼 제공되지 않음. 단일 실패 지점 제거에는 A(다중 AZ)가 맞음.
D. RDS는 관리형 서비스라 EC2 Auto Scaling 그룹에 넣을 수 없음. RDS 인스턴스는 EC2가 아니므로 D는 성립하지 않음.
Answer: C
요구사항
동일 가용 영역 내 여러 EC2 Nitro 인스턴스에 애플리케이션 배포
애플리케이션 가용성 향상
여러 EC2 Nitro 인스턴스가 여러 블록 스토리지 볼륨에 동시에 쓰기할 수 있어야 함
C. EBS 다중 연결(Multi-Attach)과 프로비저닝된 IOPS SSD(io2) 볼륨 사용
EBS Multi-Attach는 한 EBS 볼륨을 동일 AZ의 여러 EC2에 동시에 연결하고, 여러 인스턴스가 동시에 읽기·쓰기할 수 있게 하는 기능임.
Multi-Attach는 io1·io2(프로비저닝된 IOPS SSD) 에서만 지원되고, gp2, gp3, st1 등은 지원하지 않음.
따라서 “여러 Nitro 인스턴스가 여러 블록 스토리지 볼륨에 동시에 쓰기” 요구를 만족하려면 EBS 다중 연결 + io2(C)가 맞음.
틀린 이유
A. gp3 볼륨은 Multi-Attach를 지원하지 않음. 동일 볼륨을 여러 인스턴스에 붙여 동시 쓰기를 할 수 없음.
B. st1(처리량 최적화 HDD)은 Multi-Attach를 지원하지 않음. 다중 연결 요구를 충족할 수 없음.
D. gp2 볼륨은 Multi-Attach를 지원하지 않음. io1/io2만 지원하므로 C가 맞음.
Answer: A
요구사항
상태 비저장 2계층 앱: 단일 AZ의 EC2 + RDS Multi-AZ DB
애플리케이션 가용성을 높여야 함
위를 만족하기 위해 설계자가 해야 할 일 선택
A. 다중 AZ EC2 Auto Scaling으로 구성하고 Application Load Balancer 생성
현재 가용성 취약점은 EC2가 단일 AZ에만 있다는 점임. 해당 AZ 장애 시 앱 계층 전체가 중단됨.
여러 AZ에 걸친 EC2 Auto Scaling 그룹으로 워커를 분산하면, 한 AZ 장애 시에도 다른 AZ의 인스턴스가 트래픽을 처리해 앱 계층 가용성이 올라감.
Application Load Balancer는 기본적으로 다중 AZ로 동작하며, 트래픽을 여러 AZ의 EC2에 분산하므로, ALB + 다중 AZ ASG 구성이 “애플리케이션 가용성 향상”에 맞는 표준 답임.
틀린 이유
B. EC2 스냅샷을 다른 리전으로 보내는 것은 리전 단위 재해 복구(DR) 용이라, 같은 리전 내 앱 가용성을 높이는 방법이 아님. 단일 AZ SPOF는 그대로임.
C. Route 53 지연 시간 기반 라우팅은 엔드포인트(리전/서비스) 간 라우팅만 바꿀 뿐, EC2를 여러 AZ에 두는 구조를 만들어 주지 않음. EC2가 여전히 단일 AZ면 가용성 문제는 해결되지 않음.
D. Route 53 규칙이 “다중 AZ ALB를 생성”하는 것은 아님. ALB는 별도로 만들고, Route 53은 그 ALB를 가리키게 함. “들어오는 요청 처리”는 ALB 역할이고, 가용성 향상을 위해서는 다중 AZ ASG + ALB(A) 구성이 필요함.
Answer: B
요구사항
AWS Organizations 사용
멤버 계정이 Compute Savings Plan 구매
해당 멤버 계정 워크로드 변경으로 Savings Plan 전체 혜택을 쓰지 못함
구매한 컴퓨팅 용량의 50% 미만만 사용
이 상황에서 취할 조치 선택
B. 조직 관리 계정의 계정 콘솔 → 청구 기본 설정에서 할인 공유 활성화
Savings Plan/RI 할인 공유(Savings sharing) 를 켜면, 한 계정에서 사용하지 않는 Savings Plan 혜택을 조직 내 다른 멤버 계정에 적용할 수 있음.
할인 공유는 조직 단위 설정이라, 조직 관리 계정(Management Account) 의 청구(비용) 콘솔 → 청구 기본 설정에서 활성화함. 멤버 계정 콘솔이 아님.
“50% 미만 사용”으로 남는 혜택을 다른 계정이 쓰게 하려면 관리 계정에서 할인 공유를 켜는 B가 맞음.
틀린 이유
A. 할인 공유는 멤버 계정 청구 설정이 아니라 조직 관리 계정 청구 기본 설정에서 켜는 항목임. 멤버 계정 콘솔(A)에서 활성화하는 설명은 잘못됨.
C. 다른 계정의 워크로드를 Savings Plan이 있는 계정으로 옮기면 그 계정의 사용률은 올라갈 수 있으나, 조직 전체가 남는 혜택을 쓰는 표준 방식은 할인 공유(B) 임. 문제가 “할인 공유”를 묻는 것이므로 B가 정답에 해당함.
D. Reserved Instance 마켓플레이스는 Reserved Instance(RI) 판매·구매용이며, Savings Plan은 여기서 판매할 수 없음. 따라서 D는 성립하지 않음.
Answer: B
요구사항
검색 카탈로그용 마이크로서비스 개발
REST API로 프런트엔드를 사용자에게 제공
REST API가 프라이빗 VPC 서브넷의 컨테이너에서 호스팅되는 백엔드 서비스에 접근해야 함
B. API Gateway로 REST API 설계, 프라이빗 서브넷 ECS에서 호스팅, ECS 접근용 API Gateway 프라이빗 VPC 링크 생성
“REST API를 사용하여 … 제시해야 합니다”이므로 REST API가 필요함. WebSocket API(A, C)는 요구사항과 맞지 않음.
백엔드가 프라이빗 서브넷의 ECS(컨테이너) 이므로, API Gateway가 이 백엔드에 도달하려면 프라이빗 통합이 필요함. VPC Link를 사용해 API Gateway를 VPC 내 NLB/ALB(ECS 앞단)에 연결해야 함.
따라서 REST API + 프라이빗 ECS + 프라이빗 VPC 링크 구성인 B가 요구사항을 충족함.
틀린 이유
A, C. WebSocket API로 설계하는 것은 “REST API를 사용하여 … 제시” 요구와 맞지 않음.
D. API Gateway는 VPC 안에 있는 리소스가 아니라 관리형 서비스라, “API Gateway용 보안 그룹”으로 프라이빗 ECS에 접근하도록 할 수 없음. 프라이빗 VPC 내 백엔드(ECS 앞 NLB/ALB)에 연결하려면 VPC Link를 써야 하므로, 보안 그룹만으로 접근하는 D는 잘못된 설명임.
Answer: C
요구사항
수집된 원시 데이터를 Amazon S3에 저장
다양한 분석에 사용, 요청된 분석 유형에 따라 S3 객체 접근 패턴이 달라짐
접근 패턴을 예측·통제할 수 없음
S3 비용 절감 목표
C. S3 수명 주기 규칙으로 객체를 S3 Standard에서 S3 Intelligent-Tiering으로 전환
접근 패턴을 예측할 수 없을 때는 “자주/가끔” 구분이 어려우므로, 접근에 따라 자동으로 티어를 옮기는 S3 Intelligent-Tiering이 적합함.
Intelligent-Tiering은 Frequent / Infrequent 구간을 실제 접근에 맞춰 자동 이동시키고, Infrequent로 내려갈 때 조회 요금이 없어 Standard-IA보다 예측 불가한 접근에 유리함.
수명 주기 규칙으로 Standard → Intelligent-Tiering 전환만 설정하면, 별도 분석·수동 작업 없이 비용 절감을 달성할 수 있음.
틀린 이유
A. S3 복제는 다른 버킷/리전으로 복제하는 기능이라 스토리지 티어 전환 용도가 아님. “자주 액세스하지 않는 객체”를 식별하는 것도 접근 패턴을 예측할 수 없다는 조건과 맞지 않음.
B. Standard-IA는 조회 요금이 있어, 접근 패턴이 예측 불가할 때 자주 접근하는 객체가 많으면 비용이 오를 수 있음. 예측 불가 시에는 Intelligent-Tiering(C)이 더 적합함.
D. S3 Inventory로 “액세스하지 않은 객체”를 찾아 전환하는 방식은 리포트 분석·전환 작업이 필요해 복잡하고, “아직 안 쓴 객체”가 나중에 자주 쓰일 수 있어 예측 불가 조건과 맞지 않음. Intelligent-Tiering(C)은 접근에 따라 자동으로 티어를 조정하므로 더 적합함.
Answer: D
요구사항
IPv6 주소를 쓰는 EC2에서 애플리케이션 호스팅
애플리케이션은 인터넷으로 다른 외부 애플리케이션과 통신을 시작해야 함
보안 정책: 외부 서비스는 EC2로 연결을 시작할 수 없음 (아웃바운드만 허용)
D. 외부 전용 인터넷 게이트웨이(egress-only internet gateway) 생성 후 서브넷 라우팅 테이블의 대상으로 지정
Egress-only Internet Gateway는 IPv6 전용으로, VPC → 인터넷 방향(아웃바운드)만 허용하고 인터넷 → VPC(인바운드)는 차단함.
따라서 EC2는 외부 애플리케이션으로 나가는 연결을 시작할 수 있고, 외부에서 EC2로 들어오는 연결은 시작할 수 없어 보안 정책을 만족함.
문제에서 “IPv6 주소를 사용”이라고 했으므로, IPv6 아웃바운드 전용에는 NAT 게이트웨이가 아니라 Egress-only Internet Gateway(D)가 맞음.
틀린 이유
A. NAT 게이트웨이는 주로 IPv4 아웃바운드용이다. IPv6 환경에서 “아웃바운드만 허용”하는 구성은 Egress-only Internet Gateway(D)로 해야 함.
B. 인터넷 게이트웨이는 양방향 통신을 허용하므로, 외부에서 EC2로 연결을 시작할 수 있어 “외부 서비스는 EC2에 대한 연결을 시작할 수 없음” 정책을 위반함.
C. 가상 프라이빗 게이트웨이는 VPN/Direct Connect(온프레미스 연결)용이라, EC2가 인터넷상 외부 애플리케이션과 통신하는 경로가 아니며, 아웃바운드 전용 제어에도 쓰이지 않음.
Answer: C
요구사항
VPC 내 컨테이너에서 실행되는 애플리케이션
Amazon S3에 데이터 저장·접근
개발 단계에서 매일 S3에 1TB 저장·접근
비용 최소화 + 가능한 한 트래픽이 인터넷을 통과하지 않도록 할 방법 선택
C. Amazon S3용 게이트웨이 VPC 엔드포인트 생성 후, VPC의 모든 라우팅 테이블에 연결
게이트웨이 VPC 엔드포인트(S3) 를 쓰면 VPC → S3 트래픽이 AWS 내부 네트워크로만 가고 인터넷을 거치지 않아 “트래픽이 인터넷을 통과하지 못하도록” 요구를 충족함.
S3용 게이트웨이 엔드포인트는 시간당 요금·데이터 처리 요금이 없어 1TB/일 수준에서도 비용 최소화에 유리함.
엔드포인트를 VPC의 모든 라우팅 테이블에 연결하면, 해당 VPC의 컨테이너가 S3에 접근할 때 모두 게이트웨이 엔드포인트를 타게 할 수 있음.
틀린 이유
A. S3 Intelligent-Tiering은 스토리지 티어로 비용을 줄이는 기능이라, 트래픽이 인터넷을 지나지 않게 하는 구성과는 무관함.
B. S3 Transfer Acceleration은 인터넷 경유 전송을 가속하는 기능이라, “인터넷 통과 방지”와 맞지 않고, 추가 비용이 들어 “비용 최소화”에도 불리함.
D. S3용 인터페이스 VPC 엔드포인트도 트래픽을 인터넷 밖으로 보낼 수는 있으나, 시간당·데이터 처리 요금이 있어 1TB/일 규모에서는 비용이 큼. S3 접근에는 게이트웨이 엔드포인트(C)가 무료에 가깝고 비용·요구사항 모두 맞음.
Answer: A
요구사항
모바일 채팅 앱, Amazon DynamoDB 기반 데이터 저장
사용자가 가능한 한 짧은 지연으로 새 메시지를 읽기를 원함
최소한의 애플리케이션 변경으로 위를 만족하는 최적 방법 선택
A. 새 메시지 테이블에 DynamoDB Accelerator(DAX) 구성, DAX 엔드포인트 사용하도록 코드 변경
DAX는 DynamoDB용 인메모리 캐시로, 앱과 DynamoDB 사이에 두어 읽기 지연을 마이크로초 수준으로 줄여 “가능한 한 짧은 대기 시간”에 맞음.
DAX는 DynamoDB API(GetItem, Query 등)와 호환되므로, 엔드포인트만 DynamoDB → DAX로 바꾸면 되고 로직 변경은 최소로 “최소한의 애플리케이션 변경”을 만족함.
캐시·무효화는 DAX가 처리하므로, 별도 캐시 레이어를 앱에서 구현할 필요가 없음.
틀린 이유
B. DynamoDB에는 RDS처럼 읽기 전용 복제본과 읽기 전용 엔드포인트 개념이 없음. “읽기 복제본 추가, 읽기 엔드포인트로 연결”은 DynamoDB에서 제공하지 않는 구성이라 성립하지 않음.
C. 읽기 용량 단위(RCU) 증가는 처리량(throughput) 을 늘리는 것이지, 요청당 지연을 크게 줄이는 방법이 아님. “가능한 한 짧은 대기 시간”을 위한 캐시는 DAX(A)가 맞음.
D. ElastiCache Redis를 쓰려면 캐시 적재·무효화·이중 쓰기 등 로직을 앱에 넣어야 해 애플리케이션 변경이 큼. “최소한의 애플리케이션 변경”과 “DynamoDB 대신 Redis만 가리킨다”는 설명도 맞지 않음. DAX(A)는 엔드포인트만 바꾸면 되어 변경이 더 적음.
Answer: A
요구사항
ALB 뒤 EC2에서 웹 사이트 호스팅
정적 콘텐츠 제공
트래픽 증가로 비용 증가 우려
이에 맞는 대응 방법 선택 (문항상 “상태 파일”은 정적 파일로 해석)
A. Amazon CloudFront 배포를 만들어 엣지 로케이션에서 정적 파일 캐싱
정적 콘텐츠는 CloudFront로 엣지 캐시하면, 같은 객체에 대한 요청을 오리진(ALB/EC2)으로 보내지 않고 엣지에서 응답할 수 있음.
오리진으로 가는 트래픽과 EC2 부하가 줄어 비용·부하를 낮출 수 있어, “트래픽 증가에 따른 비용 우려”에 맞는 표준 방법임.
정적 웹 사이트에 CloudFront를 두는 구성이 일반적으로 권장되는 패턴임.
틀린 이유
B. ALB의 대상은 EC2, IP, Lambda 등이며, ElastiCache를 ALB 뒤에 두어 “캐시된 파일을 제공”하는 구조로 연결할 수 없음. 정적 파일 대량 제공·비용 절감에는 엣지 캐시(CloudFront) 가 맞음.
C. AWS WAF는 웹 방화벽(보안·규칙) 용도이며, 정적 파일을 캐시하는 기능은 없음. 캐싱으로 비용을 줄이는 방법이 아님.
D. 다른 리전에 ALB를 하나 더 두고 가까운 리전으로 라우팅하면 오리진 인프라가 두 배가 되어 비용이 늘어날 수 있음. 정적 콘텐츠·비용 절감에는 CloudFront로 엣지 캐싱(A)이 적합함.
Answer: C
요구사항
여러 리전에 여러 VPC를 두고, 리전별로 격리된 워크로드 운영
최근 요구: 모든 리전의 다른 모든 VPC와 VPC 간 통신 필요
최소한의 관리 노력으로 위를 만족할 방법 선택
C. 단일 리전 내 VPC 통신은 Transit Gateway로, 리전 간은 Transit Gateway 피어링으로 관리
Transit Gateway는 한 리전에서 여러 VPC를 한 허브에 붙여, VPC 간 통신을 한 곳(Transit Gateway) 에서 관리하는 구조임. 리전당 Transit Gateway 하나로 해당 리전 내 VPC 통신을 처리할 수 있음.
리전 간 통신은 Transit Gateway 피어링(Inter-region TGW peering) 으로, 리전별 Transit Gateway끼리 연결하면 모든 리전의 VPC가 서로 통신할 수 있음.
VPC 피어링만 쓰면 “모든 VPC ↔ 모든 VPC”를 위해 풀 메시가 필요해 연결 수·관리가 크게 늘어나고, Transit Gateway + TGW 피어링(C)은 허브-스포크로 최소한의 관리 노력으로 요구사항을 충족함.
틀린 이유
A. VPC 피어링은 전이(transitive) 피어링을 지원하지 않아, “모든 VPC가 서로 통신”하려면 VPC 쌍마다 피어링이 필요함. 리전 내·리전 간 모두 풀 메시가 되어 연결 수와 관리 부담이 커져 “최소한의 관리 노력”에 맞지 않음.
B. Direct Connect 게이트웨이는 온프레미스(Direct Connect) 와 여러 리전 VPC를 연결하는 하이브리드 용도임. “모든 리전의 VPC끼리 통신”하는 VPC 간 연결의 주된 수단이 아니며, 이 요구에는 Transit Gateway(C)가 맞음.
D. PrivateLink는 서비스 제공자/소비자 모델로, 한 VPC의 서비스를 다른 VPC에서 비공개로 접근할 때 쓰는 구조임. “모든 VPC가 서로 통신”하는 전체 메시를 최소 관리로 구성하는 용도가 아니며, 이 요구에는 Transit Gateway(C)가 적합함.
Answer: C
요구사항
Amazon ECS에서 사용할 컨테이너화된 애플리케이션 설계
공유 파일 시스템 필요:
내구성이 높을 것
다른 AWS 리전으로 복구 가능, RPO 8시간
리전 내 각 가용 영역에 탑재 대상(mount target) 제공
AWS Backup으로 다른 리전 복제 관리 예정
위를 만족하는 파일 시스템 선택
C. Amazon EFS(Elastic File System), Standard 스토리지 클래스
EFS는 NFS 기반 공유 파일 시스템으로, ECS 태스크(리눅스) 에서 그대로 탑재할 수 있어 “컨테이너화된 앱 + 공유 파일 시스템”에 적합함.
리전 내 각 AZ에 탑재 대상: EFS는 AZ별 mount target을 두는 방식이라 “리전 내의 각 가용 영역에 탑재 대상을 제공” 요구를 충족함.
내구성: EFS는 다중 AZ에 데이터가 저장되어 높은 내구성을 가짐.
AWS Backup + 다른 리전 복제: AWS Backup은 EFS를 백업 소스로 지원하고, 교차 리전 복사로 다른 리전에 복제할 수 있어, RPO 8시간을 백업 주기로 맞출 수 있음.
틀린 이유
A. FSx for Windows File Server는 Windows(SMB) 용이라, 일반적인 ECS 리눅스 컨테이너용 공유 파일 시스템으로는 EFS(NFS) 가 더 적합함.
B. FSx for NetApp ONTAP는 엔터프라이즈 NAS로, ECS와 연동은 가능하지만 “리전 내 각 AZ에 탑재 대상”·AWS Backup 교차 리전 복제 측면에서 ECS + 공유 파일 시스템의 표준 조합은 EFS(C)임.
D. FSx for OpenZFS는 단일 AZ 기본 구성이며, “리전 내의 각 가용 영역에 탑재 대상을 제공”하는 구조는 EFS(AZ별 mount target)가 더 직접적으로 맞음.
Answer: C
요구사항
가까운 시일 내 급격한 성장 예상
기존 사용자 정리, 새 사용자에게 AWS 권한 부여 필요
IAM 그룹 생성, 부서별로 새 사용자를 IAM 그룹에 추가하기로 함
새 사용자에게 권한을 부여하는 가장 안전한 추가 조치 선택
C. 최소 권한을 부여하는 IAM 정책을 만들고, 그 정책을 IAM 그룹에 연결
IAM 그룹에 권한을 주려면 IAM 정책을 그룹에 연결하면 됨. 그룹에 속한 사용자는 해당 정책의 권한을 받음.
최소 권한 원칙에 맞게, 필요한 권한만 담은 정책을 만들어 그룹에 붙이면, 부서별로 그룹에 추가되는 새 사용자가 과도한 권한 없이 안전하게 권한을 받음.
“그룹 기반으로 새 사용자에게 권한 부여”하는 표준·안전한 방법은 그룹에 최소 권한 IAM 정책 연결(C)임.
틀린 이유
A. SCP(서비스 제어 정책) 는 Organizations(OU/계정) 단위로 적용되는 최대 권한 상한 설정용이라, 특정 사용자/그룹에게 “권한을 부여”하는 수단이 아님. 새 사용자·그룹 권한 부여에는 IAM 정책(C)이 맞음.
B. IAM 역할은 그룹에 연결하는 객체가 아님. 그룹에는 정책을 붙임. 역할은 임시 자격 증명(AssumeRole) 용이라, “그룹에 넣은 새 사용자에게 권한 부여”에는 그룹에 정책 연결(C)이 맞음.
D. 권한 경계(Permission boundary) 는 최대 권한 상한을 정하는 것이고, “최소 권한으로 부여”하는 방식이 아님. 그리고 그룹 기반 사용자 권한 부여는 역할/권한 경계가 아니라 그룹에 붙인 정책(C)으로 하는 것이 맞음.
Answer: D
요구사항
그룹에 S3 버킷 나열(ListBucket) 및 버킷 내 객체 삭제(DeleteObject) 권한 필요
현재 정책 적용 후 객체 삭제가 되지 않음
최소 권한 원칙 준수
정책에 추가해야 할 Statement 선택
D. "Action": ["s3:DeleteObject"], "Resource": ["arn:aws:s3:::bucket-name/*"], "Effect": "Allow"
S3에서 DeleteObject는 객체에 대한 권한이므로, 리소스는 객체 ARN인 arn:aws:s3:::bucket-name/* 이어야 함.
현재 정책은 Resource를 arn:aws:s3:::bucket=name(버킷 ARN 형식도 잘못됨)으로만 두어, DeleteObject가 객체에 적용되지 않아 삭제가 실패함.
추가할 Statement로 s3:DeleteObject만 arn:aws:s3:::bucket-name/* 에 허용하면, 최소 권한으로 객체 삭제 문제가 해결됨.
Answer: B
요구사항
로펌이 대중과 정보 공유
수백 개 파일이 공개적으로 읽을 수 있어야 함
지정된 미래 날짜 이전에는 누구도 파일 수정·삭제 불가
가장 안전한 방법 선택
B. S3 버전 관리 활성화된 새 버킷 생성, 지정된 날짜까지 보존 기간이 있는 S3 Object Lock 사용, 정적 웹 사이트 호스팅·읽기 전용 버킷 정책
S3 Object Lock은 보존 기간 동안 객체 삭제·덮어쓰기를 저장소 수준에서 차단하므로, 지정된 날짜까지 “누구도 수정·삭제 불가”를 가장 안전하게 보장함. (루트 포함 어떤 보안 주체도 우회 불가)
Object Lock 사용을 위해 S3 버전 관리가 필요하므로, “S3 버전 관리가 활성화된 새 버킷”이 맞음.
정적 웹 사이트 호스팅 + 버킷 정책으로 객체 읽기 전용 허용을 두면 “공개적으로 읽을 수 있어야 하는” 요구를 충족함.
틀린 이유
A. IAM으로 “지정된 날짜까지 읽기 전용”만 부여하는 방식은 저장소 수준에서 수정·삭제를 막지 못함. 삭제 권한이 있는 주체(또는 루트)가 삭제·수정할 수 있어 “가장 안전한 방식”이 아님.
C. 수정·삭제 이벤트 후 Lambda로 원래 버전으로 복구하는 방식은 이미 수정·삭제가 발생한 뒤 대응하는 구조라, 그 사이 데이터가 변경·삭제될 수 있음. “지정된 날짜 이전 수정·삭제 금지”를 저장소에서 막는 Object Lock(B)보다 안전하지 않음.
D. Object Lock은 버킷 생성 시 활성화하고 객체 단위(또는 기본 보존) 로 보존 기간을 두는 것이 맞고, “폴더를 선택해” 보존을 거는 설명은 Object Lock 동작 방식과 다름. 지정된 날짜까지 보존 기간을 두는 것은 B처럼 “지정된 날짜에 따라 보존 기간이 있는 S3 Object Lock”으로 버킷·객체에 적용하는 것이 정확함.
Answer: B
요구사항
수동 프로비저닝으로 새 웹사이트 인프라 프로토타입 구성 (ASG, ALB, RDS 포함)
구성 검증 완료 후, 자동화된 방식으로 두 가용 영역에서 개발·프로덕션용 인프라를 즉시 배포할 수 있어야 함
위를 만족하기 위해 설계자가 권장할 방법 선택
B. 프로토타입 인프라를 참고해 인프라를 템플릿으로 정의하고, AWS CloudFormation으로 배포
검증된 프로토타입(ASG, ALB, RDS)을 바탕으로 인프라를 템플릿(CloudFormation 템플릿) 으로 정의하면, 동일 구성을 개발·프로덕션에 반복·자동 배포할 수 있음.
CloudFormation으로 스택을 실행하면 자동화된 방식으로 리소스를 생성하고, 두 가용 영역(멀티 AZ ASG, Multi-AZ RDS 등)을 템플릿에 넣어 즉시 배포할 수 있음.
“프로토타입 → 템플릿화 → 자동 배포”의 표준 방법은 CloudFormation(B)임.
틀린 이유
A. Systems Manager는 인스턴스 관리(패치, Run Command 등)용이라, ASG·ALB·RDS 같은 인프라를 프로비저닝·복제하는 도구가 아님. “2개 AZ에 프로토타입 인프라 복제·프로비저닝”에는 CloudFormation(B)이 맞음.
C. AWS Config는 설정 기록·컴플라이언스용이라, 리소스 인벤토리는 할 수 있어도 ASG·ALB·RDS를 두 AZ에 배포하는 기능은 없음. “자동화된 인프라 배포”에는 CloudFormation(B)이 맞음.
D. Elastic Beanstalk은 애플리케이션·플랫폼 배포용이라, 수동으로 만든 프로토타입 인프라를 참조해 그대로 복제하는 용도가 아님. RDS·ASG·ALB를 템플릿으로 정의해 개발·프로덕션에 반복 배포하려면 CloudFormation(B)이 적합함.
Answer: B
요구사항
비즈니스 애플리케이션은 Amazon EC2에서 호스팅
암호화된 객체 스토리지로 Amazon S3 사용
CISO 지시: EC2와 S3 간 애플리케이션 트래픽이 공용 인터넷을 통과해서는 안 됨
규정 준수를 위해 설계자가 사용해야 할 기능 선택
B. VPC 엔드포인트
VPC 엔드포인트(S3용 게이트웨이 엔드포인트) 를 쓰면, VPC 안의 EC2 → S3 트래픽이 공용 인터넷이 아니라 AWS 내부 네트워크로만 전달됨.
“두 서비스(EC2, S3) 간 트래픽이 공용 인터넷을 통과하지 않는다”는 규정 준수 요구를 네트워크 경로 측면에서 충족시키는 기능은 VPC 엔드포인트(B)임.
틀린 이유
A. AWS KMS는 암호화·키 관리용이라, 트래픽이 인터넷을 지나가는지는 제어하지 않음. “공용 인터넷 통과 금지” 요구를 만족시키는 기능이 아님.
C. 프라이빗 서브넷만으로는 EC2 → S3 트래픽이 NAT를 거쳐 공용 S3 엔드포인트로 나갈 수 있어, 공용 인터넷을 통과할 수 있음. “공용 인터넷 통과 금지”를 보장하려면 VPC 엔드포인트(B)가 필요함.
D. 가상 프라이빗 게이트웨이는 VPN/Direct Connect(온프레미스 연결)용이라, EC2 ↔ S3 트래픽 경로와는 무관함. “공용 인터넷 통과 금지”를 만족시키는 기능이 아님.
Answer: B
요구사항
3계층 웹 애플리케이션 (AWS)
다중 AZ RDS for MySQL = DB 계층, ElastiCache = 캐시 계층
캐싱 전략: 고객이 DB에 항목을 추가할 때 캐시에도 추가·업데이트
캐시 데이터는 항상 DB 데이터와 일치해야 함
위를 만족하는 캐싱 전략 선택
B. Write-through 캐싱 전략 구현
Write-through에서는 쓰기 시 DB와 캐시를 동시에 갱신(또는 DB 쓰기 직후 캐시 갱신)함.
따라서 “고객이 DB에 항목을 추가할 때 캐시의 데이터를 추가하거나 업데이트”하는 요구를 그대로 만족함.
쓰기마다 캐시를 갱신하므로 “캐시의 데이터는 항상 데이터베이스의 데이터와 일치해야 합니다” 조건을 충족함.
틀린 이유
A. 지연 로딩(Lazy loading) 은 읽기 시 캐시 미스면 DB에서 읽어 캐시를 채우는 방식이고, 쓰기 시에는 보통 DB만 쓰고 캐시는 무효화하거나 갱신하지 않음. “DB에 항목 추가할 때 캐시 추가/업데이트”와 “캐시가 항상 DB와 일치”를 보장하는 전략은 write-through(B)임.
C. TTL 은 캐시 항목의 만료 시간을 두는 것이지, “DB 쓰기 시 캐시 추가/업데이트”를 정의하는 전략이 아님. 요구사항을 충족하지 못함.
D. AWS AppConfig 는 애플리케이션 설정·기능 플래그용이라, DB–캐시 데이터 일치를 위한 캐싱 전략이 아님. 요구사항과 무관함.
Answer: B
요구사항
온프레미스 → Amazon S3로 100GB 기록 데이터 마이그레이션
온프레미스 100Mbps 인터넷 연결
S3로 전송되는 데이터 암호화 필요
새 데이터는 Amazon S3에 직접 저장
최소한의 운영 오버헤드로 위를 만족할 방법 선택
B. AWS DataSync로 온프레미스에서 S3 버킷으로 데이터 마이그레이션
100GB를 100Mbps로 전송하면 이론상 약 22시간 수준이라 네트워크 이전이 가능하고, Snowball 같은 물리 장비는 필요하지 않음.
DataSync는 전송 중 암호화(TLS) 를 지원하고, 대상 S3 버킷에 서버 측 암호화(SSE) 를 사용해 “S3로 전송되는 데이터 암호화” 요구를 충족함.
관리형 서비스라 온프레미스에 DataSync 에이전트만 두고 태스크(소스→S3) 를 만들면, 증분 동기화·압축·검증·재시도가 자동으로 처리되어 최소한의 운영 오버헤드로 요구사항을 만족함.
틀린 이유
A. AWS CLI s3 sync로도 이전은 가능하지만, 암호화·재시도·검증·실패 처리 등을 직접 스크립트/운영해야 해 운영 부담이 큼. DataSync(B)가 관리형으로 더 적은 오버헤드로 요구사항을 충족함.
C. Snowball은 TB급 또는 네트워크가 매우 느린/불안정한 경우에 적합함. 100GB·100Mbps면 네트워크 이전이 가능하고, Snowball은 주문·복사·반송·적재 등 운영 오버헤드가 커 “최소한의 운영 오버헤드”에는 DataSync(B)가 더 적합함.
D. IPsec VPN + s3 cp는 VPN 구축·유지보수와 cp/sync 스크립트·실패 처리 등 운영 부담이 큼. DataSync(B)는 VPN 없이 에이전트·TLS로 전송하고 관리형이라 최소 운영 오버헤드 조건에 더 맞음.
Answer: C
요구사항
Windows 컨테이너에서 .NET 6 기반 Windows 작업 컨테이너화
AWS 클라우드에서 해당 작업 실행
10분마다 실행
실행 시간 1~3분
가장 비용 효율적인 방법 선택
C. ECS on Fargate로 작업 실행, 컨테이너 이미지 기반 예약된 작업을 10분마다 실행
Windows 컨테이너는 Lambda에서 지원하지 않음(컨테이너 이미지 Lambda는 Linux만 지원). ECS Fargate는 Windows 컨테이너를 지원하므로 Windows 작업에는 ECS Fargate(C 또는 D)가 맞음.
ECS 예약된 작업(Scheduled Task) 으로 EventBridge(CloudWatch Events) 규칙을 두고 10분마다 ECS RunTask를 호출하면, 별도 상시 실행 인스턴스 없이 10분마다 실행을 구현할 수 있음.
Fargate는 실행한 시간(분) 만 과금되므로, 1~3분만 돌리고 10분마다 한 번씩만 실행하면 비용이 적고, “가장 비용 효율적으로” 충족함.
틀린 이유
A. Lambda의 컨테이너 이미지 지원은 Linux 전용이라 Windows 컨테이너는 실행할 수 없음. 따라서 Windows 작업에는 A는 부적합함.
B. AWS Batch도 Fargate로 10분마다 실행하는 구성은 가능하지만, “10분마다 한 번 실행”하는 단순 스케줄에는 ECS 예약된 작업(C)이 더 직접적이고, 비용·구성 모두 비슷하거나 C가 더 단순함.
D. Windows 작업 스케줄러로 10분마다 실행하려면, 스케줄러를 돌릴 Windows 인스턴스나 상시 실행 태스크가 필요해 24시간 과금이 발생함. EventBridge + ECS RunTask(C)는 스케줄만 서버리스로 처리하므로 C가 더 비용 효율적임.
Answer: A, E
요구사항
많은 독립 AWS 계정 → 통합된 다중 계정 아키텍처로 전환
여러 사업부를 위해 많은 새 AWS 계정 생성 예정
중앙 집중식 회사 디렉터리 서비스로 이 AWS 계정들에 대한 접근을 인증해야 함
위를 만족하기 위해 설계자가 권장해야 할 작업 2개 선택
A. AWS Organizations에서 모든 기능을 켠 새 조직 생성, 조직 안에서 새 AWS 계정 생성
통합된 다중 계정 구조는 AWS Organizations로 구현함. 새 조직을 만들고 모든 기능을 활성화한 뒤, 사업부별 새 계정을 조직 안에서 생성하면 “많은 새 AWS 계정 생성” 요구를 충족함.
E. 조직에서 AWS IAM Identity Center(AWS SSO) 설정, 회사 디렉터리 서비스와 연동
중앙 집중식 회사 디렉터리로 AWS 계정 접근 인증을 하려면 IAM Identity Center(AWS SSO) 를 조직에 두고, 회사 디렉터리 서비스(온프레미스 AD, AWS Directory Service, Azure AD 등)와 연동하면 됨.
IAM Identity Center가 조직 내 계정에 대한 SSO·권한 할당을 담당하므로, “회사 디렉터리로 AWS 계정 액세스 인증” 요구를 만족함.
틀린 이유
B. Cognito는 앱 사용자(모바일·웹) 인증용이라, 회사 디렉터리로 AWS 계정(콘솔/CLI) 접근을 인증하는 용도가 아님. 이 요구에는 IAM Identity Center + 회사 디렉터리 연동(E)이 맞음.
C. SCP는 계정별 권한 상한 설정용이라, “통합 다중 계정 + 회사 디렉터리 인증”을 구현하는 핵심 2가지 작업은 아님. “IAM Identity Center를 Directory Service에 추가”는 E(Identity Center와 회사 디렉터리 연동)에 포함되는 내용이라, 2개 선택지로는 A·E가 적절함.
D. Organizations에는 “인증 메커니즘을 Directory Service로 직접 사용”하도록 설정하는 기능이 없음. 회사 디렉터리로 AWS 계정 접근 인증은 IAM Identity Center(E)를 두고 디렉터리와 연동하는 방식으로 해야 함.
Answer: A
요구사항
오래된 뉴스 영상 비디오 아카이브를 AWS에 저장
비용 최소화
복원이 거의 필요 없는 아카이브
필요할 때 최대 5분 이내에 사용 가능해야 함
가장 비용 효율적인 방법 선택
A. 비디오 아카이브를 Amazon S3 Glacier에 저장하고 긴급 검색(Expedited retrieval) 사용
복원이 거의 필요 없음 + 비용 최소화 → S3 Glacier가 아카이브용으로 저장 비용이 가장 낮은 스토리지 클래스에 가깝고, Standard-IA·One Zone-IA보다 저렴함.
필요할 때 5분 이내 사용 조건을 맞추려면 검색 옵션이 중요함. Expedited retrieval은 1~5분 수준으로 반환되므로 “최대 5분 내” 요구를 충족함.
Standard retrieval은 3~5시간이라 5분 조건을 만족하지 못함. 따라서 Glacier + Expedited(A)가 요구사항에 맞는 가장 비용 효율적인 조합임.
틀린 이유
B. Glacier Standard 검색은 3~5시간 소요되어 “최대 5분 내에 사용 가능” 조건을 만족하지 못함.
C. S3 Standard-IA는 즉시 사용 가능하지만 저장 단가가 Glacier보다 높아, “거의 복원 안 함 + 비용 최소화”에는 Glacier(A)가 더 비용 효율적임.
D. S3 One Zone-IA도 Glacier보다 저장 비용이 높아, 아카이브·비용 최소화에는 Glacier + Expedited(A)가 더 비용 효율적임.
Answer: A
요구사항
AWS에서 3계층 애플리케이션 구축
프레젠테이션 계층: 정적 웹 사이트 제공
논리 계층: 컨테이너화된 애플리케이션
데이터: 관계형 데이터베이스에 저장
배포 단순화 + 운영 비용 절감 목표
A. 정적 콘텐츠는 S3, 컴퓨팅은 ECS+Fargate, DB는 관리형 RDS 클러스터
정적 콘텐츠: S3로 정적 웹사이트 호스팅 → EC2 없이 저비용·관리 부담 적음, 배포 단순.
컨테이너: ECS + Fargate → 서버리스 컨테이너로 EC2 노드 관리·패치·스케일 부담이 없어 운영 비용·배포 복잡도를 줄임.
DB: 관리형 RDS → 패치·백업 등은 AWS가 담당해 운영 비용 절감에 유리함.
“배포 단순화 + 운영 비용 절감”에 맞는 조합은 S3 + ECS Fargate + RDS(A)임.
틀린 이유
B. ECS + EC2는 클러스터 노드(EC2) 를 직접 관리해야 해 Fargate(A)보다 운영 부담·비용이 큼. 정적은 S3가 원천이고 CloudFront는 배포(캐시)용이라, “운영 비용 절감”에는 A가 더 적합함.
C. EKS는 Kubernetes 제어 평면·운영이 필요해 ECS(A)보다 관리 부담·운영 비용이 큼. “배포 단순화·운영 비용 절감”에는 ECS Fargate(A)가 더 적합함.
D. EC2로 정적 호스팅 + EKS + EC2는 EC2·Kubernetes 모두 직접 관리해 운영 비용이 가장 크고 “운영 비용 절감”에 맞지 않음. S3 + ECS Fargate + RDS(A)가 더 적합함.
Answer: C
요구사항
스토리지 솔루션 필요
가용성·확장성이 높아야 함
기본 프로토콜(NFS) 로 AWS 및 온프레미스의 여러 Linux 인스턴스에서 마운트 가능한 파일 시스템
최소 크기 요구 사항 없음
사이트 간 VPN으로 온프레미스 → VPC 접근 구성됨
위를 만족하는 스토리지 선택
C. 탑재 대상이 여러 개인 Amazon EFS
EFS는 NFS 기반 공유 파일 시스템이라, Linux에서 NFS로 마운트할 수 있어 “기본 프로토콜로 여러 Linux 인스턴스에 의해 마운트” 요구를 충족함.
AZ별 mount target을 두면 여러 AZ에서 마운트 가능해 가용성이 높고, 용량이 자동 확장되며 최소 용량이 없어 “가용성·확장성·최소 크기 요구 없음”을 만족함.
사이트 간 VPN으로 온프레미스가 VPC에 붙어 있으면, VPC 내 EFS mount target에 NFS로 접근할 수 있어 “온프레미스 Linux 인스턴스에서 마운트” 요구를 충족함.
틀린 이유
A. FSx는 Lustre/Windows/ONTAP/OpenZFS 등 용도별 제품이고, 많은 옵션에 최소 스토리지가 있으며, Linux 공유 파일 시스템·최소 없음 요구에는 EFS(C)가 더 적합함.
B. EBS Multi-Attach는 블록 스토리지이고 EC2 전용이라, 온프레미스 Linux에서 마운트할 수 없음. “파일 시스템으로 여러 Linux( AWS·온프레미스 )에서 마운트”에는 NFS 기반 EFS(C)가 맞음.
D. 단일 mount target만 두면 한 AZ에만 마운트 대상이 있어 가용성이 떨어짐. “가용성이 높아야 함”에는 여러 AZ에 걸친 mount target(C)이 맞음.
Answer: C
요구사항
AWS Organizations 모든 기능으로 AWS 계정 구성
재무 팀 요구: 멤버 계정의 청구 정보는 루트 사용자를 포함해 누구도 접근할 수 없어야 함
위를 만족하는 솔루션 선택
C. 청구 정보 접근을 거부하는 SCP 생성 후 루트 OU에 연결
SCP(서비스 제어 정책) 는 Organizations(OU/계정) 단위로 적용되며, 해당 OU·계정의 모든 보안 주체(루트 사용자 포함) 에게 최대 권한 상한을 둠.
청구 관련 API·콘솔 접근을 Deny 하는 SCP를 만들고 루트 OU에 붙이면, 그 아래 모든 멤버 계정(및 해당 계정의 루트 사용자)이 청구 정보에 접근할 수 없음.
IAM 정책은 루트 사용자에 적용되지 않아 루트를 제한할 수 없고, 루트 포함 전원 접근 차단은 SCP(C)로만 가능함.
틀린 이유
A. IAM 그룹에 Billing 정책을 붙이는 것은 재무 팀에게 청구 권한을 부여하는 구성이라, “멤버 계정 청구 정보는 누구도(루트 포함) 접근 불가” 요구와 반대임. IAM으로는 루트를 제한할 수 없음.
B. 자격 증명 기반 정책(IAM 정책) 은 루트 사용자에게 적용되지 않아, “루트를 포함해 누구도 청구 정보에 접근 불가”를 보장할 수 없음. 루트 제한은 SCP(C)만 가능함.
D. 통합 결제(Consolidated Billing) 로 바꾸는 것은 결제 방식만 바꾸는 것이며, 청구 정보 접근을 차단하는 기능이 아님. “누구도 접근할 수 없어야 함” 요구를 충족하지 못함.
Answer: C
요구사항
온프레미스 웨어하우스와 연동된 AWS 애플리케이션
Amazon SNS로 주문 메시지를 온프레미스 HTTPS 엔드포인트로 전송
일부 주문 메시지가 수신되지 않음 (전달 실패)
전달되지 않은 메시지를 보관하고 최대 14일 동안 분석해야 함
최소한의 개발 노력으로 위를 만족할 방법 선택
C. 보존 기간 14일인 SQS를 대상으로 하는 SNS 데드 레터 큐(DLQ) 구성
SNS 구독(HTTPS 엔드포인트)에서 전달 실패 시 메시지를 데드 레터 큐(DLQ) 로 보내도록 설정하면, “전달되지 않은 메시지”를 한곳에 모을 수 있음.
SNS 구독 DLQ로 Amazon SQS를 쓰는 것이 AWS에서 지원하는 표준 방식이라, SQS를 DLQ로 두고 메시지 보존 기간을 14일로 설정하면 “최대 14일 동안 보관·분석” 요구를 충족함.
SQS 보존 기간은 최대 14일까지 설정 가능하므로, 별도 개발 없이 구성만으로 “최소한의 개발 노력” 조건을 만족함.
틀린 이유
A. SNS 구독의 전달 실패 시 DLQ로 쓰는 것은 SQS가 일반적이고, Kinesis Data Streams를 SNS DLQ 대상으로 쓰는 구성은 SNS의 표준 DLQ 패턴이 아님. 전달 실패 메시지 보관·14일 분석에는 SQS DLQ(C)가 맞음.
B. 애플리케이션과 SNS 사이에 SQS를 두는 것은 전송 전 버퍼일 뿐, HTTPS 전달이 실패한 메시지는 SNS 쪽에서 발생하므로 이 큐에 쌓이지 않음. “전달되지 않은 메시지”를 모으려면 SNS 구독 DLQ(C)가 맞음.
D. SNS 구독·DLQ의 대상으로 DynamoDB를 직접 지정하는 기능은 없음. SNS가 지원하는 구독/DLQ 대상은 SQS, Lambda, HTTPS 등이며, 전달 실패 메시지 보관에는 SQS DLQ(C)가 맞음.
Answer: B
요구사항
Amazon DynamoDB에 위치·플레이어 데이터·순위표 등 사용자 정보 저장
Amazon S3로 지속적인 백업 구성, 최소한의 코딩
백업이 애플리케이션 가용성에 영향을 주지 않아야 함
백업이 테이블 RCU(읽기 용량 단위) 에 영향을 주지 않아야 함
위를 만족하는 솔루션 선택
B. 연속 백업을 사용해 DynamoDB에서 S3로 직접 내보내기, 테이블에 지정 시간 복구(PITR) 설정
DynamoDB 지정 시간 복구(PITR) 를 켜면 연속 백업(continuous backup) 이 되고, DynamoDB Export to S3 로 테이블 데이터를 S3로 직접 내보내기할 수 있음.
Export to S3 는 테이블의 프로비저닝된 RCU를 사용하지 않고 별도 내부 읽기로 동작하므로, “RCU에 영향을 주지 않아야 함”을 만족함.
가용성: Export는 비동기 작업이라 테이블 서비스 가용성에 영향을 주지 않음.
최소한의 코딩: 콘솔/CLI로 PITR 활성화와 Export 설정만 하면 되고, Lambda·EMR 등 별도 코드가 필요 없음.
틀린 이유
A. EMR + Apache Hive 로 백업하면 클러스터 구성·Hive 작업 등 개발·운영 부담이 크고, DynamoDB에서 읽을 때 RCU를 사용할 수 있어 “최소한의 코딩”·“RCU에 영향 없음” 조건을 충족하지 못함.
C. DynamoDB Streams + Lambda 로 S3에 쓰는 방식은 Lambda 개발·유지보수가 필요해 “최소한의 코딩”에는 네이티브 Export(B)가 더 적합함. Export(B)는 RCU에 영향 없음.
D. Lambda가 주기적으로 테이블을 스캔해 S3로 내보내면 스캔이 테이블 RCU를 소비해 “RCU에 영향을 주지 않아야 함”을 위반함. DynamoDB Export(B)는 RCU를 사용하지 않음.
Answer: A
요구사항
은행용 신용 카드 데이터 유효성 검사 요청을 처리하는 비동기 애플리케이션
안전해야 함
각 요청을 한 번 이상 처리할 수 있어야 함 (at least once)
가장 비용 효율적인 방법 선택
A. Lambda 이벤트 소스 매핑, SQS 표준 큐를 이벤트 소스로, SSE-KMS 암호화, Lambda 실행 역할에 kms:Decrypt 부여
SQS 표준 큐는 메시지당 비용이 FIFO보다 낮아 “가장 비용 효율적으로” 충족함. 한 번 이상 처리(at least once)도 보장함.
신용 카드·은행 데이터이므로 암호화 필요. SSE-KMS로 SQS 메시지를 암호화하면 키 관리·감사 측면에서 안전함.
Lambda가 SQS에서 암호화된 메시지를 읽으려면 복호화 권한이 필요하므로, Lambda 실행 역할에 kms:Decrypt를 부여하는 것이 맞음.
틀린 이유
B. SSE-SQS는 SQS가 관리하는 키를 쓰므로, 은행·신용 카드처럼 강한 보안·키 제어가 필요할 때는 SSE-KMS(A)가 더 적합함. FIFO는 표준 큐보다 비용이 높아 “가장 비용 효율적”에는 표준 큐(A)가 맞음.
C. FIFO 큐는 표준 큐보다 비용이 높고 처리량 제한이 있어, “가장 비용 효율적으로” 충족하려면 표준 큐(A)가 맞음.
D. “Lambda 함수에 대한 암호화 키 호출 권한”은 모호한 표현이고, KMS 복호화 권한은 Lambda 실행 역할에 kms:Decrypt를 부여하는 것이 정확함. 비용·보안 측면에서도 표준 큐 + SSE-KMS + 실행 역할 kms:Decrypt(A)가 정답에 해당함.
Answer: B
요구사항
개발용 여러 AWS 계정 보유
일부 직원이 대형 EC2 인스턴스를 계속 사용해 개발 계정 연간 예산 초과
해당 계정에서 AWS 리소스 생성을 중앙에서 제한하고 싶음
최소한의 개발 노력으로 위를 만족할 방법 선택
B. AWS Organizations로 계정을 OU로 구성, SCP를 정의·연결해 EC2 인스턴스 유형 사용 제한
중앙에서 여러 계정의 리소스 생성을 제한하려면 AWS Organizations로 계정을 OU에 두고, 서비스 제어 정책(SCP) 로 EC2 인스턴스 유형(예: 대형 인스턴스)에 대한 ec2:RunInstances 등을 거부하면 됨.
SCP는 OU/계정에 붙는 정책이라, Lambda·EventBridge·템플릿 등 별도 코드·인프라 없이 JSON 정책만 작성·연결하면 되어 최소한의 개발 노력으로 요구사항을 충족함.
API 수준에서 생성 자체를 막기 때문에, 인스턴스가 잠깐이라도 뜨는 것을 막는 사전 제어가 가능함.
틀린 이유
A. Systems Manager 템플릿·승인 프로세스는 템플릿 개발·운영이 필요하고, 직원이 콘솔/CLI로 EC2를 직접 띄우면 제한이 우회될 수 있음. “중앙에서 제한”과 “최소 개발 노력”에는 SCP(B)가 더 적합함.
C. EventBridge + Lambda로 생성 후 중지하는 방식은 이미 인스턴스가 생성된 뒤에 동작해, 그동안 비용이 발생하고 Lambda·규칙 개발이 필요함. “최소 개발 노력”과 “중앙 제한”에는 SCP로 생성 차단(B)이 더 적합함.
D. Service Catalog로 허용 인스턴스만 제공하려면 제품·포트폴리오·권한 구성 등 개발·설정 부담이 큼. “최소한의 개발 노력”에는 SCP만으로 제한(B)이 더 적합함.
Answer: D, E, F
요구사항
AI로 고객 서비스 통화 품질 확인
4개 언어(영어 포함)로 통화, 추가 언어 예정
ML 모델을 정기적으로 유지보수할 리소스 없음 → 관리형 서비스 사용
고객 서비스 통화 녹음에서 서면 감정 분석 보고서 작성
통화 녹음 텍스트는 영어로 번역되어야 함
위를 만족하는 단계 조합 3개 선택
D. Amazon Transcribe로 모든 언어의 오디오 녹음을 텍스트로 변환
오디오 → 텍스트는 음성 인식(Speech-to-Text). Amazon Transcribe가 다국어 오디오를 텍스트로 변환하는 AWS 관리형 서비스임.
“고객 서비스 통화 녹음”을 텍스트로 바꾸는 단계는 D(Transcribe) 임.
E. Amazon Translate로 모든 언어의 텍스트를 영어로 번역
다국어 텍스트 → 영어는 번역. Amazon Translate가 다국어 텍스트를 영어로 번역하는 AWS 관리형 서비스임.
“통화 녹음 텍스트를 영어로 번역”하는 단계는 E(Translate) 임.
F. Amazon Comprehend로 감정 분석 보고서 생성
텍스트 감정 분석 및 보고서 작성에는 Amazon Comprehend(감정, 엔티티 등 NLP)를 사용함.
“서면 감정 분석 보고서 작성” 단계는 F(Comprehend) 임.
흐름: D(녹음 → 텍스트) → E(텍스트 → 영어) → F(영어 텍스트 → 감정 분석 보고서). Transcribe·Translate·Comprehend는 모두 관리형이라 ML 모델 유지보수가 필요 없음.
틀린 이유
A. Amazon Comprehend는 텍스트 기반 NLP(감정·엔티티 등)용이라, 오디오를 영어로 번역하는 기능은 없음. 오디오→텍스트는 Transcribe(D), 번역은 Translate(E)임.
B. Amazon Lex는 대화형 봇(챗봇·음성 봇)용이라, 감정 분석 보고서 생성에는 Comprehend(F)가 맞음.
C. Amazon Polly는 텍스트→음성(TTS) 용이라, 음성→텍스트가 아님. 오디오를 텍스트로 바꾸는 단계는 Transcribe(D)임.
Answer: D
요구사항
EC2 인스턴스로 내부 시스템 호스팅
배포 중 AWS CLI로 EC2 인스턴스 종료 시도
403 (Access Denied) 발생
정책: Allow ec2:TerminateInstances on * / Deny ec2:TerminateInstances with Condition NotIpAddress : aws:SourceIp : 192.0.2.0/24, 203.0.113.0/24
실패 원인 선택
D. EC2 인스턴스 종료 요청이 CIDR 192.0.2.0/24 또는 203.0.113.0/24에서 시작되지 않음
Deny 문의 Condition은 NotIpAddress : aws:SourceIp : 192.0.2.0/24, 203.0.113.0/24 이다.
즉, 요청 소스 IP가 위 두 CIDR 밖이면 Deny가 적용된다. Allow가 있어도 Deny가 우선하므로 403이 난다.
CLI를 실행하는 관리자 PC/서버의 공인 IP가 192.0.2.0/24, 203.0.113.0/24가 아니면 이 Deny에 걸려 종료 요청이 거부된다. 따라서 실패 원인은 D이다.
틀린 이유
A. EC2 인스턴스에는 리소스 기반 정책을 붙일 수 없다. IAM 정책은 사용자/역할/그룹에 붙는 identity 기반 정책만 있고, 여기서 403을 만드는 것은 역할에 붙은 정책의 Deny + Condition이다.
B. IAM 역할/사용자 정책에는 Principal을 넣지 않는다. Principal은 리소스 기반 정책·신뢰 정책 등에서 쓰이므로, 403 원인으로 “주체 미지정”은 해당하지 않는다.
C. Allow 문에 ec2:TerminateInstances(또는 문항상 TerminateInstance)가 있어 Action 자체는 부여되어 있다. 403은 Allow가 아니라 Deny의 Condition(IP 제한) 때문에 발생한다.
Answer: C
요구사항
내부 감사 진행
Lake Formation 데이터 레이크와 연결된 S3 버킷에 민감한 고객·직원 데이터가 없도록 해야 함
PII(개인 식별 정보) 및 여권 번호·신용 카드 번호 등 금융 정보를 검색해야 함
위를 만족하는 솔루션 선택
C. Amazon Macie로 필요한 데이터 유형에 대한 관리형 식별자를 사용하는 데이터 검색 작업 실행
Amazon Macie는 S3에 저장된 민감한 데이터(PII, 금융 정보 등)를 자동으로 탐지하는 서비스임.
관리형 식별자(managed identifiers) 로 PII, 여권 번호, 신용 카드 번호 등 유형을 지정해 데이터 검색(discovery) 작업을 실행하면, Lake Formation과 연결된 S3 버킷에서 해당 데이터 존재 여부를 파악할 수 있음.
“PII·금융 정보 검색” 및 “민감 데이터 포함 여부 확인” 요구를 Macie 데이터 검색(C)으로 충족함.
틀린 이유
A. AWS Audit Manager는 컴플라이언스 감사(증거 수집, PCI DSS 등 프레임워크 매핑)용이라, S3 객체 내용에서 PII·신용 카드 번호 등을 탐지·검색하는 기능은 없음. “PII·금융 정보 검색”에는 Macie(C)가 맞음.
B. S3 Inventory는 객체 메타데이터(크기, 수정일 등)만 제공하고, 객체 내용을 스캔하지 않음. Athena로 인벤토리를 쿼리해도 내용 안의 PII·금융 정보를 찾을 수 없음. “PII·금융 정보 검색”에는 Macie(C)가 맞음.
D. S3 Select는 객체 내부 데이터 일부 조회(CSV/JSON 등 쿼리)용이라, 민감 데이터 유형을 자동으로 식별·검색하는 기능이 없음. “PII·금융 정보 검색”에는 Macie(C)가 맞음.
Answer: B, D
요구사항
온프레미스 서버에서 애플리케이션 호스팅
저장 용량 부족
애플리케이션이 블록 스토리지와 NFS 스토리지 둘 다 사용
기존 애플리케이션 재설계 없이, 로컬 캐싱을 지원하는 고성능 솔루션 필요
위를 만족하는 작업 조합 2개 선택
B. NFS 스토리지를 대체할 AWS Storage Gateway 파일 게이트웨이 배포
File Gateway는 NFS(또는 SMB) 로 공유를 제공하고, 데이터는 S3에 저장되며 로컬 캐시로 자주 쓰는 데이터를 캐싱함.
기존 NFS 사용 방식을 유지한 채 NFS 스토리지만 File Gateway로 바꾸면, 재설계 없이 저장 용량 확장 + 로컬 캐싱으로 성능을 확보할 수 있음.
D. 블록 스토리지를 대체할 AWS Storage Gateway 볼륨 게이트웨이 배포
Volume Gateway는 iSCSI 블록 볼륨을 제공하고, 데이터는 S3에 저장되며 로컬 캐시로 I/O를 가속함.
기존 블록 스토리지 사용 방식을 유지한 채 블록 스토리지만 Volume Gateway로 바꾸면, 재설계 없이 저장 용량 확장 + 로컬 캐싱으로 고성능을 맞출 수 있음.
B + D로 NFS·블록 둘 다 대체하고, 둘 다 로컬 캐싱을 지원하므로 요구사항을 충족함.
틀린 이유
A. S3를 온프레미스에 “파일 시스템으로 탑재”하는 방식은, NFS·블록 둘 다를 재설계 없이 대체하면서 로컬 캐싱을 제공하는 표준 방법이 아님. NFS 대체에는 File Gateway(B), 블록 대체에는 Volume Gateway(D)가 맞음.
C. Snowball Edge는 데이터 이전·엣지 용도에 가깝고, “지속적인 저장 용량 확장 + 로컬 캐싱”에는 Storage Gateway(B, D)가 더 적합함.
E. EFS는 AWS VPC 안의 서비스라 온프레미스에 “EFS 볼륨을 배포해 탑재”하는 구성이 아니며, 온프레미스 쪽 로컬 캐싱을 제공하는 방식도 Storage Gateway와 다름. NFS·블록 대체 + 로컬 캐싱에는 B, D가 맞음.
Answer: C
요구사항
동일 리전 S3 버킷에서 대량 읽기·쓰기하는 서비스
VPC 프라이빗 서브넷의 EC2에 배포
현재 퍼블릭 서브넷 NAT 게이트웨이를 통해 S3와 통신
데이터 출력(egress) 비용을 줄이고 싶음
가장 비용 효율적인 방법 선택
C. VPC 게이트웨이 엔드포인트(S3용) 프로비저닝, 프라이빗 서브넷 라우팅 테이블에서 S3 트래픽을 게이트웨이 엔드포인트로 보내도록 구성
S3용 게이트웨이 VPC 엔드포인트를 두면, 프라이빗 서브넷의 EC2 → S3 트래픽이 NAT 게이트웨이·인터넷을 거치지 않고 AWS 내부 네트워크로만 전달됨.
NAT를 타지 않으므로 NAT 게이트웨이 데이터 처리 요금이 S3 트래픽에 대해 발생하지 않고, 동일 리전 S3와의 통신은 게이트웨이 엔드포인트 경로로 추가 데이터 전송 요금 없이 처리됨.
게이트웨이 엔드포인트는 시간당·데이터 처리 요금이 없어 “데이터 출력 비용 절감”에 가장 비용 효율적임.
틀린 이유
A, B. NAT 인스턴스(EC2) 를 쓰면 S3 트래픽이 여전히 NAT를 경유해 EC2 비용·데이터 전송 비용이 듦. S3 트래픽을 NAT 밖으로 빼는 게이트웨이 엔드포인트(C)보다 비용 효율이 떨어짐.
D. NAT 게이트웨이를 하나 더 두면 시간당·데이터 처리 요금이 늘어나 비용이 증가함. “데이터 출력 비용 절감”에는 S3 트래픽을 게이트웨이 엔드포인트로 보내는 C가 맞음.
Answer: A
요구사항
Amazon S3에 고해상도 사진 저장
앱 변경 최소화를 위해 S3 객체의 최신 버전으로 저장(버전 관리 사용)
가장 최근 버전 2개만 유지하면 됨
S3 비용을 줄이고 싶음, S3 버킷이 비용이 큼
최소한의 운영 오버헤드로 S3 비용을 줄일 방법 선택
A. S3 수명 주기로 만료된 객체 버전을 삭제하고, 최신 2개 버전만 유지
S3 수명 주기 규칙에서 NoncurrentVersionExpiration을 사용해 이전 버전(noncurrent) 을 자동 삭제하고, NewerNoncurrentVersions 등으로 최신 2개 버전만 남기도록 설정할 수 있음.
한 번 설정하면 자동으로 이전 버전이 정리되어 운영 작업이 거의 없음 → “최소한의 운영 오버헤드” 충족.
오래된 버전을 줄이면 저장 용량·비용이 줄어 “S3 비용 절감”에 맞음.
틀린 이유
B. Lambda로 이전 버전을 찾아 삭제하는 방식은 코드 작성·스케줄·유지보수가 필요해 운영 오버헤드가 큼. 수명 주기(A)가 더 단순하고 오버헤드가 적음.
C. S3 Batch Operations는 일회성·수동 실행 용도에 가깝고, 주기적으로 돌리려면 작업 스케줄·관리가 필요함. 수명 주기(A)는 설정만으로 지속 자동 적용되어 운영 오버헤드가 더 적음.
D. 버전 관리 비활성화를 하면 여러 버전을 가질 수 없어 “가장 최근 버전 2개만 유지” 요구를 만족할 수 없음. “최신 2개 버전만 유지”하려면 버전 관리 유지 + 수명 주기로 이전 버전 삭제(A)가 맞음.
Answer: D
요구사항
1Gbps AWS Direct Connect 연결 비용 최소화
평균 연결 사용률이 10% 미만
보안을 해치지 않으면서 비용 절감할 방법 선택
D. AWS Direct Connect 파트너에 문의해 기존 AWS 계정용 200Mbps 호스팅 연결 주문
사용률 10% 미만이면 1Gbps 대역이 거의 쓰이지 않으므로, 200Mbps 등 작은 포트로 다운사이징하면 비용을 줄일 수 있음.
호스팅 연결(Hosted Connection) 은 Direct Connect 파트너를 통해 주문하는 방식이며, 200Mbps는 1Gbps보다 저렴한 포트임.
기존 AWS 계정에 200Mbps 호스팅 연결을 붙이는 것은 보안 구조를 바꾸는 것이 아니라 포트 용량만 줄이는 것이므로 “보안을 손상시키지 않으면서” 비용 절감에 맞음.
틀린 이유
A. 1Gbps 연결을 유지하면 다운사이징 효과가 없어 비용이 그대로임. “다른 계정과 연결 공유”는 트래픽 격리·보안 설계가 필요해, “비용 최소화 + 보안 유지”를 단순히 만족하지 못함.
B. Direct Connect 물리 연결(전용/호스팅)은 Management Console에서 새 연결을 ‘설정’하는 것이 아니라, 전용은 AWS에, 호스팅은 파트너를 통해 주문하는 구조임. 200Mbps 호스팅은 파트너 주문(D)이 맞음.
C. 1Gbps를 주문하면 용량을 줄이지 않아 비용 절감이 되지 않음. 사용률 10% 미만이면 200Mbps(D)로 줄이는 것이 비용 절감에 맞음.
Answer: A, D
요구사항
온프레미스 여러 Windows 파일 서버 보유
Amazon FSx for Windows File Server로 파일 마이그레이션·통합
액세스 권한이 바뀌지 않도록 파일 권한 보존 필요
위를 만족하는 솔루션 2개 선택
A. 온프레미스에 DataSync 에이전트 배포, FSx for Windows로 전송하는 DataSync 작업 예약
AWS DataSync는 SMB(Windows 공유) 를 소스로, FSx for Windows File Server를 대상으로 지원하며, 파일 권한(ACL·소유권) 등 메타데이터를 보존할 수 있음.
온프레미스에 DataSync 에이전트를 두고, Windows 파일 서버 공유를 소스, FSx for Windows를 대상으로 하는 DataSync 작업을 예약하면 “파일 권한 보존”과 “마이그레이션·통합”을 동시에 만족함.
D. Snowcone 주문 후 온프레미스 네트워크에 연결, 디바이스에서 DataSync 에이전트 실행, FSx for Windows로 전송하는 DataSync 작업 예약
AWS Snowcone에서 DataSync 에이전트를 실행할 수 있어, Snowcone을 온프레미스 네트워크에 두고 에이전트가 Windows 공유를 읽어 FSx for Windows로 전송하는 구성이 가능함.
전송은 DataSync가 담당하므로 파일 권한 보존이 되고, “액세스 권한이 변경되지 않도록” 요구를 충족함.
틀린 이유
B. AWS CLI로 Windows 공유를 S3에 복사하면 Windows 파일 권한(NTFS·ACL) 이 S3 메타데이터로 그대로 유지되지 않음. S3를 거친 뒤 DataSync로 FSx로 보내도 원래 권한 보존을 보장하기 어려움.
C. 드라이브를 제거해 AWS로 보내 S3로 가져오기하는 방식도 S3가 Windows 권한을 그대로 보존하지 않아 “파일 권한 보존” 요구를 충족하지 못함.
E. Snowball에 CLI로 복사 후 S3로 적재하는 흐름은 S3를 거치면서 Windows 권한이 보존되지 않음. “파일 권한 보존”에는 DataSync로 소스(Windows 공유)에서 FSx로 직접 전송(A, D)이 맞음.
'자격증' 카테고리의 다른 글
| AWS SAA-C03 Dump 551-600 (0) | 2026.02.03 |
|---|---|
| AWS SAA-C03 Dump 501-550 (0) | 2026.02.02 |
| AWS SAA-C03 Dump 401-450 (0) | 2026.02.02 |
| AWS SAA-C03 Dump 351-400 (0) | 2026.02.01 |
| AWS SAA-C03 Dump 301-350 (1) | 2026.02.01 |
