정답 · 해설

해설

【핵심 용어】 ▸ AWS Control Tower Proactive Controls — CloudFormation 배포 전에 규정 위반 리소스 생성을 차단하는 예방 통제(CloudFormation Hooks 기반) ▸ Detective Controls — 이미 배포된 리소스의 위반을 사후 탐지 (사전 차단 불가) ▸ SCP / AWS Config — 액션 차단 / 사후 준수 평가 (프로비저닝 사전 검증엔 부적합) 【정답 포인트】 ▸ "CloudFormation 스택이 위반 IAM/공인 IP EC2를 배포하는 것을 막음" → 배포 전 검증·차단하는 proactive control이 정확히 부합 ▸ Control Tower가 이미 활성화되어 있어 통제 적용이 자연스러움 【오답 체크】 (B) detective control은 배포 후 탐지만 하므로 "배포 차단" 요건 미충족. (C) Config + SSM으로 사후 삭제하는 방식은 예방이 아니라 사후 대응이며 운영 부담 큼. (D) SCP는 API 액션 차단은 되나 "인라인 정책/‘*’ 포함" 같은 리소스 속성 세부 검증엔 부적합. 【시험 포인트】 "CloudFormation 배포 전 규정 위반 차단" → Control Tower Proactive Controls(사전 예방).

해설

【핵심 용어】 ▸ EC2 Auto Scaling (다중 AZ) — 수요에 따라 인스턴스를 자동 확장·축소, 여러 AZ 배치로 고가용성 확보 ▸ Application Load Balancer — 퍼블릭 서브넷에서 트래픽을 여러 인스턴스에 분산 ▸ 수직 확장(대형 인스턴스) / NAT Gateway — 단일 장애점 유지 / 아웃바운드용 (고가용성·확장성 요건과 무관) 【정답 포인트】 ▸ (B) 다중 AZ Auto Scaling → 수평 확장 + 고가용성 (재작성 불필요) ▸ (E) 퍼블릭 서브넷 ALB → 트래픽 분산으로 확장성·가용성 완성, 애플리케이션 코드 변경 없이 구성 【오답 체크】 (A) 컴퓨팅 최적화 대형 인스턴스로 교체(수직 확장)는 여전히 단일 인스턴스라 고가용성 없음. (C) NAT 게이트웨이는 프라이빗 서브넷 아웃바운드용이지 웹 요청 처리·확장과 무관. (D) 메모리 최적화 대형 인스턴스 교체도 단일 장애점 유지로 요건 미충족. 【시험 포인트】 "고가용성 + 확장성 + 재작성 없이" → 다중 AZ Auto Scaling + ALB(수평 확장), 수직 확장은 오답.

해설

【핵심 용어】 ▸ AWS KMS — 암호화 키 관리 서비스, Lambda 환경 변수 암호화에 사용 ▸ Lambda Encryption Helpers — 환경 변수를 KMS 키로 저장 시 암호화하고 실행 시 복호화, 콘솔에서 평문 노출 방지 ▸ CloudHSM / ACM — 전용 HSM / 인증서 (환경 변수 암호화 표준 방식 아님) 【정답 포인트】 ▸ "개발자가 환경 변수를 평문으로 보지 못하게" → KMS 키 + Lambda 암호화 도우미로 저장 시 암호화 ▸ 권한 있는 함수만 복호화, 콘솔에는 암호화된 값 표시 【오답 체크】 (A) EC2로 배포 전환은 문제 해결이 아니라 아키텍처 회피, 요건과 무관. (B) CloudHSM로 SSL 암호화는 Lambda 환경 변수 보호 표준 방식이 아니며 과도. (C) ACM 인증서는 TLS용이지 환경 변수 암호화 용도가 아님. 【시험 포인트】 "Lambda 환경 변수 평문 노출 방지" → KMS 키 + encryption helpers.

해설

【핵심 용어】 ▸ Amazon Cognito User Pool — 사용자 인증(가입/로그인) 디렉터리, 수백만 사용자 확장 ▸ API Gateway REST API + Cognito Authorizer — Cognito 사용자 풀 토큰으로 API 접근을 검증하는 관리형 인증 연동 ▸ Identity Pool — AWS 리소스 임시 자격증명 부여(인가)용, 사용자 "인증" 저장소 아님 【정답 포인트】 ▸ "사용자를 인증 서비스로 검증 후 REST API 접근" + "운영 효율 최대" → Cognito User Pool + API Gateway REST API의 Cognito authorizer가 코드 없이 관리형 연동 【오답 체크】 (B) Identity pool은 인증 사용자 디렉터리가 아니라 자격증명 페더레이션/인가용이라 사용자 인증 저장소로 부적합. (C) Lambda authorizer는 커스텀 인증 코드를 작성·유지해야 해 운영 효율이 떨어짐. (D) IAM 사용자로 수백만 앱 사용자를 인증하는 것은 IAM 설계에 부적합·비확장. 【시험 포인트】 "앱 사용자 인증 + API 보호" → Cognito User Pool + API Gateway authorizer. User Pool=인증, Identity Pool=인가.

해설

【핵심 용어】 ▸ Amazon EventBridge — KMS DeleteKey 같은 API 이벤트에 반응해 자동화 실행 ▸ AWS Systems Manager Automation Runbook — 이벤트 발생 시 실행되는 자동화, KMS 키 삭제 예약을 취소(CancelKeyDeletion) ▸ Amazon SNS — 관리자에게 이메일 알림 전송 【정답 포인트】 ▸ "KMS 키 삭제 실수 방지 + 관리자 이메일 알림" + "최소 운영" → EventBridge 규칙이 DeleteKey에 반응 → SSM Automation 런북으로 삭제 취소 + SNS 알림 ▸ 커스텀 코드 없이 관리형 구성 요소만 연결 【오답 체크】 (A) AWS Config 규칙을 EventBridge 타깃으로 삭제 취소하는 흐름은 실제 동작 방식이 아님(Config는 평가지 취소 실행 주체 아님). (B) Lambda 커스텀 로직 + CloudWatch 알람은 코드 유지 부담이 커 최소 운영에 반함. (D) CloudTrail + 지표 필터 + 알람은 삭제를 알리기만 하고 실제로 삭제를 취소(방지)하지 못함. 【시험 포인트】 "이벤트 반응 + 자동 조치(취소) + 알림, 최소 코드" → EventBridge + SSM Automation runbook + SNS.

해설

【핵심 용어】 ▸ AWS Lambda — 서버리스, 실행 시간만 과금, 유휴 시 비용 0 (간헐·단시간 작업에 최적) ▸ Amazon EventBridge — 리포트 요청 이벤트로 Lambda 트리거 ▸ EC2 On-Demand/Spot / ECS — 상시 또는 기동 비용·관리 부담 (간헐 실행에 비효율) 【정답 포인트】 ▸ "월말 1주에만, 리포트당 10분 미만" + "요청 시 최단 시간 + 최소 비용" → Lambda(15분 한도 내)로 요청 즉시 실행, 유휴 비용 없음 ▸ EventBridge 규칙으로 요청 시에만 함수 실행 【오답 체크】 (A) On-Demand를 월말 1주 상시 가동은 유휴 비용 발생으로 비효율. (C) ECS는 스케줄 실행 가능하나 Lambda 대비 관리·기동 비용이 크고 짧은 작업엔 과함. (D) Spot을 1주 상시 가동도 유휴 비용 발생 + 중단 위험으로 부적합. 【시험 포인트】 "짧고(≤15분) 드문 작업 + 요청 즉시 + 최소 비용" → Lambda + EventBridge.

해설

【핵심 용어】 ▸ Amazon FSx for Lustre (scratch) — HPC용 고성능 병렬 파일 시스템, scratch 스토리지로 초고속 임시 처리 ▸ Elastic Fabric Adapter (EFA) — 낮은 지연·고대역 노드 간 통신, 긴밀 결합(tightly coupled) HPC/MPI 최적화 ▸ Global Accelerator / CloudFront / Elastic Beanstalk — 네트워크 가속·CDN·앱 배포 (HPC 스토리지/노드 통신 최적화 아님) 【정답 포인트】 ▸ (B) FSx for Lustre scratch → HPC 워크로드 고성능 스토리지 최적화 ▸ (D) EFA → 노드 간 저지연 통신으로 긴밀 결합 HPC 네트워킹 최적화 【오답 체크】 (A) Global Accelerator 커스텀 라우팅은 사용자 트래픽 가속용이지 HPC 노드 간 통신 최적화가 아님. (C) CloudFront는 콘텐츠 배포 CDN으로 HPC와 무관. (E) Elastic Beanstalk는 웹 앱 배포 관리 도구로 HPC 성능 최적화와 무관. 【시험 포인트】 "긴밀 결합 HPC" → 네트워킹=EFA, 스토리지=FSx for Lustre(scratch).

해설

【핵심 용어】 ▸ Amazon Rekognition — 사전 학습된 이미지 분석 서비스, 콘텐츠 모더레이션(부적절 이미지 탐지)을 ML 학습 없이 제공 ▸ AWS Lambda (function URL) — 업로드 시 Rekognition 호출을 트리거 ▸ SageMaker / Comprehend / Rekognition Video — 모델 학습 / 텍스트 분석 / 동영상 분석 (요건과 불일치) 【정답 포인트】 ▸ "부적절 콘텐츠 사진 차단" + "ML 모델 학습 불필요" → 사전 학습형 Rekognition(이미지)로 즉시 탐지 ▸ Lambda 함수 URL로 업로드 시 호출 【오답 체크】 (A) SageMaker Autopilot은 모델을 학습시키는 방식이라 "학습 불필요" 요건 위반. (C) CloudFront 함수 + Comprehend는 텍스트 분석용이고 이미지 콘텐츠 탐지에 부적합. (D) Rekognition Video는 동영상용이라 사진(정지 이미지) 검사에 부적합. 【시험 포인트】 "이미지 콘텐츠 모더레이션 + 학습 없이" → Amazon Rekognition(이미지), 동영상은 Rekognition Video.

해설

【핵심 용어】 ▸ Root User MFA — 루트 사용자에 다중 MFA 디바이스 등록 가능(백업 목적) ▸ Multiple MFA devices — 하나를 분실해도 다른 등록 디바이스로 로그인 유지 ▸ 백업 관리자/IAM 사용자 — 루트 접근 상실 문제를 해결하지 못함 【정답 포인트】 ▸ "MFA 분실 시 루트 접근 상실 방지" → 루트 사용자에 여러 MFA 디바이스를 미리 등록해 하나 분실해도 다른 디바이스로 접근 【오답 체크】 (A) 백업 관리자 계정은 루트 자체 접근 복구와 무관. (C) 접근 불가 후 새 관리자 생성은 이미 루트 접근이 안 되는 상황이라 성립 불가. (D) 다른 IAM 사용자에 관리자 정책 부착도 루트 접근 상실 자체를 해결하지 못함. 【시험 포인트】 "루트 MFA 분실 대비" → 루트 사용자에 다중 MFA 디바이스 등록(백업).

해설

【핵심 용어】 ▸ Amazon SNS — 발행/구독(pub-sub) 메시징, HTTP/HTTPS 엔드포인트 구독 지원, 다수 구독자에 팬아웃 ▸ Subscription — 신규 파트너를 토픽에 구독시키면 자동으로 알림 수신, 빠른 확장 ▸ Step Functions / Kinesis / Timestream — 워크플로 / 스트림 / 시계열 DB (파트너 추가 확장·HTTP 통지에 부적합) 【정답 포인트】 ▸ "파트너 HTTP 엔드포인트로 사용자 ID 통지" + "매일 수백 파트너를 빠르고 확장성 있게 추가" + "최소 구현" → SNS 토픽에 파트너를 HTTP 구독으로 추가하고 발행 ▸ 신규 파트너는 구독만 추가하면 되어 코드 변경 최소 【오답 체크】 (A) Timestream + Lambda로 파트너 목록을 관리·개별 전송하는 방식은 구현·유지 부담이 큼. (C) Step Functions에 파트너마다 태스크를 만드는 것은 파트너 추가 시마다 워크플로 수정 필요로 비확장. (D) Kinesis Data Streams는 프로듀서/컨슈머 앱 구현이 필요하고 HTTP 팬아웃 통지엔 부적합. 【시험 포인트】 "다수 구독자에게 HTTP 팬아웃 + 구독자 빠른 추가" → SNS 토픽(pub-sub).

해설

【핵심 용어】 ▸ Amazon Comprehend — 사전 학습된 NLP 서비스, 엔티티 추출(재료명 등)을 ML 지식 없이 수행 ▸ S3 Event Notifications + Lambda — 객체 업로드(PutObject) 시 처리 함수 트리거 ▸ Forecast / Polly / SageMaker — 예측 / TTS / 모델 개발 (재료명 추출·무ML 요건과 불일치) 【정답 포인트】 ▸ "레시피 텍스트에서 재료명 추출" + "ML 지식 없는 팀" + "비용 효율" → 관리형 NLP Comprehend로 엔티티 추출 ▸ S3 이벤트로 Lambda 트리거 후 결과를 DynamoDB에 저장 【오답 체크】 (B) Forecast는 시계열 예측 서비스로 텍스트 재료명 추출과 무관. (C) Polly(TTS) + 직원 수작업 청취는 자동화·비용 효율 요건에 반함. (D) SageMaker는 모델 개발이 필요해 "ML 지식 없음" 요건 위반. 【시험 포인트】 "텍스트에서 엔티티/핵심어 추출 + ML 학습 없이" → Amazon Comprehend.

해설

【핵심 용어】 ▸ VPC Peering — 두 VPC(계정 간 포함)를 프라이빗 네트워크로 연결 ▸ Lambda in VPC + cross-account EFS — VPC 내 Lambda가 다른 계정 EFS를 네트워크 경로로 마운트/접근 ▸ DataSync / Lambda layer — 데이터 복제 / 코드 계층 (실시간 확장 접근·비용 요건과 불일치) 【정답 포인트】 ▸ "기본 계정 VPC의 Lambda가 보조 계정 EFS 접근" + "파일 증가에 따라 확장 + 비용 효율" → 두 계정 VPC를 피어링해 EFS를 직접 마운트·접근(데이터 복제 불필요) 【오답 체크】 (A) 새 EFS 생성 + DataSync 복제는 데이터 중복·복제 비용이 발생하고 실시간 접근이 아님. (C) 보조 계정에 두 번째 Lambda를 두고 호출하는 방식은 추가 함수 관리 부담과 복잡성 증가. (D) EFS 데이터를 Lambda 레이어로 옮기는 것은 레이어 크기 제한·정적 특성상 확장 요건 미충족. 【시험 포인트】 "계정 간 VPC 리소스(EFS) 직접 접근" → VPC 피어링으로 프라이빗 연결.

해설

【핵심 용어】 ▸ Client-Side Encryption — 데이터 센터(온프레미스)에서 미리 암호화 후 S3 업로드, 키를 AWS 외부에서 관리 ▸ 전송 중 암호화(TLS/HTTPS) — S3 API 호출 시 기본 적용 ▸ SSE-KMS(customer managed/AWS managed)/SSE-S3 — AWS가 키를 관리 (AWS 외부 키 관리 요건 위반) 【정답 포인트】 ▸ "암호화 키를 AWS 클라우드 외부에서 관리" → 데이터 센터에서 클라이언트 측 암호화 후 업로드(키가 AWS로 넘어가지 않음) ▸ 전송 중은 TLS, 저장 시는 이미 암호화된 상태로 저장 【오답 체크】 (A) SSE-KMS 고객 관리형 키도 키가 AWS KMS 내부에 존재해 "AWS 외부 키 관리" 요건 위반. (B) SSE-KMS AWS 관리형 키는 AWS가 키를 전적으로 관리하므로 요건 위반. (C) 기본 SSE도 AWS가 키를 관리하므로 외부 키 관리 요건 미충족. 【시험 포인트】 "암호화 키를 AWS 외부에서 관리" → 클라이언트 측 암호화(업로드 전 암호화).

해설

【핵심 용어】 ▸ Amazon API Gateway + AWS Lambda — 결제 알림 수신 및 기본 검증(짧은 이벤트)에 서버리스로 적합 ▸ Amazon ECS on AWS Fargate — 장시간 실행·컴퓨팅/메모리 조정 가능한 서버리스 컨테이너 (인프라 관리 불필요) ▸ EKS Anywhere / self-managed nodes / EC2 Spot — 인프라 관리 부담 (관리 불필요 요건 위반) 【정답 포인트】 ▸ "모바일 결제 알림 기본 검증" → API Gateway + Lambda(짧은 검증) ▸ "백엔드는 장시간 실행 + CPU/메모리 조정 + 인프라 관리 불필요" → ECS Fargate(서버리스 컨테이너) 【오답 체크】 (A) EKS Anywhere 독립 클러스터는 온프레미스·인프라 관리가 필요해 관리 불필요 요건 위반. (B) EKS self-managed nodes는 노드 관리 부담이 커 운영 오버헤드 큼. (C) EC2 Spot Fleet는 인프라 관리·중단 위험으로 관리 불필요·안정성 요건에 반함. 【시험 포인트】 "짧은 검증=Lambda + 장시간·리소스 조정·무관리=Fargate", 컨테이너 서버리스는 Fargate.

해설

【핵심 용어】 ▸ Amazon Cognito User Pool — 사용자 인증 디렉터리, 수백만 사용자 확장 ▸ Risk-Based Adaptive Authentication — 비정상 위치/IP/디바이스 로그인 시 위험 감지해 MFA를 자동 요구 ▸ Identity Pool / IAM / IAM Identity Center — 인가·조직 SSO (적응형 리스크 인증 미제공/부적합) 【정답 포인트】 ▸ "일관되지 않은 위치·IP·디바이스에서 2단계 인증 유발" → Cognito User Pool의 리스크 기반 적응형 인증 + MFA가 정확히 해당 ▸ "수백만 사용자 확장" → Cognito User Pool 【오답 체크】 (B) Identity pool은 인가용이며 적응형(위험 기반) 인증 기능이 없음. (C) IAM 사용자로 수백만 앱 사용자 인증은 부적합하고 적응형 인증도 불가. (D) IAM Identity Center는 조직/직원 SSO용으로 대규모 앱 사용자 적응형 인증 시나리오에 부적합. 【시험 포인트】 "위험 기반(위치/디바이스) 조건부 MFA + 대규모 사용자" → Cognito User Pool 적응형 인증.

해설

【핵심 용어】 ▸ AWS Glue — 서버리스 ETL, 매일 데이터 변환·적재 작업 수행 ▸ Amazon Redshift Serverless — 서버리스 MPP(대규모 병렬 처리) 데이터 웨어하우스 ▸ Amazon Redshift ML — SQL 명령으로 ML 모델 생성·학습 ▸ EMR / Aurora / Athena — 클러스터 관리 / OLTP / 쿼리 엔진 (서버리스·MPP·SQL ML 조합에 부적합) 【정답 포인트】 ▸ "매일 변환·적재(서버리스 우선)" → Glue 서버리스 ETL ▸ "MPP 데이터 웨어하우스 + SQL로 ML 모델 학습" → Redshift Serverless + Redshift ML 【오답 체크】 (A) EMR은 서버리스가 아니라 클러스터 관리 부담이 있어 "서버리스 우선" 요건에 덜 부합. (B) Aurora Serverless는 MPP 웨어하우스가 아니라 관계형 OLTP DB로 요건 불일치. (D) Athena는 쿼리 엔진이며 "Athena ML"이라는 SQL 모델 학습 서비스는 존재하지 않음. 【시험 포인트】 "서버리스 + MPP 웨어하우스 + SQL ML" → Glue + Redshift Serverless + Redshift ML.

해설

【핵심 용어】 ▸ AWS Outposts — AWS 하드웨어를 온프레미스 데이터 센터에 설치해 EKS 등 AWS 관리형 서비스를 로컬에서 실행, 데이터 로컬 유지 ▸ Local Zones — 특정 대도시 인근 AWS 인프라 (고객 데이터 센터 내부 아님) ▸ Snowmobile / Snowball Edge — 데이터 전송/엣지 컴퓨팅 (상시 EKS 클러스터·규정 데이터 로컬 요건과 불일치) 【정답 포인트】 ▸ "EKS 및 AWS 관리형 서비스 사용" + "데이터는 데이터 센터 내에 로컬 유지(규정)" → Outposts 랙을 데이터 센터에 설치해 로컬에서 실행 【오답 체크】 (A) Local Zones는 AWS가 운영하는 대도시 위치이지 고객 데이터 센터 내부에 배포하는 것이 아님. (B) Snowmobile은 대량 데이터 전송용 트럭으로 상시 컨테이너 실행 용도가 아님. (D) Snowball Edge는 엣지 컴퓨팅/전송용으로 완전한 EKS + AWS 관리형 서비스 상시 운영에 부적합. 【시험 포인트】 "온프레미스에서 AWS 관리형 서비스 실행 + 데이터 로컬 유지" → AWS Outposts.

해설

【핵심 용어】 ▸ AWS Storage Gateway - Amazon S3 File Gateway — 온프레미스 NFS/SMB 파일을 S3 객체로 저장, 무한 확장 ▸ S3 Lifecycle Policy — 적절한 스토리지 클래스로 자동 전환해 비용 최적화 ▸ Volume Gateway / EFS IA — 블록 스토리지 / 관리형 파일 시스템 (NFS 마이그레이션·비용 효율 요건 대비 부적합) 【정답 포인트】 ▸ "온프레미스 NFS 데이터가 확장 부족 → AWS로 마이그레이션" + "비용 효율" → S3 File Gateway로 파일을 확장성 있는 S3에 저장 + 라이프사이클로 비용 절감 【오답 체크】 (A) Volume Gateway는 iSCSI 블록 볼륨용으로 NFS 파일 데이터 저장/확장 요건에 덜 맞음. (C) EFS Standard-IA는 관리형 NFS로 가능하나 S3 대비 대용량 저장 비용이 높아 비용 효율에서 밀림. (D) EFS One Zone-IA는 단일 AZ로 내구성이 낮고 마찬가지로 S3 대비 비용 효율이 낮음. 【시험 포인트】 "온프레미스 NFS/파일 → 확장성·저비용 클라우드 저장" → S3 File Gateway + S3 라이프사이클.

해설

【핵심 용어】 ▸ Lambda Memory–CPU 비례 — Lambda는 메모리를 늘리면 vCPU도 비례 증가, CPU 집약 작업이 빨라져 실행 시간·비용 절감 가능 ▸ AWS Compute Optimizer — Lambda 메모리 최적값 권장 ▸ Provisioned Concurrency — 미리 초기화된 실행 환경 유지로 콜드 스타트 제거·지연 안정화 ▸ Reserved Concurrency — 동시성 상한 설정 (성능·지연 개선 목적 아님) 【정답 포인트】 ▸ "CPU 집약 코드 + 지연 유지 + 비용 절감" → 메모리를 Compute Optimizer 권장치로 늘려 CPU를 확보하면 실행이 빨라져 총 비용 절감 ▸ "지연 유지" → provisioned concurrency로 콜드 스타트 없이 안정적 응답 【오답 체크】 (A) 예약 동시성 + 메모리 감소는 CPU가 줄어 CPU 집약 작업이 느려지고 지연 악화. (B) 예약 동시성은 지연·성능 개선 목적이 아니라 동시성 상한 제어라 요건과 어긋남. (C) 프로비저닝 동시성은 맞으나 메모리 감소는 CPU 저하로 지연·처리 시간 악화. 【시험 포인트】 Lambda CPU 부족 → 메모리 증가(=CPU 증가)로 빠르게, 지연 안정화는 provisioned concurrency.

해설

【핵심 용어】 ▸ Amazon ECR (Private Repository) — 컨테이너 이미지 저장소, 취약점(CVE) 스캔 내장 ▸ Scan on Push — 이미지 푸시 시 자동 스캔, ECS 워크로드 변경 없이 신규 이미지도 자동 검사 ▸ Macie / Inspector(S3) / EKS 전환 — 데이터 분류 / 별도 구성 / 오케스트레이터 변경 (워크로드 변경 최소 요건 위반) 【정답 포인트】 ▸ "ECS 태스크가 쓰는 이미지 + 신규 이미지 CVE 스캔" + "워크로드 변경 최소" → 이미 이미지를 두는 ECR에 scan-on-push(basic scan) 설정만으로 해결 【오답 체크】 (B) S3 + Macie는 민감 데이터 분류 서비스로 컨테이너 CVE 스캔이 아님. (C) EKS로 전환은 오케스트레이터를 바꾸는 큰 변경이라 "변경 최소" 요건 위반. (D) S3 + Lambda + Inspector 구성은 이미지 저장 방식·파이프라인을 크게 바꿔 변경이 많음. 【시험 포인트】 "컨테이너 이미지 CVE 스캔 + 최소 변경" → ECR scan-on-push.