정답 · 해설

해설

【핵심 용어】 ▸ Origin Shield — CloudFront 캐시 앞의 추가 캐싱 계층 ▸ Global Edge Locations — 전 세계 엣지 로케이션 활용 ▸ Origin Failover — 원본 서버 장애 시 자동 전환 【정답 포인트】 ▸ Origin Shield + 적절한 TTL → 원본 부하 감소, 높은 캐시 히트율 ▸ 단일 배포 (us-east-1) → 운영 단순화, 관리 오버헤드 최소 ▸ Origin Failover → 크로스 리전 고가용성 (추가 복제본) ▸ 글로벌 엣지 로케이션 자동 활용 → 지역별 성능 최적화 【오답 체크】 (A) 다중 배포 + Route 53 → 관리 복잡도 증가, 라우팅 설정 필요 (C) ElastiCache 추가 → 불필요한 복잡도, CloudFront의 엣지 캐시로 충분 (D) eu-west-1 Origin Shield → 지역 편향, Global Accelerator는 CDN과 중복 【시험 포인트】 단일 CloudFront + Origin Shield = 최소 운영 오버헤드로 글로벌 성능 달성. CloudFront 자체가 글로벌 배포이므로 다중 배포 불필요합니다.

해설

【핵심 용어】 ▸ CloudWatch Logs — 중앙 집중식 로그 저장 ▸ Logs Insights — 로그 쿼리 및 분석 도구 ▸ CodeDeploy 에이전트 로그 — /var/log/codedeploy-agent/codedeploy-agent.log 【정답 포인트】 ▸ CloudWatch Logs 수집 → 모든 인스턴스의 로그 중앙화 ▸ Logs Insights → SQL 유사 쿼리로 다중 인스턴스 로그 동시 분석 ▸ 자동화 가능 → 향후 모니터링 지속 가능 ▸ 운영 효율성 → SSH/Session Manager보다 확장성 높음 【오답 체크】 (A) SSH → 보안 위험, 수동 작업, 확장성 낮음 (B) Session Manager → (A) 보다 나음(보안 로깅) 하지만 여전히 수동 조회 (C) S3+Athena → 추가 구성 필요, 실시간 분석 어려움, appspec.yml 수정 필요 【시험 포인트】 CodeDeploy 배포 문제 해결 = CloudWatch Logs Insights. 다중 인스턴스 로그 통합 분석이 필수입니다.

해설

【핵심 용어】 ▸ GuardDuty — AI 기반 위협 탐지(배포 후 실행 중 탐지) ▸ Lambda Protection — Lambda 함수의 의심 행동 탐지 ▸ EventBridge — GuardDuty 발견 사항 자동 알림 【정답 포인트】 ▸ GuardDuty Lambda Protection → 배포된 함수의 런타임 악의적 활동 탐지 ▸ 공급망 공격 감지 → 배포 후 침입 탐지(IDS), CI/CD가 놓친 공격 포착 ▸ EventBridge 연동 → 자동 알림 및 대응 ▸ 서버리스 환경 최적화 → Lambda, API Gateway 모두 감시 【오답 체크】 (A) WAF → 네트워크 공격만 탐지, 런타임 악의적 행동 탐지 불가 (C) CloudFormation Guard → 배포 전 정책 검증(IaC), 런타임 공격 탐지 불가 (D) Network Firewall → 네트워크 계층, 서버리스 환경(Lambda)에 적용 불가 【시험 포인트】 공급망 공격 = CI/CD 우회 후 배포된 코드의 악의적 활동. GuardDuty Lambda Protection이 유일한 런타임 탐지 수단입니다.

해설

【핵심 용어】 ▸ ALB 가중치 기반 라우팅 — 같은 ALB의 리스너 규칙에서 대상 그룹별 가중치 설정 ▸ 트래픽 분할 — 10% 베타, 90% 정상 버전 【정답 포인트】 ▸ 단일 ALB 유지 → Route 53 변경 없음, 구성 변경 최소 ▸ ALB 리스너 규칙의 가중치 → 간단한 트래픽 분할 ▸ EC2+대상 그룹 그대로 → 기존 인프라 활용 ▸ 최소 오버헤드 → Route 53 가중치 라우팅보다 단순 【오답 체크】 (A) 새 ALB + Route 53 가중치 라우팅 → 구성 변경 많음(새 ALB, Route 53 수정) (C) 애플리케이션 리팩토링 → 개발 오버헤드 큼, AppConfig 도입 복잡 (D) ECS+CodeDeploy → EC2에서 ECS로 전환 필요, 큰 변경 【시험 포인트】 ALB = Layer 7 로드밸런싱으로 리스너 규칙에서 직접 가중치 설정 가능. Route 53과 혼동하지 않기. "최소 구성 변경" 핵심은 ALB의 리스너 규칙 활용입니다.

해설

【핵심 용어】 ▸ ECR Lifecycle Policy — ECR 고유의 자동 정리 정책 ▸ Image Age & Image Count — 나이 또는 개수 기반 필터링 【정답 포인트】 ▸ ECR 네이티브 기능 → 별도 도구 없음, 최소 오버헤드 ▸ 자동 실행 → Lambda 스케줄링 필요 없음 ▸ 태그 여부 관계없이 관리 → 태그되지 않은 이미지도 정책 적용 가능 ▸ "최소 지정 개수 유지" → 이미지 개수 기반 필터 (imageCountMoreThan) 【오답 체크】 (A) S3 라이프사이클 → ECR은 S3 기반 아님, 잘못된 서비스 (C) Lambda 함수 → 추가 개발/스케줄링 필요, 오버헤드 증가 (D) Systems Manager → 추가 스크립트 작성, 정기 실행 설정 필요 【시험 포인트】 ECR = ECR Lifecycle Policy. 이 서비스의 네이티브 기능을 모르면 복잡한 솔루션을 선택하게 됩니다. imageCountMoreThan, imageSinceImagePushedDays 등 필터 이해 필요합니다.

해설

【핵심 용어】 ▸ CloudWatch Agent — EC2에서 커스텀 메트릭 수집 ▸ Instrumentation — 애플리케이션이 에이전트로 메트릭 전송 ▸ PutMetricData — CloudWatch API 【정답 포인트】 ▸ CloudWatch Agent 에이전트 → 정해진 표준 방식 ▸ 최소 오버헤드 → 에이전트 설치+구성만 필요 ▸ 확장성 → 다중 인스턴스에 에이전트 배포 시 중앙화 된 모니터링 ▸ API 응답 시간, DB 쿼리 지연 → 애플리케이션이 직접 전송 가능 【오답 체크】 (B) Prometheus → 쿠버네티스/컨테이너 중심, EC2 단순 배포에 오버 엔지니어링 (C) Lambda 폴링 → 외부에서 능동적 폴링, 애플리케이션 내부 메트릭 수집 불가 (D) Logs Insights → 로그 기반 분석, 실시간 메트릭 아님, 성능 지연 【시험 포인트】 EC2 + 커스텀 메트릭 = CloudWatch Agent. PutMetricData API는 일반적 메커니즘이지만, 에이전트가 가장 효율적인 방식입니다.

해설

【핵심 용어】 ▸ CloudFormation IaC Generator — AWS 콘솔의 기능으로 수동 생성된 리소스를 자동으로 CDK/CFN 코드로 변환 ▸ 부분 스캔 — 특정 리소스 유형만 선택적으로 스캔하여 빠른 처리 가능 ▸ from_asset — AWS CDK에서 로컬 파일 시스템의 람다 핸들러 코드를 참조하는 파라미터 【정답 포인트】 ▸ 직접 CDK 생성 — CloudFormation IaC Generator는 CDK 애플리케이션을 직접 생성 가능 ▸ Lambda 필터링 — 불필요한 스캔을 건너뛰고 필요한 리소스만 자동화 ▸ from_asset 설정 — 핸들러 코드를 코드로 관리하여 인프라 간 일관성 확보 ▸ 최소 구현 노력 — 자동 생성 후 핸들러 코드만 조정, 수동 작업 최소화 【오답 체크】 (A) 정답 — CloudFormation IaC Generator는 직접 CDK를 생성하므로 가장 효율적 (B) CFN 템플릿 중간 단계 — 추가 변환 작업 필요, ZipFile은 인라인 코드 용도로 부적합 (C) Code/ImageUri — 컨테이너 이미지 기반 람다인데 현재는 일반 ZIP 함수, 불필요한 변경 (D) AWS Config + 수동 작성 — CSV 기반으로 CDK를 완전히 수동 작성해야 하므로 오버헤드 극대 【시험 포인트】 CloudFormation IaC Generator의 핵심은 직접 CDK 애플리케이션을 생성한다는 점. CFN 템플릿은 중간 단계이며 추가 변환이 필요하므로 최소 노력 요구사항과 맞지 않습니다. Lambda 리소스 필터링은 대규모 환경에서 스캔 시간을 단축하는 실무 포인트.

해설

【핵심 용어】 ▸ aws eks update-cluster-version — AWS CLI를 사용한 EKS 클러스터 버전 업그레이드 명령 ▸ AWS 표준 지원 일정 — AWS가 권장하는 Kubernetes 버전 업그레이드 시기 및 지원 기간 ▸ 관리형 노드 그룹 — EC2 인스턴스 자동 관리 기능으로 운영 복잡도 감소 【정답 포인트】 ▸ CLI 명령 직접 실행 — 즉시 실행 가능하며 파이프라인 구축 불필요 ▸ 표준 일정 준수 — DevOps 엔지니어가 수동으로 AWS 권장 일정 확인 후 업그레이드 실행 ▸ 최소 운영 오버헤드 — 단순 CLI 명령으로 관리, 자동화 도구 없이도 충분 ▸ 기존 구성 유지 — 관리형 노드 그룹 유지로 인프라 변경 최소화 【오답 체크】 (A) 정답 — 수동 CLI 명령은 표준 일정 준수와 최소 오버헤드를 동시에 충족 (B) EKS Auto Mode 활성화 — 기존 관리형 노드 그룹 제거 필요로 대규모 변경 야기 (C) eksctl 도구 사용 — 별도 오픈소스 도구로 AWS 표준 방식 아님, 추가 학습 비용 (D) IaC 리팩토링 — 기존 수동 배포를 코드화로 완전히 전환, 운영 오버헤드 크게 증가 【시험 포인트】 "지속적으로 업그레이드" + "최소 오버헤드" = 자동화 아닌 정기적 수동 관리. 문제에서 "자동으로"라는 표현이 없으므로 수동 실행이 정답. EKS Auto Mode와 같은 신기술보다 현실적인 관리 방식을 선택하는 것이 핵심.

해설

【핵심 용어】 ▸ CodePipeline 스테이지 — 파이프라인 내 순차 실행 단계로 S3 배포 등 작업 추가 가능 ▸ EventBridge 스케줄 규칙 — cron 형식으로 정기적 트리거 설정, 일일 빌드 자동화 ▸ 빌드 아티팩트 — CodeBuild에서 생성된 컴파일/패키징 결과물을 S3에 저장 【정답 포인트】 ▸ 기존 파이프라인 활용 — 새로운 CodeBuild 프로젝트 생성 불필요, 기존 리소스 확장 ▸ EventBridge 스케줄 — 일일 정기 빌드 요구사항을 자동으로 충족 ▸ S3 배포 스테이지 추가 — 파이프라인 내 단일 스테이지로 아티팩트 배포 ▸ 공개 웹사이트 연동 — S3 버킷의 결과물을 직접 공개 가능하게 배포 ▸ 최소 운영 오버헤드 — 스케줄 설정 후 자동 실행, 추가 모니터링 불필요 【오답 체크】 (A) CodeBuild + 웹훅 — 코드 푸시 기반 실시간 빌드로 일일 정기 빌드 요구사항 불일치, 새 프로젝트 생성 (B) CodeBuild + EventBridge — 올바른 스케줄 개념이나 기존 파이프라인 미활용, CodeBuild 신규 생성으로 중복 (C) PR 기반 트리거 — 풀 요청 발생 시에만 실행으로 일일 정기 빌드 불가능 (D) 정답 — 기존 파이프라인 유지하며 S3 스테이지 추가, EventBridge로 일일 스케줄 자동화 【시험 포인트】 문제의 핵심은 "매일" + "기존 파이프라인 수동 호출" 중심에서 자동화로 전환. 불필요한 신규 리소스 생성보다 기존 파이프라인에 S3 배포 스테이지 추가가 효율적. EventBridge는 CodePipeline의 표준 스케줄 트리거 방식으로, 정기적 CI/CD 요구사항의 필수 패턴입니다.