정답 · 해설

해설

【핵심 용어】 ▸ CloudWatch Logs Destination — 중앙화된 로그 수신 ▸ Subscription Filter — log group → destination 자동 연결 ▸ EventBridge + Lambda — 새 log group 자동 감지 【정답 포인트】 D: 전용 계정에 destination + Firehose → S3. EventBridge CreateLogGroup 감지로 자동 subscription filter 추가. 모든 기존/향후 log group 지원 【오답 체크】 A는 Organizations backup policy가 CloudWatch Logs 지원 안 함. B는 기존 log group만 지원(future 미지원). C는 Config 기반이지만 여전히 수동 작업 필요 【시험 포인트】 Multi-account CloudWatch Logs → Destination + Subscription Filter + EventBridge automation. Future-proof 솔루션.

해설

【핵심 용어】 ▸ CloudWatch Agent — 애플리케이션 메트릭 수집(sidecar) ▸ Step Scaling — alarm 기반 수동 조정 ▸ Target Tracking — metric 기반 자동 조정 ▸ OpenTelemetry + Prometheus — advanced metric collection 【정답 포인트】 A: CloudWatch agent (least overhead) + step scaling으로 간단하게 구현. D: Prometheus (advanced) + OpenTelemetry + target tracking으로 자동 조정 최적화 【오답 체크】 B는 metric filter가 간단한 text parsing만 (JVM 메트릭 구조화 어려움). C는 Prometheus rule이 scaling trigger 아님 【시험 포인트】 JVM metric scaling: 단순=CloudWatch agent + step scaling, 고급=Prometheus + target tracking. 둘 다 valid하지만 overhead 다름.

해설

【핵심 용어】 ▸ ECR Cross-Region Replication — 자동 이미지 복제 ▸ Aurora Global Database — 활성-활성 multi-region DB ▸ Operational efficiency — 자동화 및 최소 관리 【정답 포인트】 C: ECR CRR로 이미지 자동 복제 + Aurora global DB로 자동 data sync. 최소 운영 오버헤드 【오답 체크】 A는 S3 CRR가 ECR 이미지에 부적절. B는 Lambda 수동 구축 필요(overhead). D는 CodeBuild 수정 + binary log replication 복잡 【시험 포인트】 Multi-region application state = ECR CRR + Aurora global DB. 둘 다 fully managed, autonomous replication.

해설

【핵심 용어】 ▸ SNS → SQS Fan-out — 중복 메시지 처리(dead-letter queue 가능) ▸ SQS — 메시지 지속성, 재시도 로직 ▸ Concurrency Control — SQS 그룹 정책 【정답 포인트】 B: SNS → 각 Lambda별 SQS 큐로 fan-out. SQS의 visibility timeout + retry로 데이터 손실 방지. SQS Reserved Concurrency로 fine-tuning 【오답 체크】 A는 SNS direct subscribe로 retry 제한, 동시성 제어 불가. C는 구조 오류(이미 SQS에 구독된 Lambda가 SNS 메시지 수신 불가). D는 sequential이 아닌 parallel 필요 【시험 포인트】 Parallel Lambda 호출 + retry + concurrency tuning = SNS → SQS fan-out pattern. Enterprise-grade message buffering.

해설

【핵심 용어】 ▸ Regional API Endpoint — 단일 지역 배포 ▸ Edge-Optimized — CloudFront 캐싱(latency 최적화 아님) ▸ Latency-Based Routing — 사용자 가장 가까운 엔드포인트 【정답 포인트】 C: 각 지역의 regional endpoint + latency routing으로 최적 성능. 독립적 가용성 + 지역별 custom domain. 글로벌 배포 최적화 【오답 체크】 A는 edge-optimized가 regional resilience 제공 안 함. B는 regional endpoint를 ALB로 처리(복잡). D는 edge-optimized가 latency 기반 routing 미지원 【시험 포인트】 Globally deployed redundant API = regional endpoints in each region + latency-based Route 53 routing. Edge-optimized는 캐싱용, 아님 regional redundancy.

해설

【핵심 용어】 ▸ CodeBuild Local Cache — Docker 레이어 캐시로 빌드 성능 최적화 ▸ Amazon ECR — 컨테이너 이미지 저장 및 재사용 【정답 포인트】 ▸ CodeBuild local Docker layer cache 기능은 각 빌드 사이에 Docker 레이어를 재사용하여 빌드 시간을 단축합니다. ▸ ECR은 관리형 컨테이너 레지스트리로 이미지 저장 및 배포에 최적화되어 있습니다. ▸ 로컬 캐시는 CodeBuild 환경 내에서 레이어를 캐시하므로 빌드 성능이 크게 향상됩니다. 【오답 체크】 (B) S3는 컨테이너 이미지 저장용으로 설계되지 않았으며, 여러 빌드 호스트에서 캐시 관리가 복잡합니다. (C) 이미지 버전만 변경해도 캐시 효과가 없으며, 빌드 성능 개선이 안 됩니다. (D) 사용자 지정 AMI는 유지 관리 오버헤드가 크고, 수동으로 이미지를 업데이트해야 합니다. 【시험 포인트】 CodeBuild의 캐시 메커니즘은 S3, ECR, 로컬 캐시 3가지입니다. local Docker layer cache는 대용량 이미지 캐싱에 가장 효율적입니다.

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — 조직 내 계정의 최대 권한을 제한하는 정책 ▸ Deny 문 — SCP는 허용을 기반으로 하지 않고, 명시적 거부로 제한합니다. 【정답 포인트】 ▸ SCP는 항상 거부(Deny) 문으로 작성되어야 합니다. 허용(Allow)은 IAM 정책의 역할입니다. ▸ "not equal to t3.small" 조건은 t3.small이 아닌 모든 인스턴스 타입을 거부하므로, t3.small만 허용됩니다. ▸ "not equal to us-*" 조건은 us-로 시작하지 않는 모든 리전을 거부합니다. ▸ 두 개의 거부 문을 함께 사용하면 조건을 모두 만족합니다. 【오답 체크】 (B) Allow 문은 SCP에서 사용하지 않습니다. SCP는 거부 문 기반입니다. (C) "equal to t3.small"은 t3.small을 거부하므로, 정반대입니다. (D) Allow 문을 사용하고 조건도 반대입니다. 【시험 포인트】 SCP 정책 구조: SCP는 항상 거부(Deny) 기반이며, "not equal to" 조건으로 허용 범위를 제한합니다.

해설

【핵심 용어】 ▸ ApproximateNumberOfMessagesVisible — 대기열에 현재 있는 메시지 수(지연되지 않음) ▸ ApproximateNumberOfMessagesDelayed — 처리 지연으로 인한 메시지 수 ▸ CloudWatch 메트릭 경보 — 정적 임계값으로 간단하고 효율적인 모니터링 【정답 포인트】 ▸ ApproximateNumberOfMessagesVisible은 대기열의 현재 크기를 반영하며, 처리 지연 여부와 관계없이 모든 가시적 메시지를 나타냅니다. ▸ 메트릭 경보는 간단하고 운영 오버헤드가 최소입니다. Lambda + EventBridge는 불필요한 복잡성을 추가합니다. ▸ 1시간 기간으로 충분한 모니터링 간격을 제공합니다. 【오답 체크】 (A) ApproximateNumberOfMessagesDelayed는 지연된 메시지만 포함하므로, 현재 대기열 크기의 전체 상황을 반영하지 못합니다. (C) (D) Lambda + EventBridge는 불필요한 복잡성을 도입하며, CloudWatch 메트릭 경보보다 관리 부담이 큽니다. 【시험 포인트】 SQS 메트릭: ApproximateNumberOfMessagesVisible은 현재 대기열 크기를 반영하고, 가장 효율적인 모니터링 방식은 CloudWatch 메트릭 경보입니다.

해설

【핵심 용어】 ▸ CloudTrail Organization Trail — 조직 내 모든 계정의 활동을 중앙에서 로깅 ▸ CloudWatch Metrics Insights — CloudTrail 로그에 대한 SQL 쿼리 분석 도구 【정답 포인트】 ▸ Organization Trail은 관리 계정에서 모든 멤버 계정의 로그를 수집하므로 중앙 집중식 모니터링을 제공합니다. ▸ CloudWatch Metrics Insights는 CloudTrail 로그를 직접 쿼리할 수 있는 SQL 쿼리 도구입니다. ▸ CloudWatch 이상 탐지는 메트릭 기반 이상 탐지를 제공합니다. ▸ 조직 전체 관점에서 보안 모니터링을 일원화합니다. 【오답 체크】 (A) 각 계정별 개별 추적은 중앙 집중식 모니터링이 아니며, GuardDuty는 이상 탐지용이 아닙니다. (B) Athena는 S3 쿼리 도구이며, CloudTrail 로그 분석용이 아닙니다. (D) 개별 추적과 사용자 지정 이상 탐지 솔루션은 복잡하고 확장성이 낮습니다. 【시험 포인트】 Multi-account monitoring: Organization Trail + CloudWatch Metrics Insights는 중앙 집중식 로깅 및 분석을 위한 표준입니다.

해설

【핵심 용어】 ▸ HPA(Horizontal Pod Autoscaler) — Pod 개수 확장 ▸ Cluster Autoscaler — 노드 개수 확장 ▸ 자동 확장 계층 — Pod → Node 순서로 확장 【정답 포인트】 ▸ HPA는 특정 CPU 사용률 기준으로 Pod을 확장합니다. ▸ Cluster Autoscaler는 Pod 확장 시 노드가 부족하면 자동으로 노드를 추가합니다. ▸ auto-discovery 설정은 Auto Scaling 그룹을 자동으로 감지하여 관리합니다. ▸ HPA + Cluster Autoscaler는 Pod와 Node 수준의 이중 자동 확장을 제공합니다. 【오답 체크】 (A) Auto Scaling 그룹 수준의 CPU 기반 확장은 Pod별 세분화된 제어가 없습니다. (B) VPA는 Pod 리소스 요청/제한을 조정하는 용도이지, CPU 사용률 기반 확장이 아닙니다. (C) Systems Manager는 노드 그룹 크기를 수동으로 변경하는 용도이지, 자동 확장이 아닙니다. 【시험 포인트】 EKS 자동 확장: HPA (Pod) + Cluster Autoscaler (Node) 조합이 표준입니다.

해설

【핵심 용어】 ▸ IAM Identity Center Attribute Mapping — IdP 속성을 AWS 속성으로 매핑 ▸ aws:PrincipalTag — Principal의 태그를 조건으로 사용 ▸ ec2:ResourceTag — 리소스의 태그를 조건으로 사용 【정답 포인트】 ▸ ${path:enterprise.department}는 IAM Identity Center에서 사용자의 부서 정보를 나타냅니다. ▸ aws:PrincipalTag/department는 사용자의 부서 태그에 접근하는 조건 키입니다. ▸ ec2:ResourceTag/department는 EC2 인스턴스의 부서 태그에 접근하는 조건 키입니다. ▸ 정책에서 두 태그를 비교하여 일치하는 리소스에만 접근을 허용합니다. ▸ 이 방식은 속성 기반 액세스 제어(ABAC)의 표준입니다. 【오답 체크】 (A) (B) (D) 정확한 조건 키가 제시되지 않아 평가 불가능합니다. 【시험 포인트】 IAM Identity Center + ABAC: aws:PrincipalTag와 ec2:ResourceTag 조건 키를 사용하여 속성 기반 정책을 작성합니다.

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — 조직 차원의 권한 제한 ▸ cloudtrail:StopLogging — CloudTrail 로깅 중지 ▸ cloudtrail:DeleteTrail — CloudTrail 추적 삭제 【정답 포인트】 ▸ SCP는 조직의 모든 계정에 적용되므로 사용자가 권한을 우회할 수 없습니다. ▸ IAM 정책은 개별 계정별로 설정해야 하므로 일관성 보장이 어렵습니다. ▸ cloudtrail:StopLogging과 cloudtrail:DeleteTrail을 모두 거부하여 CloudTrail을 비활성화하지 못하도록 합니다. ▸ 모든 OU에 SCP를 적용하면 조직 전체에서 정책이 강제됩니다. 【오답 체크】 (B) IAM 정책은 개별 계정별로만 적용되며, 조직 전체에 일관되게 적용되지 않습니다. (C) (D) 반응형 모니터링이나 자동 복구로는 로깅 중지를 완전히 방지할 수 없습니다. 【시험 포인트】 Multi-account enforcement: SCP는 조직 차원의 정책 강제 도구입니다.

해설

【핵심 용어】 ▸ Blue/Green Deployment — 새 버전으로 전환 전 테스트 ▸ Target Group Switching — 트래픽 전환 메커니즘 ▸ Rolling Restart — 무중단 애플리케이션 업데이트 【정답 포인트】 ▸ Green 환경의 인스턴스가 먼저 새 버전으로 배포되어야 합니다. ▸ 배포 완료 후 ALB의 대상 그룹을 Green으로 전환하면 트래픽이 한 번에 이동합니다. ▸ ALB 대상 그룹 전환은 원자적(atomic) 트래픽 전환을 보장합니다. ▸ Route 53 변경은 필요 없으며(ALB는 이미 지정됨), 대상 그룹만 변경하면 됩니다. 【오답 체크】 (B) ALB를 먼저 변경하면 배포 중인 인스턴스로 트래픽이 가므로 불완전한 배포 상태입니다. (C) Blue와 Green을 혼합하면 Blue/Green 배포의 목적을 잃습니다. (D) Route 53 변경은 ALB 엔드포인트 변경이 아니며, ALB 대상 그룹 전환만으로 충분합니다. 【시험 포인트】 Blue/Green with ALB: 배포 완료 후 대상 그룹 전환으로 트래픽 한 번에 이동.

해설

【핵심 용어】 ▸ Metric Math — CloudWatch에서 메트릭을 사용하여 계산된 메트릭 생성 ▸ Target Tracking Scaling Policy — 메트릭 기반 자동 확장 ▸ Messages per Instance — 인스턴스당 대기열 메시지 수 【정답 포인트】 ▸ CPU 기반 확장은 I/O 바운드 작업(SQS 처리)에서 신뢰할 수 없습니다. ▸ 메트릭 수학을 사용하여 (ApproximateNumberOfMessagesVisible / GroupInServiceInstances)를 계산합니다. ▸ 이 값이 임계값을 초과하면 자동으로 확장됩니다. ▸ 추가 Lambda 함수나 EventBridge 규칙 없이 CloudWatch 기본 기능만 사용합니다. ▸ 가장 간단하고 운영 오버헤드가 적습니다. 【오답 체크】 (A) (B) Lambda + EventBridge는 복잡성을 추가하며, 예약된 간격으로만 메트릭을 업데이트합니다. (D) 로그 기반 메트릭 필터는 지연되며, 실시간 자동 확장에 부적합합니다. 【시험 포인트】 Queue-based scaling: 메트릭 수학으로 "메시지/인스턴스"를 계산하는 것이 표준입니다.

해설

【핵심 용어】 ▸ AWS Config Managed Rule — 규정 준수 모니터링 ▸ ec2-instance-profile-attached — EC2 인스턴스 프로필 연결 여부 확인 ▸ 자동 수정(Remediation) — 규정 위반 시 자동 조치 【정답 포인트】 ▸ AWS Config ec2-instance-profile-attached 규칙은 기존 인스턴스와 새 인스턴스 모두를 모니터링합니다. ▸ 자동 수정은 프로필이 없는 모든 인스턴스에 기본 프로필을 연결합니다. ▸ EventBridge는 새 인스턴스(RunInstances)만 처리하므로 기존 인스턴스를 놓칩니다. ▸ AWS Config는 지속적인 규정 준수 모니터링을 제공합니다. 【오답 체크】 (A) EventBridge RunInstances는 새 인스턴스만 처리하며, 이미 생성된 인스턴스는 처리할 수 없습니다. (C) StartInstances는 시작 이벤트이므로, 프로필 연결과는 관계없습니다. (D) iam-role-managed-policy-check는 IAM 역할 정책을 확인하는 규칙이지, 인스턴스 프로필 연결을 확인하지 않습니다. 【시험 포인트】 Compliance monitoring: AWS Config Managed Rule은 기존 및 신규 리소스 모두를 모니터링합니다.

해설

【핵심 용어】 ▸ Delegated Administrator — 특정 서비스 관리 권한을 위임받은 계정 ▸ Permission Set — IAM Identity Center의 권한 정책 ▸ AWSSSOMemberAccountAdministrator — 멤버 계정 관리 권한 【정답 포인트】 ▸ (B) Organizations 관리 계정에서 IAM Identity Center를 활성화합니다(필수). ▸ (B) 새 IAM 팀 계정을 IAM Identity Center 위임된 관리자로 등록합니다(권한 최소화). ▸ (D) IAM Identity Center 사용자/그룹 및 권한 세트를 생성합니다. ▸ (F) IAM 팀은 새 계정(위임된 관리자)에서만 작동하므로, Organizations 관리 계정에 접근하지 않습니다. ▸ 이 구조로 최소 권한 원칙과 조직 분리를 유지합니다. 【오답 체크】 (A) 새 계정에서만 IAM Identity Center를 활성화하면 조직 전체에 적용되지 않습니다. (C) SCP로 관리 계정의 IAM Identity Center를 거부하면 조직 전체 설정이 불가능합니다. (E) IAM 팀에게 관리 계정 액세스를 부여하면 최소 권한 원칙 위반입니다. 【시험 포인트】 IAM Identity Center delegation: 관리 계정 설정 + 멤버 계정 위임 관리자 + 해당 계정에서만 권한 부여.

해설

【핵심 용어】 ▸ Aurora Global Database — 다중 리전 복제 ▸ RPO(Recovery Point Objective) — 허용되는 데이터 손실 시간 ▸ Write Amplification — 동기 복제로 인한 쓰기 지연 【정답 포인트】 ▸ Aurora 글로벌 데이터베이스는 모든 보조 클러스터에 동기 복제를 사용합니다. ▸ RPO 60초는 쓰기 작업이 모든 보조 리전에 도달할 때까지 기다리는 것을 의미합니다. ▸ 보조 클러스터 개수가 많을수록 동기 복제 지연이 커집니다. ▸ 보조 클러스터 하나를 제거하면 복제 지연이 감소하여 쓰기 차단이 줄어듭니다. ▸ RPO 60초는 그대로 유지되지만(동일 설정), 실제 차단 시간이 줄어듭니다. 【오답 체크】 (A) 보조 클러스터를 추가하면 더 많은 복제 대상이 생겨 지연이 증가합니다. (B) Write Forwarding은 읽기 전용 보조 리전에서 쓰기를 허용하지만, 주요 쓰기 차단 문제를 해결하지 못합니다. (D) 동기 복제는 이미 사용 중이며, 더 강화하면 차단이 더 심해집니다. 【시험 포인트】 Aurora Global Database RPO: 보조 리전 감소 = 복제 지연 감소 = 쓰기 차단 감소.

해설

【핵심 용어】 ▸ CloudWatch Agent — 메트릭 및 로그 수집 ▸ IAM Roles for Service Accounts (IRSA) — Kubernetes에서 AWS IAM 역할 사용 ▸ EKS Control Plane Logging — EKS API 서버 로그 【정답 포인트】 ▸ (A) CloudWatch Agent를 StatefulSet으로 배포하여 메트릭 및 로그를 수집합니다. ▸ (C) CloudWatchAgentServerPolicy는 에이전트가 필요한 최소 권한을 제공합니다. ▸ (E) IRSA를 통해 Kubernetes 서비스 계정이 IAM 역할을 사용할 수 있게 합니다. ▸ (F) EKS 제어 평면 로깅은 클러스터의 API 활동을 추적합니다. ▸ 이 조합으로 애플리케이션 메트릭, 로그, 제어 평면 로그를 모두 수집합니다. 【오답 체크】 (B) OpenTelemetry Collector는 분산 추적용이며, CloudWatch Agent와 중복입니다. (D) CloudWatchAgentAdminPolicy는 필요 이상의 권한을 제공하므로 최소 권한 원칙 위반입니다. 【시험 포인트】 EKS observability: CloudWatch Agent + IRSA + Control Plane Logging의 조합으로 포괄적 모니터링.

해설

【핵심 용어】 ▸ CodeGuru Security — 코드 취약점 정적 분석 도구 ▸ AWS Inspector — 인프라 취약점 스캔(EC2, ECR 이미지용) ▸ CodePipeline Stage — 파이프라인 단계 추가 【정답 포인트】 ▸ CodeGuru Security는 Python, Java 등 소스 코드 취약점을 분석합니다. ▸ Amazon Inspector는 EC2 인스턴스 및 ECR 이미지의 런타임 취약점을 검사합니다. ▸ 소스 코드 스캔이 필요하므로 CodeGuru Security를 사용합니다. ▸ CodeBuild + CodeGuru Security는 CodePipeline의 표준 보안 검사 패턴입니다. ▸ IAM 역할에 CodeGuru Security 권한을 추가하면 최소 권한을 보장합니다. 【오답 체크】 (B) Amazon Inspector는 코드 분석이 아닌 인프라/컨테이너 취약점 스캔용입니다. (C) (D) DevOps Guru와 CodeGuru Security는 CodePipeline 작업 공급자가 아닙니다. 【시험 포인트】 Code security scanning in CodePipeline: CodeBuild + CodeGuru Security가 표준입니다.

해설

【핵심 용어】 ▸ CloudWatch DetailedMonitoring — 60초 간격 메트릭 (기본 모니터링은 300초) ▸ CloudWatch Agent — 메모리, 디스크, 프로세스 등 사용자 지정 메트릭 수집 ▸ NetworkIn — EC2 인스턴스 기본 제공 메트릭 【정답 포인트】 ▸ NetworkIn은 EC2 기본 모니터링의 기본 제공 메트릭입니다. ▸ 세부 모니터링은 60초 간격으로 데이터를 수집합니다(기본 300초). ▸ MemoryBytesUsed는 존재하지 않는 메트릭입니다. EC2 기본 모니터링은 메모리 메트릭을 제공하지 않습니다. ▸ mem_used는 CloudWatch Agent에서 제공하는 메모리 사용률 메트릭입니다. ▸ Detailed Monitoring (60초) + CloudWatch Agent (mem_used)의 조합이 필요합니다. 【오답 체크】 (A) 기본 모니터링은 300초 간격이므로 요구 사항을 충족하지 못합니다. MemoryBytesUsed 메트릭은 존재하지 않습니다. (B) MemoryBytesUsed는 존재하지 않는 메트릭입니다. (D) 기본 모니터링은 300초 간격입니다. 【시험 포인트】 CloudWatch metrics: Detailed Monitoring (60초) + CloudWatch Agent (커스텀 메트릭) 조합.