정답 · 해설

해설

【핵심 용어】 ▸ Amazon Macie — PII 자동 검출 ▸ Step Functions — 데이터 처리 오케스트레이션 ▸ EventBridge 예약 — 주간 실행 자동화 ▸ 교차 계정 KMS 정책 【정답 포인트】 ▸ (A) Macie + Step Functions → PII 검출 및 익명화 ▸ (D) EventBridge 예약 → 주간 자동 실행 【오답 체크】 (B) S3 복제는 복호화 불가 (암호화된 상태 복제) (C) S3 Object Lambda는 GET 요청용 (동기 처리, 배치 아님) (E) EC2 크론 작업은 관리 오버헤드 증가 【시험 포인트】 PII가 있는 데이터는 프로덕션에서 개발로 이동 전 반드시 익명화되어야 합니다. Macie로 PII를 자동 검출하고 Step Functions로 처리 파이프라인을 구성합니다. EventBridge 예약으로 반복 작업을 자동화하면 EC2 관리가 불필요합니다.

해설

【핵심 용어】 ▸ Systems Manager State Manager — EC2/온프레미스 노드 명령 실행 ▸ 이미지 사전 가져오기(Image Prefetch) — 노드 캐시에 미리 로드 ▸ EKS 데이터 플레인 노드 【정답 포인트】 ▸ (C) 데이터 플레인 노드만 실행 권한 필요 (제어 평면 아님) ▸ 노드 태그로 이미지 세트 식별 ▸ State Manager 연결로 자동 실행 【오답 체크】 (A) (D) 제어 평면은 실행 대상 아님 (관리형 AWS 서비스) (B) 머신 크기는 동적 노드 추가 시 변경 가능 (부정확) 【시험 포인트】 EKS 노드는 ec2 또는 ssm-agent 역할이 필요한 데이터 플레인 인스턴스입니다. Systems Manager는 이 노드들에 명령을 실행합니다. 태그 기반 식별이 최신 노드 추가 시에도 동작합니다. 제어 평면 노드(etcd, API 서버 등)는 AWS 관리로 접근 불가입니다.

해설

【핵심 용어】 ▸ EventBridge 예약 — 정기적 API 호출 ▸ AWS Glue Crawler — 메타데이터 카탈로그 ▸ Amazon Athena — SQL 쿼리 ▸ QuickSight — BI 대시보드 【정답 포인트】 ▸ (A) EventBridge + Lambda → API 데이터 수집 → S3 ▸ (C) Glue Crawler + Athena 뷰 → 쿼리 가능 ▸ (E) QuickSight → BI 대시보드 시각화 【오답 체크】 (B) DynamoDB는 분석용이 아님 (OLTP 데이터베이스) (D) Glue는 DynamoDB 스트림 크롤링 미지원 (F) CloudWatch는 분석 대시보드 부적합 (메트릭 모니터링용) 【시험 포인트】 규모 있는 분석은 데이터 레이크(S3) + 카탈로그(Glue) + 쿼리(Athena) + BI(QuickSight) 조합입니다. DynamoDB는 저수준 분석 불가이고, CloudWatch는 메트릭 시계열 모니터링용입니다.

해설

【핵심 용어】 ▸ EFS 마운트 대상 — 파일 시스템 액세스 포인트 ▸ EFS CSI Driver IAM Role — 드라이버 권한 ▸ NFS 네트워크 연결 【정답 포인트】 ▸ (B) 보안 그룹 NFS(포트 2049) 인바운드 규칙 ▸ (C) EFS CSI 드라이버 IAM 역할 필수 ▸ (E) 노드 서브넷의 마운트 대상 필수 【오답 체크】 (A) Fargate는 EFS 지원하지만 EC2 대체 아님 (인프라 요구사항) (D) DataSync는 일회성 전송용 (파일 시스템 마운트 아님) (F) 암호화 비활성화는 보안 약화 【시험 포인트】 EFS 마운팅 실패는 다음 3가지 확인: (1) 마운트 대상 생성 (노드 서브넷), (2) 보안 그룹 NFS 포트 개방, (3) CSI 드라이버 IAM 권한. 이 조합이 없으면 쿠버네티스 볼륨 요청이 실패합니다.

해설

【핵심 용어】 ▸ IAM Roles Anywhere — 온프레미스 장치 AWS 액세스 ▸ Private CA 인증서 — 장치 ID 검증 ▸ 최소 권한 원칙 ▸ 장치별 접근 제어 【정답 포인트】 ▸ (B) Private CA 인증서 → 장치 개별 식별 ▸ (D) amazon-efs-utils → NFS 자동 마운트 【오답 체크】 (A) 전체 접근 권한은 최소 권한 위배 (C) 공유 자격증명은 개별 장치 취소 불가 (E) 네이티브 NFS는 AWS 인증 미지원 【시험 포인트】 IAM Roles Anywhere + Private CA 조합으로 각 장치를 개별 인증서로 식별하고 취소 가능하게 합니다. amazon-efs-utils는 EFS 마운트를 자동으로 처리하며 Direct Connect 프라이빗 링크로 암호화됩니다.

해설

【핵심 용어】 ▸ CloudFormation Hook — 배포 정책 적용 ▸ Linear 배포 전략 — 일정 비율 증분 ▸ Canary 배포 전략 — 소수 대상만 테스트 【정답 포인트】 ▸ (B) Linear 10% 매분 → 정확히 요구사항 충족 ▸ AWS::CodeDeployBlueGreen 변환 필수 ▸ Hook 파라미터로 배포 구성 【오답 체크】 (A) AppSpec은 Lambda용 (ECS는 Hook 사용) (C) Canary는 5분 간격 (매분 아님) (D) ECSCanary10Percent5Minutes는 5분 간격 【시험 포인트】 CloudFormation의 CodeDeploy blue/green은 Hook 형식이 필요합니다. Linear 전략은 매분마다 정해진 비율(10%)씩 증분하고, Canary는 작은 그룹에서만 테스트 후 다음 단계로 진행합니다. 문제 요구사항은 매분 10% Linear 배포입니다.

해설

【핵심 용어】 ▸ Organizations API — 계정 생성 권한 ▸ 교차 계정 역할 가정 — 신뢰 관계 ▸ Lambda 실행 역할 → 관리 계정 역할 (AssumeRole) 【정답 포인트】 ▸ (A) 관리 계정 IAM 역할 생성 (organizations:CreateAccount) ▸ 새 계정 Lambda 실행 역할이 이 역할을 가정 ▸ Lambda 코드에서 STS AssumeRole 호출 【오답 체크】 (B) 위임된 관리는 특정 계정에만 일부 기능 위임 (전체 생성 권한 아님) (C) Lambda 서비스 주체는 역할을 가정 불가 (Lambda 실행 역할만 가정 가능) (D) Control Tower는 Organizations API 대체가 아님 【시험 포인트】 교차 계정 리소스 접근은 AssumeRole 신뢰 관계로 구현합니다. 새 계정의 Lambda 실행 역할이 관리 계정의 Organizations 권한 역할을 가정하고, 코드에서 STS AssumeRole을 호출하여 임시 자격증명을 얻은 후 Organizations API를 사용합니다.

해설

【핵심 용어】 ▸ DynamoDB Global Tables — 자동 양방향 복제, 밀리초 단위 동기화 ▸ S3 Cross-Region Replication — 객체 레벨 실시간 복제 【정답 포인트】 ▸ DynamoDB Global Tables는 AWS가 관리하는 완전 자동 메커니즘으로 즉시 데이터 전파를 보장합니다. ▸ S3의 양방향 복제는 버킷 간 자동 동기화를 제공합니다. ▸ 수동 Lambda 로직이나 Batch Operations는 운영 복잡도를 증가시키고 지연을 야기합니다. 【오답 체크】 (B) Batch Operations는 스케줄된 배치 작업으로 실시간 동기화가 불가능합니다. (C) (D) Lambda 함수를 통한 스트림 처리는 추가 코드 관리, 모니터링, 오류 처리 오버헤드가 있습니다. 【시험 포인트】 다중 리전 아키텍처 → 관리형 서비스 선택 → 운영 효율성 극대화

해설

【핵심 용어】 ▸ EventBridge — RDS 이벤트 감지 및 라우팅 ▸ CloudWatch Custom Metric — 사용자 정의 메트릭 게시 ▸ Lambda — 이벤트 처리 및 메트릭 생성 【정답 포인트】 ▸ RDS 자동 스케일링 이벤트는 RDS Events(CloudTrail 아님)에서 발생합니다. ▸ EventBridge는 RDS Events를 직접 캡처할 수 있는 유일한 방식입니다. ▸ Lambda를 통해 Custom Metric을 생성하면 대시보드에서 직접 시각화 가능합니다. 【오답 체크】 (B) (D) CloudTrail은 관리 이벤트 또는 데이터 이벤트만 기록하며, RDS 자동 스케일링 이벤트 감지는 불가능합니다. (C) 알람 상태 변경만으로는 스케일링 이벤트의 메트릭 데이터를 수집하지 못합니다. 【시험 포인트】 RDS Events → EventBridge → Lambda → Custom Metric → CloudWatch Dashboard

해설

【핵심 용어】 ▸ EC2 Image Builder — 컨테이너 이미지 자동 빌드 및 배포 ▸ Container Recipe — ECR 대상 이미지 정의 ▸ Distribution — 다중 리전 배포 【정답 포인트】 ▸ EC2 Image Builder는 컨테이너 레시피와 함께 여러 ECR 리포지토리에 직접 배포할 수 있습니다. ▸ Distribution 설정으로 한 번의 빌드로 3개 리전 동시 배포 가능합니다. ▸ 복제 구성(옵션 A)보다 직접 배포(옵션 C)가 운영 복잡도를 줄입니다. 【오답 체크】 (A) 복제 체인(us-west-2 → us-east-2 → eu-central-1)은 지연을 야기합니다. (B) (D) CodePipeline+CodeBuild는 빌드용이고, CodeDeploy는 컨테이너 배포용이 아닙니다. 【시험 포인트】 컨테이너 이미지 배포 → EC2 Image Builder → Distribution → 다중 리전 동시 배포

해설

【핵심 용어】 ▸ Systems Manager State Manager — 관리형 노드의 상태 관리 및 문서 실행 ▸ Association — 노드와 문서의 자동 연결 ▸ Managed Nodes — SSM 에이전트가 설치된 EC2/온프레미스 서버 【정답 포인트】 ▸ State Manager Association은 모든 관리형 노드를 자동으로 감지하고 주기적으로 실행됩니다. ▸ 소프트웨어가 없으면 자동으로 Systems Manager 문서 실행을 통해 설치합니다. ▸ AWS Config보다 간단하고 직관적인 구성입니다. 【오답 체크】 (B) Config는 규정 준수만 보고하고, 자동 수정은 별도 설정이 필요합니다. (C) Inspector는 취약성 스캔이고, 소프트웨어 설치와 무관합니다. (D) EventBridge + CloudTrail은 신규 인스턴스 생성 이벤트만 감지하고, 기존 인스턴스는 대상에서 벗어납니다. 【시험 포인트】 소프트웨어 배포 자동화 → State Manager Association → 주기적 실행 및 자동 수정

해설

【핵심 용어】 ▸ ECR Enhanced Scanning — Amazon Inspector 기반 취약성 스캔(OS+언어 패키지) ▸ EventBridge + Lambda — 스캔 결과 처리 및 파이프라인 게이트 ▸ Inspector — CRITICAL/HIGH 결과 필터링 【정답 포인트】 ▸ 기본 스캔 (A) 은 운영 체제 취약성만 검사하고 언어 패키지는 미포함입니다. ▸ 고급 스캔 (B) 은 Inspector 연동으로 OS + 언어 패키지 모두 스캔합니다. ▸ EventBridge + Lambda (D) 는 Inspector 결과를 파이프라인 승인/거부 결정으로 변환합니다. ▸ Clair (E) 는 AWS 서비스가 아니며 ECR과의 네이티브 통합이 없습니다. 【오답 체크】 (A) 기본 스캔은 언어 패키지 취약성을 감지하지 못합니다. (C) ECR 자체는 파이프라인 게이트 결정을 할 수 없습니다. (E) Clair는 ECR의 고급 스캔 엔진이 아닙니다. 【시험 포인트】 컨테이너 보안 → ECR Enhanced + Inspector → EventBridge/Lambda 파이프라인 게이트

해설

【핵심 용어】 ▸ AWS Config Conformance Pack — 조직 차원의 규정 준수 정책 배포 ▸ approved-amis-by-id — AMI 화이트리스트 규칙 ▸ Systems Manager Automation — 비준수 리소스 자동 수정 ▸ AWS Organizations — 중앙 집중식 정책 실행 【정답 포인트】 ▸ Conformance Pack은 AWS Organizations 수준에서 배포되어 개별 계정의 제거 불가능합니다. ▸ CloudFormation StackSets (B) 는 계정별 배포로 개별 우회 위험이 있습니다. ▸ Config 관리 규칙 + 자동 수정이 가장 강력한 거버넌스 솔루션입니다. ▸ 알림만 제공 (A) (C) 하는 방식은 수정이 자동화되지 않습니다. 【오답 체크】 (A) (C) EventBridge + Lambda/SNS는 감지만 하고 자동 수정이 없습니다. (B) StackSets는 개별 계정의 우회 가능성이 있습니다. 【시험 포인트】 조직 거버넌스 → AWS Config Conformance Pack → 자동 수정 → 비우회 정책

해설

【핵심 용어】 ▸ IAM AssumeRole — AWS API 호출로 로깅 ▸ CloudTrail Events — API 기반 이벤트 감지 ▸ EventBridge — CloudTrail 이벤트 라우팅 ▸ Lambda + SNS — 거의 실시간 알림 【정답 포인트】 ▸ 역할 가정(AssumeRole)은 CloudTrail에 API 이벤트로 기록됩니다. ▸ EventBridge는 CloudTrail 이벤트를 실시간으로 캡처합니다. ▸ Lambda를 통해 비즈니스 로직(특정 역할 필터링)을 추가할 수 있습니다. ▸ SNS는 거의 실시간 알림을 제공합니다. 【오답 체크】 (A) AWS Config는 리소스 구성 추적이고, 실시간 알림이 아닙니다. (B) GuardDuty는 보안 위협 탐지용이고, IAM 역할 가정 추적용이 아닙니다. (C) Management Console 로그인 이벤트는 역할 가정 API 호출을 감지하지 못합니다. 【시험 포인트】 역할 가정 추적 → CloudTrail API 이벤트 → EventBridge 실시간 라우팅 → SNS 알림

해설

【핵심 용어】 ▸ Aurora Global Database — RPO 1초, RTO <1분 ▸ Route 53 Failover Routing — DNS 레벨 페일오버 ▸ RPO(Recovery Point Objective) — 최대 2시간 이내 데이터 손실 ▸ RTO(Recovery Time Objective) — 최대 10분 이내 복구 【정답 포인트】 ▸ Aurora Global Database (B) 는 RPO <1초, RTO <1분으로 요구사항 초과 충족합니다. ▸ Route 53 Failover (D) 는 DNS 레벨에서 즉시 페일오버하여 RTO 10분 달성 가능합니다. ▸ 두 기능 조합으로 데이터 (B) + 애플리케이션 (D) 페일오버를 완성합니다. 【오답 체크】 (A) Single-AZ는 장애 복구용이 아니며, 다중 리전 구성이 아닙니다. (C) NLB는 데이터베이스 로드 밸런싱이고, 페일오버 메커니즘이 아닙니다. (E) Global Accelerator는 성능 라우팅이고, Route 53 Failover처럼 헬스 체크 기반 페일오버가 아닙니다. 【시험 포인트】 RTO/RPO 요구사항 → Aurora Global + Route 53 Failover → 다중 리전 액티브-액티브 설계

해설

【핵심 용어】 ▸ CodeUri — S3 객체(저장된 경로) vs 로컬 폴더(소스) ▸ aws cloudformation package — 로컬 코드를 S3에 업로드 후 템플릿 업데이트 ▸ sam deploy — SAM 템플릿 자동 패키징 및 배포 【정답 포인트】 ▸ 문제: S3에 업로드된 package.zip은 고정 참조이므로, SAM은 변경을 감지하지 못합니다. ▸ 해결책: CodeUri를 로컬 폴더 경로로 변경하면, SAM이 소스 코드 변경을 자동 감지합니다. ▸ (C) sam deploy: CodeUri가 로컬 폴더일 때 자동으로 패키징하고 배포합니다. ▸ (E) aws cloudformation package + deploy: 명시적 패키징 후 배포합니다. 【오답 체크】 (A) cloudformation update-stack는 S3 경로 변경만 반영하고, 새 코드 패키징은 하지 않습니다. (B) update-stack-instances는 StackSet용이고, 단일 스택 배포와 무관합니다. (D) change-set도 S3 경로 기반이므로 패키징 메커니즘 부재로 실패합니다. 【시험 포인트】 SAM 배포 → CodeUri 로컬화 → 자동 패키징 및 배포

해설

【핵심 용어】 ▸ ECR Enhanced Scanning — Amazon Inspector 기반 OS + 언어 패키지 취약성 스캔 ▸ EC2 Image Builder — 컨테이너 이미지 자동 빌드(Container Recipe 지원) ▸ EventBridge + Inspector Finding — 취약성 감지 시 자동 재빌드 트리거 【정답 포인트】 ▸ EC2 Image Builder는 Container Recipe로 컨테이너 이미지를 빌드할 수 있습니다. ▸ ECR 고급 스캔(Enhanced Scanning)이 OS + 언어 패키지 취약성을 모두 감지합니다. ▸ Inspector 결과 이벤트를 EventBridge에서 캡처하여 파이프라인 재실행을 트리거합니다. ▸ 자동 완전 워크플로우: 스캔 → 이벤트 → 재빌드 → 업로드 【오답 체크】 (B) GuardDuty Malware Protection은 악성 소프트웨어 탐지용이고, 취약성 스캔이 아닙니다. (C) CodeBuild + 기본 스캔은 언어 패키지 취약성을 감지하지 못합니다. (D) Systems Manager Compliance는 관리형 노드 규정 준수 검사이고, 컨테이너 이미지 취약성과 무관합니다. 【시험 포인트】 App Runner + ECR 모니터링 → Enhanced Scanning → Inspector 이벤트 → EC2 Image Builder 재빌드

해설

【핵심 용어】 ▸ aws-downloadContent — 원격 소스에서 파일 다운로드 ▸ GitHub sourceType — GitHub 저장소에서 직접 다운로드 지원 ▸ Systems Manager Document — 온프레미스 노드의 부트스트랩 정의 【정답 포인트】 ▸ aws-downloadContent 플러그인은 GitHub 저장소를 직접 지원합니다. ▸ sourceType: GitHub, sourceInfo: 리포지토리 경로 설정 ▸ 가장 간단하고 직관적인 구성입니다. 【오답 체크】 (A) AWS-RunShellScript로 GitHub → S3 중계는 불필요한 추가 단계입니다. (B) aws-configurePackage는 패키지 관리용이고, 임의 파일 다운로드를 지원하지 않습니다. (D) aws:softwareInventory는 소프트웨어 인벤토리 수집용이고, 파일 다운로드용이 아닙니다. 【시험 포인트】 GitHub 저장소 부트스트랩 → aws-downloadContent + GitHub sourceType → 온프레미스 노드 배포

해설

【핵심 용어】 ▸ Service Role — CloudFormation이 가정할 역할 ▸ Trust Policy — 역할을 가정할 수 있는 보안 주체 ▸ iam:PassRole — 사용자가 서비스에 역할을 전달할 수 있는 권한 ▸ ReadOnlyAccess — 리소스 변경 불가능 【정답 포인트】 (A) 개발자에게 읽기 전용 권한 부여 → 수동 변경 방지 (D) cloudformation.amazonaws.com을 신뢰 정책에 추가 → CloudFormation만 역할 사용 가능 (F) CloudFormationDeployment 역할에 cloudformation:* 권한 + iam:PassRole 권한 추가 → 개발자가 역할을 CloudFormation에 전달 가능 이 3가지 조합으로: - 개발자는 리소스를 직접 수정 불가 (A) - CloudFormation만 CloudFormationDeployment 역할 사용 (D) - 개발자가 배포 시 역할을 CloudFormation에 전달 가능(F) 【오답 체크】 (B) 개발자가 역할을 가정하면 리소스 변경 가능하게 됩니다. (C) PassedToService 조건 설정도 필요하지만, 개발자가 여전히 역할을 가정할 수 있습니다. (E) 개발자가 역할을 직접 가정하므로 CloudFormation만의 사용 제한이 아닙니다. 【시험 포인트】 CloudFormation 전용 배포 → 개발자 읽기 전용 + Service Role + iam:PassRole

해설

【핵심 용어】 ▸ Stack Export — 특정 스택에서 출력값을 다른 스택에서 참조 가능하도록 내보내기 ▸ Cross-Stack Reference — 별도 스택 간의 리소스 참조 ▸ 독립적 수명 주기 관리 — 각 팀의 변경 프로세스 유지 【정답 포인트】 ▸ Stack Export는 각 팀의 독립적인 스택 유지를 허용합니다. ▸ 각 스택은 독립적으로 검토, 변경, 배포 가능합니다. ▸ 웹 애플리케이션 팀은 Fn::ImportValue로 데이터베이스 스택의 리소스 참조를 가져올 수 있습니다. ▸ 리소스 레벨 변경 집합 검토가 각 스택에서 가능합니다. 【오답 체크】 (B) 중첩 스택은 부모-자식 관계로 단일 팀이 관리해야 합니다. (C) 스택 집합은 다중 계정/리전 배포용이고, 단일 조직 내 팀 간의 사용 사례가 아닙니다. (D) 수동 파라미터 전달은 자동화를 벗어나고 오류 가능성을 높입니다. 【시험 포인트】 다중 팀 CloudFormation → Stack Export + ImportValue → 독립적 수명 주기 관리