정답 · 해설

해설

【핵심 용어】 ▸ CodeArtifact — NPM 저장소 호스팅 (업스트림 연결 지원) ▸ Upstream Repository — 공개 npm에 자동 페치 ▸ Package Status Unlisted — 승인되지 않은 버전 숨김 【정답 포인트】 ▸ CodeArtifact가 npm-store 업스트림으로 공개 저장소와 자동 연결 ▸ CodePipeline이 새 버전 자동 감지 및 검증 ▸ 검증 실패 시 unlisted로 설정 (자동 숨김) ▸ CodeBuild는 CodeArtifact만 사용 (매우 간단) 【오답 체크】 (B) S3 캐싱은 저장소 역할 불가 (매번 다운로드) (C) CodeCommit은 NPM 저장소 아님 (npm install 미지원) (D) CodeCommit을 NPM 저장소로 사용 불가능 (복잡성 증가) 【시험 포인트】 NPM 버전 검증: CodeArtifact(호스팅 + 업스트림) → CodePipeline(검증) → 상태 제어(unlisted)

해설

【핵심 용어】 ▸ RTO/RPO 목표 — 30분 이내 복구 시간 및 데이터 손실 최소화 ▸ DR 비용 최소화 — 대기 환경에서 리소스 사용 최소화 ▸ CloudFront Origin Failover — 단일 CloudFront에서 여러 오리진 간 자동 페일오버 【정답 포인트】 A는 CloudFront의 Origin Failover 기능을 활용하므로 단일 CloudFront 배포로 운영/DR 환경을 관리합니다. Auto Scaling 그룹 용량을 0으로 설정하여 DR 환경에서 대기 중인 리소스만 유지하므로 비용이 최소화됩니다. AMI 복사와 OpenSearch 클러스터 간 복제로 30분 이내 RTO/RPO를 충족합니다. 【오답 체크】 B와 C는 DR 리전에 별도의 CloudFront를 생성하므로 관리 복잡도 증가, Route 53 DNS 페일오버 지연 발생. D는 Auto Scaling 용량을 3으로 설정하여 DR 환경 비용이 증가. 【시험 포인트】 CloudFront Origin Failover는 CloudFront 하나로 여러 리전을 관리하는 핵심 기능. DR 환경에서는 대기 상태(capacity 0)로 비용을 줄이되, 필요시 빠르게 확장 가능해야 함.

해설

【핵심 용어】 ▸ AWS Config Managed Rules — alb-waf-enabled 규칙으로 WAF 연결 상태 모니터링 ▸ Auto Remediation — 규칙 위반 시 자동 수정 작업 실행 ▸ Systems Manager Automation — 수정 작업으로 AWS WAF 자동 추가 【정답 포인트】 A는 AWS Config의 관리형 규칙으로 ALB의 WAF 연결 상태를 계속 모니터링합니다. 규칙 위반(WAF 제거) 감지 시 Systems Manager Automation 문서가 자동으로 실행되어 WAF를 다시 추가합니다. 운영 개입 없이 자동 수정되므로 효율성이 높습니다. 【오답 체크】 B는 Lambda 함수를 사용하여 detective 모드로 검사만 수행하므로 자동 수정 불가. C와 D는 detect-stack-drift를 사용하지만 CloudFormation 레벨에서만 작동하며, WAF 추가 로직이 명확하지 않음. 【시험 포인트】 AWS Config Auto Remediation은 정책 강제(compliance enforcement)의 핵심 패턴. Managed Rules + Automation으로 최소 개입으로 규정 준수 유지.

해설

【핵심 용어】 ▸ AWS CodeBuild — 완전 관리형 빌드 서비스, 부하 테스트 도구 실행 가능 ▸ CodePipeline Native Integration — CodeBuild는 CodePipeline과 네이티브 통합 ▸ Performance Gate — Lambda 함수로 성능 기준 검증 후 배포 결정 【정답 포인트】 D는 CodeBuild(완전 관리형)로 테스트를 실행하여 서버 관리 오버헤드가 최소화됩니다. CodePipeline과 네이티브 통합되므로 별도의 통합 로직이 불필요합니다. Lambda 함수로 임계값 검증 후 자동으로 배포 진행/중단을 결정합니다. 【오답 체크】 A는 Elastic Beanstalk 추가 구성 필요, Fargate/ECS 오버헤드 (B) 또는 EC2/Step Functions 관리 복잡도 (C) 가 높음. 【시험 포인트】 CodePipeline 통합 패턴: CodeBuild는 빌드/테스트 표준, Lambda는 의사결정 로직. Performance validation gate는 배포 전 품질 검증의 핵심.

해설

【핵심 용어】 ▸ Multi-AZ Deployment — 주 DB와 대기 DB를 별도 AZ에 배치, 자동 페일오버 ▸ Synchronous Replication — 주 DB의 데이터를 대기 DB에 즉시 동기화 ▸ Stateful Database — 트랜잭션 이력 유지 필수 【정답 포인트】 D는 RDS Multi-AZ 배포로 단 하나의 설정 변경만으로 고가용성을 달성합니다. 주 인스턴스 장애 시 자동으로 대기 인스턴스로 페일오버되므로 가용성이 높고, 동기 복제로 데이터 손실이 없습니다. 기존 애플리케이션 코드 변경이 불필요합니다. 【오답 체크】 A는 DynamoDB로 마이그레이션하면 애플리케이션 구조 대대적 변경 필요. B는 EBS Multi-Attach가 single-writer로만 작동하므로 고가용성 보장 안 됨. C는 읽기 전용 복제본이므로 쓰기 작업(주문 저장) 처리 불가. 【시험 포인트】 RDS 고가용성: Multi-AZ는 기본 선택, 읽기 확장은 read replicas 추가. Stateful 데이터는 DynamoDB 마이그레이션 보다는 RDS 아키텍처 최적화.

해설

【핵심 용어】 ▸ CodeBuild webhook trigger — Pull Request 이벤트로 자동 테스트 실행 ▸ Build status reporting — PR에 테스트 결과 표시 ▸ buildspec reports section — 테스트 리포트(coverage, test results) 생성 ▸ artifacts section — 바이너리/데이터 파일을 S3 저장 【정답 포인트】 A(IAM role)는 필수 기초. B(CodeBuild webhook + build status reporting)로 Pull Request 연동과 결과 표시 달성. D(artifacts)로 출력 파일을 S3에 저장. 단, buildspec의 reports는 테스트 리포트(JUnit XML 등), artifacts는 바이너리/데이터 파일 저장용이므로 둘 다 필요할 수 있음. E(appspec.yml)는 CodeDeploy 배포 설정으로 이 시나리오와 무관. 【오답 체크】 A는 CodePipeline stage 기반이므로 Pull Request webhook 지원 불충분. CodeBuild의 webhook이 Pull Request 트리거로 더 직접적. C와 D 중 artifacts가 데이터 파일 S3 저장에 적합. 【시험 포인트】 CodeBuild Pull Request integration: webhook trigger → build status reporting PR comment로 결과 표시 → artifacts/reports로 S3 저장.

해설

【핵심 용어】 ▸ CodeBuild artifact configuration — S3를 아티팩트 저장소로 설정 ▸ buildspec.yml artifacts block — 아티팩트 경로 및 S3 위치 정의 ▸ CodeBuild service role — S3 접근 권한을 위임받는 IAM 역할 【정답 포인트】 B는 정확한 AWS CodeBuild 아티팩트 설정 방식을 설명합니다. S3 버킷을 buildspec 파일에서 아티팩트 출력 위치로 설정하고, CodeBuild service role(not resource role)에 S3 접근 권한을 부여합니다. CodeBuild는 서비스 역할로 S3에 아티팩트를 업로드합니다. 【오답 체크】 A는 "리소스 액세스 역할"이라는 부정확한 표현. C는 EFS가 아티팩트 저장소가 아님(네트워크 스토리지용). D는 EBS 볼륨이 CodeBuild와 통합되지 않음. 【시험 포인트】 CodeBuild 아티팩트 저장: S3가 표준 → buildspec artifacts 설정 + CodeBuild service role IAM 권한 조합. EFS/EBS는 아티팩트 저장소로 미지원.

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — AWS Organizations 레벨에서 권한 통제 ▸ CodeConnections repository link — Git 리포지토리 메타데이터 연결 ▸ CloudFormation stack sync — 리포지토리 코드 변경을 CloudFormation에 자동 반영 【정답 포인트】 A(SCP deny)로 특정 Git 공급자가 아닌 연결 차단하여 정책 강제. C(단일 CodeConnections 연결)로 각 리포지토리에 하나의 연결 설정으로 관리 간편화. E(repository link + CloudFormation sync)로 CloudFormation이 Git 리포지토리와 자동 동기화되어 여러 리전에서 IaC 배포. B는 allow SCP이므로 실질적 제한 안 됨. D는 각 리전마다 연결 생성으로 오버헤드. F는 CodePipeline으로 추가 복잡도. 【오답 체크】 B는 allow만으로는 정책 강제 불충분. D는 다중 리전 연결로 운영 비효율. F는 CloudFormation stack sync를 활용하지 않아 배포 자동화 미흡. 【시험 포인트】 CodeConnections Organization-level governance: SCP로 정책 강제 → repository link로 메타데이터 단일화 → CloudFormation sync로 IaC 자동 배포.

해설

【핵심 용어】 ▸ Nested stack — CloudFormation 템플릿 내에서 다른 템플릿을 스택으로 배포 ▸ StackStatusReason — 스택 실패 이유 메시지 ▸ ParentId property — 중첩 스택의 부모 스택 식별자 【정답 포인트】 B는 CloudFormation API를 사용하여 중첩 스택의 구체적 실패 원인을 파악합니다. ParentId로 루트 스택을 기준으로 하위 중첩 스택 조회, StackStatusReason으로 각 스택의 실패 메시지(IAM 권한 부족, 유효하지 않은 파라미터 등) 확인. 직접적이고 신속한 진단 가능. 【오답 체크】 A는 detect root cause가 AWS 공식 기능이 아님(misleading). C는 Systems Manager runbook이 CloudFormation 커스텀 리소스 문제 진단 용도로 과도한 설정. D는 CloudFormation 템플릿 로깅이 실패 원인 파악에 직접적 도움이 아님. 【시험 포인트】 CloudFormation troubleshooting: 중첩 스택 실패 → list-stacks + ParentId로 계층 조회 → StackStatusReason 메시지로 근본 원인 파악이 표준 방식.

해설

【핵심 용어】 ▸ Route 53 weighted routing — 가중치 기반 트래픽 분산 ▸ Health check — 엔드포인트 상태 확인, 가중치 0 레코드로 전환 ▸ Warm standby — 사전 구성되었으나 실제 트래픽 미처리 【정답 포인트】 A는 Route 53 weighted routing으로 주 인스턴스(weight 100)와 대기 인스턴스(weight 0) 설정. 주 인스턴스 health check 실패 시 Route 53이 자동으로 대기 인스턴스(weight 0)로 전환. 상태 저장 서비스는 EFS 공유로 즉시 복구. ALB 추가 없이 Route 53만으로 simple failover 구현 가능. 【오답 체크】 B는 weight 99:1로 설정하면 1% 트래픽이 대기로 유입되어 상태 저장 데이터 불일치 발생. C와 D는 ALB 추가로 불필요한 복잡도 증가. 【시험 포인트】 Route 53 failover patterns: Failover routing(명시적 active/passive) vs. Weighted routing(health check + weight 0으로 passive failover). Stateful 서비스는 ALB 추가 불필요, DNS failover로 충분.

해설

【핵심 용어】 ▸ CloudWatch metric filters — 로그 데이터로부터 커스텀 메트릭 생성 ▸ Bytes ingested — CloudWatch 청구 기준 메트릭 ▸ Cost attribution — 각 로그 그룹의 수집 비용 추적 【정답 포인트】 A는 CloudWatch metric filter로 각 로그 그룹의 "bytes ingested" 메트릭을 추출하여 가장 데이터를 많이 수집하는 애플리케이션을 시각화. 대시보드에서 그래프로 추이 관찰 가능, 비용 최적화 대상 명확. 운영 효율성: 즉시 가시성 확보, 자동화 모니터링. 【오답 체크】 B는 Logs Insights로 로그 개수만 파악(수집 바이트 수 미파악), 비용 원인 분석 불충분. C는 AWS 계정 레벨 비용 분석이므로 애플리케이션 레벨 상세 파악 불가. D는 CloudTrail로 API 호출 추적(로그 생성 빈도 아님), 데이터 볼륨 측정 불가. 【시험 포인트】 CloudWatch cost optimization: metric filter로 log group별 bytes ingested → 대시보드 추시 → 이상 로그 그룹 신속 식별 후 로그 레벨/필터링 조정.

해설

【핵심 용어】 ▸ Cross-account access — PipelineAccount의 S3/KMS를 CodeDeployAccount에서 접근 ▸ Role assumption — 계정 A의 역할이 계정 B의 역할 가정 ▸ Trust policy — 특정 계정/서비스가 역할 가정 가능하도록 설정 【정답 포인트】 A는 정확한 크로스 계정 접근 체인을 설명합니다. (1) S3 버킷 정책: CodeDeployAccount 계정이 S3 접근 가능 (2) DevOps_Role 신뢰 정책: PipelineAccount의 CodePipeline_Service_Role이 가정 가능 (3) CodePipeline_Service_Role: DevOps_Role 가정 권한. 흐름: CodePipeline(PipelineAccount) → assume DevOps_Role(CodeDeployAccount) → access S3/KMS. 【오답 체크】 B는 DevOps_Role이 CodePipeline_Service_Role을 가정하려고 함(역방향, 불가능). C는 S3 정책을 PipelineAccount에만 부여하여 CodeDeployAccount 접근 불가. D는 DevOps_Role 신뢰 정책이 CodeDeployAccount만 가정 가능(PipelineAccount 제외). 【시험 포인트】 Cross-account role assumption: source account의 역할 → assume → target account의 역할 → resource 접근. 신뢰 정책에 source principal 명시 필수.

해설

【핵심 용어】 ▸ CloudTrail events — RunInstances 등 EC2 생성 이벤트 ▸ EventBridge integration — CloudTrail 이벤트를 이벤트로 변환, Lambda 트리거 ▸ Auto-tagging — 생성 직후 자동 태그 추가 【정답 포인트】 D는 EventBridge에서 CloudTrail 이벤트(EC2 RunInstances)를 감지하여 Lambda 함수 트리거. Lambda는 CloudTrail 이벤트에서 user ID, cost center 정보 추출하여 EC2 리소스에 태그 자동 추가. 1시간 이내 요구사항 충족. 『정확한 흐름』CloudTrail → S3 저장 → EventBridge rule(CloudTrail events) → Lambda invoke → EC2 tagging. 【오답 체크】 A는 S3 object tagging(CloudTrail 로그 객체) 이벤트로, EC2 리소스 태그와 무관. B는 서버 로깅만으로 자동 태그 불가. C는 AWS Config compliance checking(remediation 미흡), 생성 직후 자동 태그 불가. 【시험 포인트】 Multi-account auto-tagging pattern: CloudTrail events → EventBridge → Lambda 자동화. 1시간 SLA 충족하려면 이벤트 기반 트리거 필수(스케줄 기반 불가).

해설

【핵심 용어】 ▸ AWS CodeArtifact — 아티팩트 저장소, upstream repository 연결로 오픈소스 패키지 캐싱 ▸ Semantic versioning — major.minor.patch 버전 스키마 ▸ Build cache — 오픈소스 의존성 빌드 시간 단축 【정답 포인트】 A는 표준 artifact management 패턴입니다. CodeArtifact 리포지토리는 upstream 리포지토리(Maven Central, npm registry 등) 연결로 오픈소스 패키지 자동 캐싱. CodeBuild 프로젝트는 의미 있는 버전으로 컴파일하여 CodeArtifact에 발행. 캐싱으로 빌드 속도 향상, 버전 관리 중앙화. 【오답 체크】 B는 CodeDeploy(배포 도구)로 아티팩트 저장 미지원, EFS는 버전 관리 불가. C는 "AWS Artifact"가 아티팩트 저장소 아님(compliance documents). D는 Lambda로 수동 패키지 관리(비효율), CodeArtifact 장점 미활용. 【시험 포인트】 DevOps artifact management: CodeArtifact(upstream cache + version control) + CodeBuild(semantic version build) 조합 표준. 캐싱으로 의존성 다운로드 속도 극적 개선.

해설

【핵심 용어】 ▸ AWS FIS (Fault Injection Service) — 복원력 테스트를 위해 장애 시뮬레이션 ▸ CodePipeline Lambda action — 파이프라인에서 Lambda 함수 호출 ▸ Chaos engineering — 파이프라인 배포 후 복원력 검증 【정답 포인트】 C는 CodePipeline의 standard Lambda action으로 FIS 실험을 시작합니다. Lambda 함수는 AWS FIS StartExperiment API 호출, 실험 완료 대기, 결과 검증 로직 포함. 파이프라인 단계 내에 통합되므로 배포-테스트-복원력검증 자동화 달성. 【오답 체크】 A는 "AWS FIS action"이 CodePipeline에서 공식 지원되지 않음(native action 아님). B는 EventBridge 스케줄러로 파이프라인 통합 미흡(trigger 메커니즘 부재). D는 Jenkins + buildspec 불필요 복잡도. 【시험 포인트】 CodePipeline chaos testing integration: Lambda action으로 FIS StartExperiment → wait for completion → validate resilience metrics. 표준 패턴.

해설

【핵심 용어】 ▸ ECR pull-through cache — 외부 레지스트리 이미지 캐싱, 로컬 저장소 분리 ▸ Basic vulnerability scanning — ECR 이미지 스캔 기능 ▸ Resilience — upstream 리포지토리 중단 시에도 캐시된 이미지 사용 【정답 포인트】 D는 ECR pull-through cache와 기본 스캔 조합으로 모든 요구사항 충족. Private 리포지토리는 기본 스캔 활성화, pull-through cache 규칙으로 외부 이미지 로컬 캐싱. Upstream 리포지토리 중단 시 캐시된 이미지 재사용으로 파이프라인 연속성 보장. 【오답 체크】 A는 replication rule로 이미지 복제(선제적, cache 아님), upstream 중단 전 모든 이미지 복제 필요. B는 public ECR을 중간 계층으로 불필요. C는 public repository 생성으로 보안 위험(private only 선호). 【시험 포인트】 ECR resilience pattern: pull-through cache로 on-demand 캐싱 + basic scanning으로 vulnerability detection. Upstream 중단 시에도 로컬 캐시 활용 가능.

해설

【핵심 용어】 ▸ Single point of failure elimination — 단일 AZ, 단일 인스턴스 제거 ▸ Multi-AZ architecture — 여러 가용 영역에 분산 배포 ▸ Minimal configuration changes — 기존 EC2/MySQL 아키텍처 유지 【정답 포인트】 B는 최소 변경으로 고가용성 달성. EC2는 여러 AZ에 Auto Scaling으로 수평 확장, ALB로 로드 분산. MySQL은 Aurora Multi-AZ(기본 multi-AZ, 자동 페일오버, 읽기 복제본)로 관리형 전환. CloudFront로 엣지 캐싱. 애플리케이션 코드 변경 미미(connection string만 Aurora endpoint로 변경). 【오답 체크】 A는 Fargate + DynamoDB로 완전 리아키텍처(code rewrite 필요). C는 multi-region 배포로 RTO/RPO 목표 불명확. D는 Lambda(serverless)로 stateless 애플리케이션 아님(session management 복잡). 【시험 포인트】 Legacy monolith HA upgrade: EC2 multi-AZ + Auto Scaling → Aurora Multi-AZ(MySQL compatible) → CloudFront. 최소 코드 변경, 최대 가용성 향상.

해설

【핵심 용어】 ▸ CodeDeploy canary/blue-green — Lambda/ECS 배포 전략, zero-downtime ▸ Consistent deployment — Lambda와 ECS 통일 솔루션 ▸ Configuration management — SSM Parameter Store (lightweight) vs. Secrets Manager 【정답 포인트】 B는 CodeDeploy로 Lambda(canary) + ECS(blue/green) 배포를 통일 관리. Canary는 일부 트래픽만 새 버전 전환으로 위험 최소화, Blue/green은 2개 환경 전환으로 zero-downtime. CloudFormation 템플릿 작성 불필요(CodeDeploy appspec.yml로 충분). Parameter Store는 구성 데이터 관리에 경량, 개발 노력 최소. 【오답 체크】 A는 CloudFormation으로 모든 구성 요소 정의 필요(개발 노력 증가), 카나리/블루그린 전략 미흡. C는 Step Functions로 복잡 오케스트레이션(불필요), cross-region canary는 과도. D는 Systems Manager로 Lambda 배포 미지원(CodeDeploy보다 제한적). 【시험 포인트】 Multi-component microservice deployment: CodeDeploy native support → Lambda canary + ECS blue/green → zero-downtime guarantee. SSM Parameter Store로 구성 경량 관리.

해설

【핵심 용어】 ▸ CodeBuild test action — CI/CD 파이프라인에 테스트 단계 통합 ▸ Code coverage gate — buildspec에서 커버리지 임계값 검증 후 빌드 실패 ▸ Automated validation — 수동 승인 없이 자동 통과/실패 결정 【정답 포인트】 C는 CodeBuild의 표준 테스트 패턴. buildspec.yml에서 unit tests 실행 + coverage report 생성, 임계값 검증(if coverage < 80%, exit 1). CodePipeline test action이 빌드 실패를 감지하여 파이프라인 중단. 자동화, 신속, 운영 오버헤드 최소. 【오답 체크】 A는 Lambda + EventBridge 스케줄로 파이프라인과 비동기 분리, SLA 보장 안 됨. B는 Step Functions test action이 CodePipeline에 미지원. D는 Jenkins(외부 도구) 추가 복잡도, 승인 작업은 자동이 아님. 【시험 포인트】 CodePipeline quality gate: CodeBuild test action + buildspec reports/validation으로 coverage enforcement. Lambda/Step Functions/Jenkins는 과도한 설정.

해설

【핵심 용어】 ▸ CloudWatch metric filter — 로그 패턴 매칭으로 메트릭 생성, 별도 처리 불필요 ▸ Native CloudWatch — 추가 서비스 불필요, 비용/운영 최소 ▸ JSON log parsing — 메트릭 필터 문법으로 JSON 필드 추출 【정답 포인트】 C는 가장 간단하고 비용 효율적입니다. CloudWatch metric filter는 native 기능으로 "[timestamp, request_id, status=success]" 패턴으로 성공 거래만 필터링하여 메트릭 생성. CloudWatch 대시보드에서 메트릭 시각화. 추가 서비스(OpenSearch, Kinesis, Lambda) 불필요. 【오답 체크】 A는 OpenSearch cluster 유지 비용 및 구독 필터 설정 오버헤드. B는 Lambda 함수 작성/관리 필요(JSON parsing 코드). D는 Kinesis + Lambda로 가장 복잡, 비용 증가. 【시험 포인트】 CloudWatch metric filter은 JSON 로그에서 특정 필드(status=success) 추출 가능. Serverless 솔루션으로 OpenSearch 불필요한 경우 metric filter이 최적.