정답 · 해설

해설

【핵심 용어】 ▸ 스모크 테스트(Smoke Test) — 배포 후 기본 기능 검증 ▸ CodeGuru — 코드 품질 및 보안 취약점 검사 ▸ 자동 롤백 vs 배포 실패 — 다양한 실패 처리 방식 【정답 포인트】 ▸ 문제 분석: API 배포 후 여러 이슈 + 보안 취약점 발생 ▸ 해결 방안: (1) 배포 후 실행되는 스모크 테스트 + (2) 빌드 스테이지의 보안 스캔 ▸ B 선택: 스모크 테스트가 배포 후 실패하면 파이프라인 멈춤 (피드백 루프 단축) ▸ D 선택: CodeGuru로 빌드 단계에서 보안 취약점 조기 발견 【오답 체크】 (A) 자동 롤백은 배포 실패 시 자동 복구되므로 파이프라인이 계속 진행 → 대기 시간 발생 (C) Inspector는 Lambda 함수를 런타임에 스캔하는 도구로, 빌드 단계에 부적절 (E) 배포 후 스캔은 이미 프로덕션에 배포된 후 → 빌드 단계에서 조기 발견이 핵심 【시험 포인트】 CodePipeline 파이프라인 설계에서 스모크 테스트와 보안 검사의 위치 선택이 중요. "배포 후 테스트 + 조기 보안 검사" 패턴이 출제 빈도 높음.

해설

【핵심 용어】 ▸ CloudFormation StackSets — Organizations 전체에 스택 자동 배포 ▸ 서비스 관리 권한 — Organizations 통합으로 자동 권한 관리 ▸ 신뢰할 수 있는 액세스(Trusted Access) — Organizations 내 서비스 활성화 【정답 포인트】 ▸ 요구사항: 모든 기존 및 향후 계정에 IAM 구성 자동 배포 ▸ B의 장점: CloudFormation StackSets + 서비스 관리 권한 = 자동 확장 ▸ 신뢰할 수 있는 액세스로 Organizations 내 새로운 계정도 자동 포함 ▸ 자동 배포(Automatic Deployment) = 운영 효율성 극대화 【오답 체크】 (A) Control Tower는 Landing Zone 설정용이며, IAM 역할 배포에 특화되지 않음 (C) 자체 관리 권한은 수동으로 대상 계정을 지정해야 함 → 확장성 낮음 (D) CodePipeline은 CI/CD 자동화용이지, Organizations 전체 배포에 부적절 【시험 포인트】 CloudFormation StackSets의 "서비스 관리 권한" vs "자체 관리 권한" 차이 중요. Organizations 통합 시 자동 확장을 원하면 서비스 관리 권한 선택.

해설

【핵심 용어】 ▸ WebSocket — 양방향 통신 프로토콜 ▸ 스티키 세션 — 특정 클라이언트를 동일 서버로 유지 ▸ 지연 시간 기반 라우팅(Latency-based Routing) — 사용자와 가장 가까운 리전으로 【정답 포인트】 ▸ WebSocket 지원: ALB와 NLB 모두 가능, 하지만 ALB가 더 간단 ▸ 스티키 세션: ALB가 기본 지원, NLB는 추가 설정 필요 ▸ 글로벌 배포 + 최저 지연 = Route 53 지연 시간 기반 라우팅 ▸ ALB + 지연 시간 라우팅 = 가장 낮은 운영 오버헤드 【오답 체크】 (B) 지오로케이션 라우팅은 지리적 위치 기반, 지연 시간 기반이 아님 (C) CloudFront는 정적 콘텐츠용이며, WebSocket 실시간 통신에 부적절 (D) ALB와 NLB 혼합은 복잡도 증가, 운영 오버헤드 상승 【시험 포인트】 WebSocket + 스티키 세션 요구사항에서 ALB와 NLB 선택 기준. Route 53 라우팅 정책(지연 시간 vs 지오로케이션) 구분이 중요.

해설

【핵심 용어】 ▸ Macie 사용자 정의 데이터 식별자 — 특정 패턴(UUID) 감지 ▸ 스테이징 버킷 — 프로덕션 배포 전 필터링 ▸ 민감 데이터 검색(Sensitive Data Discovery Job) 【정답 포인트】 ▸ 요구사항: 공개 미발표 제품(UUID 접두사) 파일을 프로덕션에서 차단 ▸ 핵심 전략: 검색 → 필터링 → 배포 (프로덕션 데이터 삭제 X) ▸ A 선택: (1) 스테이징 버킷에서 생성 (2) 사용자 정의 식별자로 UUID 검출 (3) 안전한 파일만 복사 ▸ 사용자 정의 식별자 = 특정 패턴(UUID)에 대한 정확한 탐지 【오답 체크】 (B) 이미 프로덕션에 배포된 파일 삭제는 위험, 사전 필터링이 모범 사례 (C) 관리형 식별자는 일반적인 민감 데이터(신용카드 등) 검출용, UUID 패턴 특화 X (D) 프로덕션 직접 스캔 후 삭제는 위험하며 비효율적 【시험 포인트】 Amazon Macie 사용자 정의 데이터 식별자로 특정 패턴을 감지하고, 스테이징 버킷을 통한 사전 필터링 아키텍처. "삭제 vs 필터링" 패턴 선택 중요.

해설

【핵심 용어】 ▸ RPO(Recovery Point Objective) — 최대 허용 데이터 손실 시간 ▸ RTO(Recovery Time Objective) — 최대 허용 중단 시간 ▸ Multi-AZ DB 클러스터 — 동기식 복제로 낮은 RPO ▸ 읽기 복제본 승격 — 빠른 장애 조치 【정답 포인트】 ▸ RPO < 1분 요구: 지속적 동기식 복제 필수 ▸ RTO < 10분 요구: 자동화된 빠른 승격 ▸ A 선택: Multi-AZ(동기 복제) + 크로스 리전 읽기 복제본 + 자동 승격 ▸ Multi-AZ DB 클러스터 = 기본적으로 동기식 복제 → RPO 최소화 ▸ 읽기 복제본 승격 자동화 = RTO 단축 【오답 체크】 (B) 5분마다 스냅샷 = RPO 5분 (요구사항 1분 초과) (C) DMS 복제는 비동기식이므로 RPO 보장 어려움, 장애 조치 자동화 부족 (D) AWS Backup 30초 주기는 불가능하며, 비동기식 백업은 RPO 보장 어려움 【시험 포인트】 RPO/RTO 숫자 기준으로 동기식(Multi-AZ) vs 비동기식(스냅샷/백업) 선택. 크로스 리전 고가용성 구성 시 읽기 복제본 승격 패턴.

해설

【핵심 용어】 ▸ EC2 Image Builder — AMI 빌드 및 배포 자동화 서비스 ▸ 월간 업데이트 — 반복 스케줄 필요 ▸ Organizations 배포 — 다중 계정 배포 【정답 포인트】 ▸ EC2 Image Builder = AMI 빌드 + 배포 + 스케줄링을 통합 ▸ 조직 계정에 직접 배포 기능 내장 ▸ 월간 실행 스케줄 → 파이프라인 내 설정 ▸ 최소 관리 오버헤드, 최대 자동화 【오답 체크】 (A) CloudFormation 템플릿 공유는 각 계정이 수동 배포 필요 (C) CodePipeline + Lambda는 커스터마이징은 가능하지만 AMI 배포 기능이 없음 (D) Systems Manager는 조직 전체 자동화 가능하지만 AMI 빌드에 특화되지 않음 【시험 포인트】 월간 AMI 빌드 + 조직 배포 요구사항에서 EC2 Image Builder 특화성. 기본 제공 스케줄링과 배포 기능이 핵심.

해설

【핵심 용어】 ▸ 글로벌 보조 인덱스(GSI) — 파티션 키 변경용 (리전 복제 X) ▸ DynamoDB 글로벌 테이블 — 다중 리전 복제 (이 문제에는 선택지 없음) ▸ 지연 시간 라우팅 — 최저 지연 시간 기반 라우팅 ▸ 장애 조치 라우팅 — 주 리소스 실패 시 보조로 전환 【정답 포인트】 ▸ A: DynamoDB 복제본 필요 (리전별 독립 테이블) ▸ C: 각 리전에 API + Lambda 배포 필수 ▸ E: 지연 시간 라우팅 = 최저 지연 시간 제공하는 리전 선택 ▸ A + C + E = 완전한 크로스 리전 고가용성 【오답 체크】 (B) 글로벌 보조 인덱스는 같은 테이블 내 대체 쿼리용, 리전 복제 X (D) 장애 조치 라우팅은 주/보조 구조, "최저 지연 시간" 요구사항 충족 X (F) 다중값 응답은 여러 리소스 반환, 지연 시간 기반 선택 X 【시험 포인트】 다중 리전 아키텍처에서 "글로벌 테이블" vs "테이블 복제본" 구분. Route 53 라우팅 정책(장애 조치 vs 지연 시간 vs 다중값) 선택 기준.

해설

【핵심 용어】 ▸ AWS Global Accelerator — UDP/TCP 기반 성능 최적화 ▸ 지연 시간 기반 라우팅 vs Global Accelerator — 다양한 레이어 ▸ WebSocket 실시간 통신 — 지속적 연결 필요 【정답 포인트】 ▸ Global Accelerator = 최저 지연 시간 보장 (Anycast IP 사용) ▸ 자동 경로 최적화 및 AI 기반 라우팅 ▸ WebSocket 같은 장기 연결에 최적 ▸ 엔드포인트 그룹 = 각 리전 NLB 매핑 ▸ 동적 지연 시간 측정 → 실시간 최적 리전 선택 【오답 체크】 (A) Route 53 지연 시간 라우팅은 정적 측정, Global Accelerator보다 낮은 성능 (B) CloudFront는 정적 콘텐츠 캐싱용, WebSocket 실시간 통신에 부적절 (C) 다중값 응답은 여러 IP 반환, 자동 지연 시간 최적화 X 【시험 포인트】 "가장 낮은 지연 시간" 요구사항에서 AWS Global Accelerator 선택. 동적 라우팅과 성능 최적화가 핵심 차이.

해설

【핵심 용어】 ▸ AWS Control Tower — Landing Zone 자동 설정 ▸ 사용자 정의된 Landing Zone — 조직 정책 내장 ▸ 자동 등록 — 새 계정 자동 적용 【정답 포인트】 ▸ 요구사항: 모든 계정/리전 + 변경 자동 적용 + 최저 오버헤드 ▸ D 선택: Control Tower Landing Zone = CDK 구성 통합 가능 ▸ 자동 등록 = 새 계정 자동 정책 적용 ▸ Single Point of Management = 운영 효율성 극대화 ▸ CDK → Landing Zone 커스터마이징은 가능 【오답 체크】 (A) CDK + StackSets는 manual target 지정 필요, 새 계정 자동 포함 X (B) EventBridge 자동화는 복잡하며 관리 오버헤드 증가 (C) CloudFormation 매크로는 배포 복잡도 증가, Control Tower 미활용 【시험 포인트】 AWS Control Tower의 "Landing Zone 자동 정책 적용" 특성. 대규모 조직의 정책 배포에서 Control Tower가 가장 관리 효율적.

해설

【핵심 용어】 ▸ AWS CodeArtifact — 패키지 관리 저장소 ▸ 개발 vs 프로덕션 분리 — 계정별 리포지토리 ▸ 리포지토리 정책 — 접근 제어 ▸ EventBridge → CodePipeline — 테스트 자동화 【정답 포인트】 ▸ B 선택: (1) 계정별 CodeArtifact 리포지토리 분리 (2) 리포지토리 정책으로 개발자 접근 제한 ▸ CodeArtifact = 패키지 관리 특화 (S3 vs CodeArtifact) ▸ EventBridge → CodePipeline = 배포 전 자동 테스트 ▸ 프로덕션 전 테스트 → 품질 보증 【오답 체크】 (A) 단일 중앙 리포지토리는 계정별 정책 적용 어려움 (C) (D) S3는 패키지 관리용이 아니며, CodeArtifact만큼 기능 풍부하지 않음 (D) 프로덕션 복사 후 테스트는 늦은 검사, 사전 테스트가 모범 사례 【시험 포인트】 CodeArtifact의 리포지토리 정책과 계정별 분리 구조. CI/CD 파이프라인에서 프로덕션 배포 전 테스트 자동화 패턴.

해설

【핵심 용어】 ▸ Service Control Policy(SCP) — 조직 정책으로 권한 제한 ▸ ReadOnlyAccess vs AdministratorAccess — 역할 분리 ▸ 파이프라인 역할 가정(Assume) — 위임된 권한 【정답 포인트】 ▸ 요구사항: (1) DevOps 팀은 읽기만 (2) 엔지니어는 긴급 수동 배포 가능 (3) 파이프라인만 자동 배포 ▸ A 선택: (1) DevOps 그룹 = ReadOnlyAccess (2) Engineer = AdministratorAccess + 파이프라인 역할 가정 가능 ▸ SCP = 파이프라인 역할만 쓰기 허용 ▸ 권한 분리 + 비상 액세스 + 제어 통합 【오답 체크】 (B) 모든 DevOps가 SCP로 제한되므로 엔지니어도 수동 작업 불가 (C) DevOps 그룹이 파이프라인 역할을 가정하면 모두 동일 권한 (분리 실패) (D) 태그 기반 정책은 관리 복잡도 증가, 파이프라인 역할 제어 미흡 【시험 포인트】 IAM 권한(읽기/관리) vs SCP(정책 기반 제한)의 조합. 파이프라인 자동화와 긴급 수동 액세스의 균형.

해설

【핵심 용어】 ▸ ECR 복제 규칙 — 레지스트리 수준 자동 복제 ▸ 크로스 리전 권한 — 소스 레지스트리가 대상 접근 【정답 포인트】 ▸ C 선택: (1) 주 ECR 레지스트리 권한 설정 (2) 복제 규칙으로 자동화 ▸ ECR 복제 규칙 = 기존 이미지 + 새로운 이미지 모두 자동 복제 ▸ 수동 pull/push 불필요 ▸ 최소 운영 오버헤드 【오답 체크】 (A) 수동 pull/push + 복제 규칙 = 중복 작업 (B) 권한만 설정하면 자동 복제 X, 수동 관리 필요 (D) S3 + Lambda 경로는 불필요하게 복잡, ECR 복제 규칙이 표준 【시험 포인트】 Amazon ECR의 레지스트리 수준 복제 규칙과 크로스 리전 권한 구성. 자동화된 이미지 복제 아키텍처.

해설

【핵심 용어】 ▸ CodeDeploy 배포 로그 — /opt/codedeploy-agent/deployment-root/ 디렉토리 ▸ CloudWatch Logs — 애플리케이션 로그 수집 ▸ X-Ray — 분산 추적 【정답 포인트】 ▸ CodeDeploy 문제 해결 = CodeDeploy 에이전트 로그가 핵심 ▸ C 선택: (1) CloudWatch Logs (2) 로컬 CodeDeploy 로그 (3) X-Ray 추적 ▸ 3가지 로그 소스로 다층 분석 ▸ 배포 실패의 정확한 단계와 오류 메시지 파악 【오답 체크】 (A) VPC Flow Logs는 네트워크 수준, 배포 로직 문제 감지 X (B) CloudTrail은 AWS API 호출, 배포 실패 세부 정보 X (D) Trusted Advisor와 Health Dashboard는 배포 로그 제공 X 【시험 포인트】 CodeDeploy 문제 해결에서 로컬 에이전트 로그와 애플리케이션 로그의 중요성. 다층 로깅 전략(로컬 + CloudWatch + X-Ray).

해설

【핵심 용어】 ▸ Amazon DevOps Guru — ML 기반 이상 감지 및 권장 사항 ▸ SNS 알림 — 실시간 이벤트 알림 ▸ 자동화된 분석 — 운영 오버헤드 최소화 【정답 포인트】 ▸ A: DevOps Guru = 이상 감지 + 권장 사항 자동 제공 (ML 기반) ▸ B: SNS = 이상 감지 시 실시간 알림 ▸ A + B = 최소 오버헤드 (수동 분석 X) 【오답 체크】 (C) S3 + Athena + QuickSight는 수동 분석 및 설정 필요 (오버헤드 증가) (D) 이메일 보고서는 실시간 알림 X, 후속 응답 지연 (E) Athena 자체는 이상 감지 기능 없음, DevOps Guru가 필요 【시험 포인트】 Amazon DevOps Guru의 ML 기반 이상 감지 및 권장 사항 기능. 실시간 알림(SNS)과의 통합으로 운영 효율성 극대화.

해설

【핵심 용어】 ▸ AWS CodeArtifact — 관리형 아티팩트 저장소 (빠른 배포) ▸ VPN 연결 — 암호화된 공용 인터넷 연결 ▸ Direct Connect — 전용 네트워크 연결 (설정 시간 2주 초과) 【정답 포인트】 ▸ 2주 내 배포 = Direct Connect 불가능 (설정 기간 길음) ▸ C 선택: (1) VPN = 빠른 설정 + 암호화 (2) CodeArtifact = 관리형 + 고가용성 ▸ CodeArtifact = AWS 네이티브, 즉시 사용 가능 ▸ 공용 리포지토리 소비 + ECS 배포 통합 【오답 체크】 (B) (D) Direct Connect는 설정 시간 2-4주 (요구사항 초과) (B) (D) 타사 소프트웨어는 관리 오버헤드 증가 【시험 포인트】 AWS CodeArtifact의 빠른 배포 및 관리형 아티팩트 저장소 특성. Direct Connect vs VPN의 설정 시간 차이.

해설

【핵심 용어】 ▸ EKS Pod CIDR — 172.17.0.0/16 기본값 ▸ 네트워크 충돌 — VPC 서브넷과 Pod 네트워크 겹침 ▸ NodeCreationFailure — 워커 노드 클러스터 조인 실패 【정답 포인트】 ▸ EKS의 기본 Pod CIDR = 172.17.0.0/16 ▸ VPC 서브넷이 동일 CIDR 범위면 IP 충돌 발생 ▸ 워커 노드가 클러스터에 조인할 때 네트워크 설정 오류 ▸ A 선택 = VPC 서브넷 CIDR 변경 또는 Pod CIDR 재설정 【오답 체크】 (B) kubeconfig 자격 증명은 노드 조인 실패와 무관 (관리 플레인 액세스용) (C) 런북은 진단용, CIDR 충돌 해결 X (D) OIDC 공급자는 IRSA(IAM Roles for Service Accounts) 구성용, 노드 조인과 무관 【시험 포인트】 EKS 네트워크 설계에서 Pod CIDR와 VPC 서브넷 CIDR 충돌 가능성. NodeCreationFailure 오류의 네트워크 근본 원인.

해설

【핵심 용어】 ▸ 독립적 배포 — 파이프라인 분리 ▸ CodeDeploy vs S3 배포 — 배포 대상별 방식 ▸ 프론트엔드(S3) vs 백엔드(EC2) — 다양한 배포 메커니즘 【정답 포인트】 ▸ 요구사항: 프론트엔드와 백엔드 "독립적" 배포 ▸ D 선택: (1) 2개 파이프라인 = 독립적 트리거 가능 (2) 각 파이프라인 전용 배포 방식 ▸ 백엔드 파이프라인 = CodeDeploy (EC2용) (3) 프론트엔드 파이프라인 = S3 배포 ▸ 프론트엔드 변경 → 백엔드 빌드/배포 대기 X 【오답 체크】 (A) 단일 파이프라인 + CodeDeploy(프론트엔드) = S3 배포 아님, 비효율 (B) 단일 파이프라인 = 한 스테이지 실패 시 양쪽 배포 중단 (C) 2개 파이프라인이지만 프론트엔드를 CodeDeploy로 배포 = S3 미활용 【시험 포인트】 "독립적 배포" 요구사항에서 파이프라인 분리의 중요성. 배포 대상(EC2 vs S3)에 따른 액션 선택(CodeDeploy vs S3).

해설

【핵심 용어】 ▸ AWS Backup — 중앙 집중식 백업 관리 ▸ 고객 관리형 KMS — 최고 보안 (암호화 키 제어) ▸ AMI 백업 — EC2 전체 시스템 백업 【정답 포인트】 ▸ "가장 안전하게" = 고객 관리형 KMS 키 필수 ▸ A 선택: (1) 양쪽 계정의 고객 관리형 KMS (2) 전체 EC2 백업 → AMI (3) 중앙 복사 ▸ EBS 4개 볼륨 모두 포함 = 전체 시스템 복구 가능 ▸ 고객 관리형 KMS = 조직 정책 준수 (암호화 키 소유권) 【오답 체크】 (B) 소스 계정 KMS로 중앙 계정의 데이터 암호화 = 접근 제어 복잡, 보안 위험 (C) AWS 관리형 키 = 제한된 제어, 규제 요구사항 미충족 (D) 혼합형 KMS (고객 관리형 + AWS 관리형) = 보안 정책 일관성 부족 【시험 포인트】 AWS Backup의 중앙 집중식 관리 시 고객 관리형 KMS 키의 중요성. 규제 환경에서 암호화 키 소유권 확보.

해설

【핵심 용어】 ▸ AWS Health — AWS 서비스 상태 이벤트 ▸ EventBridge → CloudWatch Logs — 이벤트 수집 및 보관 ▸ 메트릭 필터 + 사용자 정의 메트릭 — 상관관계 분석 ▸ CloudWatch 경보 — 자동화된 알림 【정답 포인트】 ▸ B 선택: (1) EventBridge로 AWS Health 이벤트 캡처 (2) CloudWatch Logs로 보관 ▸ 메트릭 필터로 이벤트 분석 (3) 사용자 정의 메트릭 생성 (4) 경보로 자동화 ▸ 모든 요구사항(보관, 상관관계, 경보) 충족 【오답 체크】 (A) CloudTrail은 API 호출 기록용, AWS Health 이벤트 직접 로깅 아님 (C) SNS → Lambda는 복잡하며, 상관관계 분석 기능 부족 (D) X-Ray는 요청 추적용, AWS Health 이벤트 처리 X, GuardDuty는 보안 이상 탐지용 【시험 포인트】 EventBridge를 통한 AWS Health 이벤트 수집과 CloudWatch Logs 통합. 메트릭 필터로 애플리케이션 성능과의 상관관계 분석.

해설

【핵심 용어】 ▸ ECR Replication — 이미지를 다중 리전으로 자동 복제 ▸ Global Table — DynamoDB의 완전 관리형 다중 리전 솔루션 ▸ Multi-Region Access Point — S3 버킷에 단일 진입점 제공 ▸ Latency Routing — Route 53 정책으로 낮은 지연 경로 자동 선택 【정답 포인트】 ▸ ACE 조합이 최소 변경으로 고가용성 달성 ▸ (A) ECR 복제 + 지연 라우팅 = 효율적 이미지 배포 + 자동 지역 선택 ▸ (C) DynamoDB 글로벌 테이블 = 각 작업이 로컬 리전에서 읽기/쓰기 (낮은 지연) ▸ (E) Multi-Region Access Point + 양방향 복제 = S3 일관성 유지 + 단순한 애플리케이션 로직 【오답 체크】 ▸ (B) ap-southeast-2 DynamoDB만 사용 = eu-west-2에서 높은 지연, 성능 저하 ▸ (D) 양방향 복제는 충돌 해결 복잡 (PUT/GET 작업 시) ▸ (F) 장애 조치 정책 = 능동적 라우팅 아님 (지연 시간 고려 X) 【시험 포인트】 ▸ 다중 리전 확장: ECR, DynamoDB Global Table, Multi-Region Access Point 조합 ▸ 각 리전에서 로컬 자원 접근 원칙 (지연 최소화) ▸ Route 53 정책: Latency > Failover (성능 우선)