정답 · 해설

해설

【핵심 용어】 ▸ CloudFormation Service Role — CloudFormation이 스택 리소스 생성 시 사용하는 역할 ▸ iam:PassRole — 다른 서비스에 역할을 전달할 수 있는 권한 ▸ 최소 권한 원칙(Least Privilege) — 필요한 최소 권한만 부여 【정답 포인트】 ▸ D가 정답: Service Role 분리 + iam:PassRole 조합 ▸ 개발자는 CloudFormation에 역할을 "전달"할 권한만 필요 ▸ 실제 리소스 생성 권한은 Service Role이 가짐 ▸ 최소 권한: 개발자는 특정 역할만 전달 가능(제약 설정 가능) 【오답 체크】 (A) 개발자에게 모든 리소스 권한을 직접 부여(권한 과다) (B) CloudFormation 전체 권한 부여(최소 권한 위배) (C) cloudformation:* 허용(과도한 권한) 【시험 포인트】 ▸ Service Role 패턴: IAM 권한 분리의 표준 방식 ▸ iam:PassRole: 서비스 역할 위임의 핵심 권한 ▸ DOP 특화: IAM 보안 모범 사례 (최소 권한)

해설

【핵심 용어】 ▸ CloudWatch Logs Subscription — 로그 이벤트를 다른 서비스로 자동 전송 ▸ EventBridge Rule — 일정에 따른 자동 작업 트리거 ▸ 자동화 — 수동 개입 없이 정책 시행 【정답 포인트】 ▸ D가 정답: 두 가지 Lambda 함수의 역할 분리 ▸ 첫 번째 Lambda: 로그인 감지 → 태그 지정 (즉시) ▸ 두 번째 Lambda: EventBridge 일일 규칙 → 태그된 인스턴스 종료 (매일) ▸ 완전 자동화 + 24시간 정책 준수 【오답 체크】 (A) Step Functions 불필요(오버엔지니어링) (B) SNS 기반 수동 알림(자동화 아님) (C) SQS 기반은 불필요한 복잡성 【시험 포인트】 ▸ CloudWatch Logs Subscription: 로그 기반 자동화의 표준 ▸ EventBridge 일일 규칙: 정기적 작업 실행 ▸ DOP 특화: 정책 시행의 완전 자동화

해설

【핵심 용어】 ▸ CloudFormation StackSets — 여러 계정/리전에 자동 배포 ▸ Organizations 자동 배포 — 새 계정 생성 시 자동 적용 ▸ AWS Config — 리소스 구성 모니터링 및 컴플라이언스 【정답 포인트】 ▸ B가 정답: StackSets의 Organizations 통합 기능 ▸ 새 계정 생성 시 자동으로 CloudFormation 배포 ▸ 스케일(500개 계정)에 최적화된 솔루션 ▸ 일회 설정 후 운영 오버헤드 최소 【오답 체크】 (A) EventBridge + Lambda는 신뢰 접근 활성화만 가능(Config 설정 불완전) (C) SCP는 권한 제어이지 리소스 생성 불가 (D) EventBridge + Runbook은 수동 또는 스크립트 기반(확장성 낮음) 【시험 포인트】 ▸ StackSets + Organizations: 조직 규모 자동화의 표준 ▸ 자동 배포 정책: 새 계정의 규정 준수 보장 ▸ DOP 특화: 조직 전체 거버넌스 구현

해설

【핵심 용어】 ▸ 컨테이너화 — 다양한 언어/프레임워크를 통합하는 표준화 방법 ▸ ECS + Fargate — 관리형 컨테이너 오케스트레이션(유지 보수 최소) ▸ ECR — 중앙 이미지 레지스트리 【정답 포인트】 ▸ D가 정답: 다양성을 단일 표준(Docker)으로 통합 ▸ 개별 저장소: 팀별 독립적 배포 가능 ▸ ECR 중앙화: 일관된 이미지 관리 ▸ ECS/Fargate: 기본 인프라 관리 제거(서버리스) ▸ CodeDeploy: 일관된 배포 파이프라인 【오답 체크】 (A) 중앙 저장소(복잡도 높음), 중앙 서버(단일 실패점) (B) 분산 배포(일관성 낮음) (C) AMI 기반(OS 별도 관리), EC2 인스턴스(유지 보수 필요) 【시험 포인트】 ▸ 컨테이너: 이기종 환경의 통합 패턴 ▸ Fargate: "유지 보수 최소화" 요구사항의 핵심 ▸ DOP 특화: 마이크로서비스 아키텍처 고려

해설

【핵심 용어】 ▸ 다중 리전 배포 — 지연 시간 최소화 ▸ DynamoDB 전역 테이블 — 자동 다중 리전 복제 ▸ Route 53 지연 시간 기반 라우팅 — 최적의 리전 선택 【정답 포인트】 ▸ C 선택: 새 리전에 전체 스택(ALB + ASG) 배포 ▸ D 선택: Route 53 지연 시간 기반 라우팅(사용자 위치 감지) ▸ F 선택: DynamoDB 전역 테이블(양쪽 리전 데이터 동기) ▸ 조합: 각 리전 배포 → 라우팅 제어 → 데이터 동기화 【오답 체크】 (A) 교차 리전 복제는 일방향, 전역 테이블로 변환 필요 (B) "전역 리소스"는 AWS 개념이 아님(리전별 리소스 필요) (E) 장애 조치 정책은 지연 시간 최소화 목표와 맞지 않음 【시험 포인트】 ▸ 다중 리전 아키텍처: 컴퓨팅 (C) + 라우팅 (D) + 데이터(F) ▸ Route 53 라우팅 정책: Latency가 최적화 목표 ▸ DOP 특화: 전역 애플리케이션 배포 패턴

해설

【핵심 용어】 ▸ Config 관리 계정 — 중앙 집중식 Config 규칙 관리 ▸ 신뢰 접근 — 대리 관리자 권한 ▸ CloudTrail 조직 추적 — 조직 전체 감시 ▸ SCP — 기본 리소스 보호 【정답 포인트】 ▸ C가 정답: 다층 거버넌스 구조 ▸ Config 관리 계정: 규칙 집중 관리 ▸ StackSets: 모든 계정에 레코더 배포 ▸ 조직 추적: 단일 CloudTrail로 중앙 수집 ▸ SCP: 관리자 권한 보호(편집/삭제 불가) ▸ 개별 팀: 자신의 추적/규칙만 관리 가능 【오답 체크】 (A) StackSet만으로 관리 계정 미지정(중앙화 미흡) (B) Control Tower는 신규 가입 워크플로우(기존 계정 미흡) (D) SCP 범위 불명확("조직 관리자만" 예외 조건) 【시험 포인트】 ▸ 3가지 계층: 배포(StackSets) + 중앙 수집(추적) + 보호(SCP) ▸ Config 관리 계정: 대리 관리자 권위 구조 ▸ DOP 특화: 조직 규모 거버넌스 구현

해설

【핵심 용어】 ▸ AWS Config 조직 aggregator — 중앙 집중식 구성 및 규정 준수 모니터링 ▸ 대리 관리자 계정 — Config 관리 권한 위임 ▸ 신뢰 접근 — 조직 전체에 적용 권한 【정답 포인트】 ▸ A 선택: 대리 관리자 지정 + 신뢰 접근 활성화 ▸ E 선택: 대리 관리자 계정에 조직 aggregator 생성 ▸ 조합: 권한 위임 (A) → 중앙 수집 (E) ▸ 결과: 중앙 계정에서 모든 계정의 리소스 변경 기록 【오답 체크】 (B) 서비스 연결 역할은 Config aggregation에 필수가 아님 (C) StackSets는 각 계정에 aggregator 배포(중앙화 아님) (D) 관리 계정 aggregator는 대리 관리자 권위 미흡 【시험 포인트】 ▸ Config aggregator: 조직 규모 컴플라이언스 기본 ▸ 대리 관리자 + 신뢰 접근: 권위 위임 패턴 ▸ DOP 특화: 중앙 집중식 감시 구현

해설

【핵심 용어】 ▸ Lambda 함수 버전 — 코드 버전 관리 ▸ Canary 배포 — 트래픽 점진적 전환(소수→전체) ▸ CloudFormation — IaC 기반 배포 【정답 포인트】 ▸ B가 정답: Lambda 버전 + CloudFormation + Canary 조합 ▸ Lambda 버전: $LATEST와 명명된 버전 분리 ▸ Canary: CloudFormation API Gateway 가중 정책으로 구현 ▸ 테스트 후 버전 승격으로 안전한 배포 【오답 체크】 (A) CDK는 CloudFormation 래퍼(버전 관리 명시적 부족) (C) Elastic Beanstalk는 Lambda 미지원 (D) OpsWorks는 Lambda에 부적합(EC2/온프레미스 중심) 【시험 포인트】 ▸ Lambda 버전: 서버리스 배포의 핵심 ▸ Canary 전략: CloudFormation으로 구현 ▸ DOP 특화: 서버리스 CI/CD 패턴

해설

【핵심 용어】 ▸ EventBridge + CodeBuild — PR 이벤트 기반 자동 테스트 ▸ Approval Rule Template — Merge 전 조건 검증 ▸ 사용자 지정 이벤트 페이로드 — 컨텍스트 전달 【정답 포인트】 ▸ B가 정답: PR 생성 감지 → 즉시 테스트 실행 ▸ EventBridge: CodeCommit pullRequestCreated 이벤트 ▸ CodeBuild: 단위+통합 테스트 ▸ 사용자 지정 페이로드: 저장소/브랜치 정보 전달 ▸ 병렬 실행 가능 (코드 병합 전 피드백) 【오답 체크】 (A) Approval Rule은 조건 체크(자동 테스트 실행 아님) (C) 기존 파이프라인 수정 복잡(별도 이벤트 기반 테스트 권장) (D) Notification Rule은 PR 이벤트 지원이 제한적 【시험 포인트】 ▸ EventBridge: PR 기반 자동화의 표준 ▸ 조기 피드백: Merge 전 테스트 ▸ DOP 특화: CI/CD 품질 게이트 구현

해설

【핵심 용어】 ▸ Systems Manager Automation — 복잡한 자동화 작업 실행 ▸ EventBridge 규칙 — CloudWatch 경보 이벤트 기반 트리거 ▸ 운영 효율성 — 최소한의 의존성/중복 【정답 포인트】 ▸ D가 정답: EventBridge + Systems Manager Automation ▸ EventBridge: CloudWatch 경보 ALARM 상태 감지 ▸ Automation Runbook: EC2 Systems Manager 에이전트 통해 원격 실행 ▸ SNS 불필요(EventBridge 직접 트리거) ▸ Lambda 불필요(Runbook 직접 실행) 【오답 체크】 (A) SNS는 EventBridge 같은 이벤트 기반 서비스가 아님 (B) Lambda는 EC2 원격 커맨드 실행 복잡(IAM 권한, Systems Manager 필요) (C) Lambda + Runbook 조합은 불필요한 레이어 【시험 포인트】 ▸ EventBridge: CloudWatch 경보의 표준 이벤트 소스 ▸ Systems Manager: EC2 에이전트 기반 명령 실행 ▸ DOP 특화: 최소 구성요소로 최대 자동화

해설

【핵심 용어】 ▸ CreateUser API — 새 사용자 생성 이벤트 ▸ 액세스 키 비활성화 — 자격증명 제어 ▸ 로그인 프로필 삭제 — 콘솔 접근 차단 【정답 포인트】 ▸ A 선택: CloudTrail의 CreateUser API 감지 ▸ C 선택: Lambda로 액세스 키 비활성화 + 로그인 프로필 삭제 ▸ E 선택: SNS 주제로 보안팀 알림 ▸ 조합: 감지 (A) → 자동 대응 (C) → 알림 (E) ▸ "즉시 비활성화" + "알림" 모두 충족 【오답 체크】 (B) GetLoginProfile은 자격증명 생성이 아니므로 부적절 (D) 로그인 프로필만 삭제(액세스 키 남아있음) (F) SQS는 이메일 구독 미지원(SNS 사용) 【시험 포인트】 ▸ CreateUser: 새 사용자 정책 시행의 트리거 ▸ 액세스 키 + 로그인 프로필: 모든 접근 채널 차단 ▸ DOP 특화: IAM 보안 자동화

해설

【핵심 용어】 ▸ CodePipeline — CI/CD 파이프라인 조율 ▸ CodeDeploy — 다중 컴퓨팅 플랫폼 배포 ▸ 수동 승인 — ManualApproval 작업 【정답 포인트】 ▸ B가 정답: CodeDeploy는 3가지 플랫폼 모두 지원 ▸ CodeDeploy의 배포 대상: EC2, ECS, Lambda, On-premises ▸ CodePipeline + CodeDeploy: 표준 CD 솔루션 ▸ 수동 승인: CodePipeline 네이티브 지원 【오답 체크】 (A) CodePipeline 자체는 배포 공급자가 아님(오직 조율) (C) Elastic Beanstalk는 ECS/Lambda 미지원 (D) CodeDeploy 직접은 GitHub 소스 미지원(CodePipeline 필요) 【시험 포인트】 ▸ CodeDeploy: 다중 플랫폼 배포의 통일된 서비스 ▸ CodePipeline: 수동 승인 단계 포함 ▸ DOP 특화: CI/CD 파이프라인 아키텍처

해설

【핵심 용어】 ▸ Warm Pool — 사전 구성된 대기 인스턴스 ▸ Stopped 상태 — 비용 최소화(실행 비용 없음) ▸ Running 상태 — 빠른 시작(비용 높음) ▸ 라이프사이클 훅 — 시작 완료 확인 【정답 포인트】 ▸ A가 정답: "가장 비용 효율적" ▸ Warm Pool + Stopped: 인스턴스 미리 생성(비용 낮음) ▸ 필요시 시작 → 데이터 처리 → 준비 완료 ▸ Stopped는 실행 비용 미발생(저장 비용만) ▸ Running 상태보다 낮은 총 비용 【오답 체크】 (B) 최대 수 증가는 비용 증가(항상 실행 인스턴스) (C) Running Pool은 대기 중에도 비용 발생(비효율) (D) Standby 상태는 시작 시간 단축 못함(Running 필요) 【시험 포인트】 ▸ Warm Pool: EC2 시작 시간 최적화 ▸ Stopped vs Running: 비용 트레이드오프 ▸ DOP 특화: 스케일링 성능 + 비용 최적화

해설

【핵심 용어】 ▸ --acl authenticated-read — 모든 AWS 인증 사용자 접근 허용(위험) ▸ 버킷 정책 — 특정 계정만 접근 제어 ▸ 공개 접근 차단 — 필수 보안 조치 【정답 포인트】 ▸ D가 정답: 두 가지 변경 ▸ authenticated-read 제거: 공개 접근 금지 ▸ 버킷 정책: 특정 계정만 명시적 허용 ▸ 결과: 필요한 계정만 접근 가능 【오답 체크】 (A) public-read는 누구나 다운로드 가능(문제 악화) (B) 기본 ACL로는 계정 단위 제어 불가 (C) 정책은 맞지만 --acl 제거 누락 【시험 포인트】 ▸ authenticated-read: "인증된" 모든 사용자 → 모든 AWS 계정 ▸ 버킷 정책: 특정 계정 지정 ▸ DOP 특화: S3 보안 + 멀티 계정 아키텍처

해설

【핵심 용어】 ▸ CodeGuru Reviewer — 시크릿 감지 및 "보호" 옵션 ▸ Secrets Manager — 안전한 시크릿 저장소 ▸ Parameter Store(Secure String) — 암호화 저장 ▸ 자동 감지 — 리포지토리 연결 후 스캔 【정답 포인트】 ▸ B가 정답: 가장 안전한 조합 ▸ CodeGuru Reviewer: 시크릿 자동 감지 (배포 전) ▸ "보호 선택" 옵션: 시크릿 레메디에이션 자동화 ▸ Secrets Manager: 데이터베이스 자격증명의 표준 저장소 ▸ 결과: 하드코딩 방지 + 안전한 관리 【오답 체크】 (A) Profiler는 성능 분석(시크릿 감지 안함) (C) Profiler는 시크릿 감지 불가 (D) Parameter Store의 "String"은 암호화 아님(Secure String 필요) 【시험 포인트】 ▸ CodeGuru Reviewer: 시크릿 감지의 표준 ▸ Secrets Manager: 데이터베이스 자격증명 관리 ▸ Secure String vs String: 암호화 차이 ▸ DOP 특화: CI/CD 보안 자동화

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 — 자동 준수 확인 ▸ Systems Manager Automation — 자동 remediation ▸ 기존 + 신규 버킷 모두 대응 【정답 포인트】 ▸ B가 정답: 2개 요구사항 모두 충족 ▸ Config 규칙: 신규 버킷 생성 시 자동 확인 ▸ Automation Runbook: 자동 AES-256 설정 ▸ 수동 재평가: 기존 버킷 규정 준수 확인 ▸ 결과: 기존(수동 스캔) + 신규(자동) 모두 암호화 【오답 체크】 (A) Lambda 수동 실행(스케줄링 필요), 신규 버킷 자동화 미흡 (C) 신규 버킷만 처리(기존 버킷 미대응) (D) 정책은 생성 전 거부(기존 미대응), 조건 키 구문 복잡 【시험 포인트】 ▸ Config + Automation: 기존 + 신규 통합 솔루션 ▸ 자동 remediation: 수동 개입 최소화 ▸ DOP 특화: 규정 준수 자동화

해설

【핵심 용어】 ▸ AWS CodePipeline — 소스에서 배포까지 자동화된 CI/CD 워크플로우 ▸ AWS CodeDeploy — EC2 인스턴스 및 온프레미스 서버로의 배포 자동화 ▸ Auto Scaling group — 트래픽에 따른 EC2 인스턴스 자동 관리 【정답 포인트】 ▸ "최소 구성"과 "동시 배포" → 단일 파이프라인으로 여러 배포 그룹에 병렬 배포 ▸ CodeDeploy는 단일 애플리케이션에서 여러 배포 그룹을 지원하므로 추가 CodeDeploy 애플리케이션 불필요 ▸ 옵션 C: 1개 파이프라인 + 1개 애플리케이션 + N개 배포 그룹 = 최소 구성 【오답 체크】 (A) 각 ALB마다 별도의 CodeDeploy 애플리케이션 필요 → 구성 과다 (B) 단일 배포 그룹은 병렬 배포 불가 → 순차 배포만 가능 (D) ALB 쌍마다 파이프라인 생성 → 구성 과다, 중복 관리 【시험 포인트】 CodeDeploy의 계층 구조: Application > DeploymentGroup(s) > 병렬 배포 최소 구성 문제 → 불필요한 리소스 제거, 기존 서비스 활용 CodePipeline 병렬 처리 → runOrder 값을 같게 설정하여 동시 배포

해설

【핵심 용어】 ▸ Route 53 가중치 기반 라우팅 — 가중치에 따른 트래픽 분산 ▸ TTL (Time To Live) — DNS 응답 캐시 시간 ▸ DNS 전파 — 전 세계 DNS 서버에 레코드 변경 동기화 【정답 포인트】 ▸ 문제: 새 레코드(가중치 255)가 추가되었으나 기존 S3 레코드(가중치 불명)도 존재 → 트래픽 분산 ▸ TTL 1일(86400초) 캐시 → 최대 2일까지 구 DNS 응답 유지 가능 ▸ "2일 후 여전히 구 웹사이트 표시" = TTL 만료 후에도 S3 레코드 존재 ▸ 유일한 해결책: 구 레코드를 완전히 제거하고 DNS 전파 대기 【오답 체크】 (A) S3 객체 삭제 → DNS는 여전히 S3로 가중치 분배 (B) 가중치 0 설정 → AWS에 "도메인 재설정 옵션" 없음, DNS는 여전히 응답 캐시됨 (C) 리다이렉트 → 여전히 Route 53 가중치 분산 문제 미해결 【시험 포인트】 DNS 캐싱 메커니즘 → TTL 이해 필수 Route 53 가중치 라우팅 → 모든 레코드에 트래픽 분배 레코드 제거 후 DNS 전파 시간 필요

해설

【핵심 용어】 ▸ Amazon EventBridge — 이벤트 기반 아키텍처를 위한 서비스 ▸ AWS CodePipeline — CI/CD 자동화 ▸ 이벤트 패턴 — source, detail-type, detail 필터 【정답 포인트】 ▸ "custom event pattern" 언급 → detail-type: "CodePipeline Execution State Change" 또는 approval action 관련 ▸ 문제에서 패턴이 명시되지 않았지만, "execution state fails"와 approval과 관련된 선택지 분석 ▸ EventBridge rule의 detail.state: "FAILED" AND detail.type: "approval" → 거부/실패한 승인 ▸ "rejected or failed approval actions" = 승인 단계에서의 거부 또는 실패 【오답 체크】 (A) "Failed deploy and build" → 배포/빌드 실패는 다른 detail-type (C) "All events" → 필터링 없음, 패턴과 무관 (D) "Approval actions" → 모든 승인 작업 포함, 실패/거부만 아님 【시험 포인트】 EventBridge 패턴 필터링 → detail 객체 구조 이해 CodePipeline 이벤트 타입 → ExecutionStateChange, ApprovalAction 선택적 필터 → FAILED/REJECTED 상태만 매칭

해설

【핵심 용어】 ▸ CloudFormation Init 메타데이터 — cfn-init/cfn-hup과 함께 작동 ▸ cfn-init — 메타데이터에서 구성 파일 다운로드 ▸ cfn-hup — 메타데이터 변경 감지 및 자동 재배포 ▸ Launch Template — EC2 시작 설정 저장 【정답 포인트】 ▸ "CloudFormation 템플릿과 함께 소스 제어" → CloudFormation 메타데이터 섹션 사용 ▸ "최소 지연으로 변경 반영" → cfn-hup 폴링이 자동으로 업데이트 감지 ▸ cfn-init: 초기 구성 파일 다운로드 ▸ cfn-hup: 메타데이터 변경 감시하여 자동 적용 ▸ Launch Template은 동적 메타데이터 업데이트 불가 【오답 체크】 (A) AWS Config는 구성 관리 도구 아님, 규정 준수 확인용 (B) Launch Template에는 구성 파일 변경 감지 메커니즘 없음 (C) Resource Data Sync는 Systems Manager 기반, CloudFormation과 통합 약함 【시험 포인트】 CloudFormation 메타데이터 섹션 구조 cfn-init과 cfn-hup의 역할 분담 Auto Scaling 그룹 + 메타데이터 = 자동 재배포