정답 · 해설

해설

【핵심 용어】 ▸ EventBridge — 이벤트 기반 아키텍처, CodePipeline 상태 변경 감지 ▸ SNS — 메시지 브로드캐스트, 여러 구독자 지원 ▸ Lambda + Webhook — HTTP 호출을 통한 외부 시스템 통합 【정답 포인트】 ▸ EventBridge 규칙: CodePipeline 상태 변경 자동 감지 (선언적, 실시간) ▸ SNS 주제: 중앙 집중식 메시지 버스, 확장 가능 ▸ Lambda 함수: 이벤트 → Webhook 포맷 변환 → 채팅 도구로 전송 ▸ 아키텍처 분리: 파이프라인 코드 수정 없음 (D의 문제점) 【오답 체크】 (A) CloudWatch Logs: SNS 직접 구독 미지원, 트리거 방식 부적절 (B) CloudTrail: 비용 높음, API 호출 기록용, 상태 변경 감지 느림 (D) 파이프라인 코드 수정: 애플리케이션 로직 혼재, 관리 어려움 【시험 포인트】 실시간 이벤트 알림 → EventBridge + SNS + Lambda 조합. 파이프라인 외부의 깨끗한 이벤트 아키텍처

해설

【핵심 용어】 ▸ AWS Config — 리소스 구성 준수 상태 지속 모니터링 ▸ 관리형 규칙(managed rule) — AWS가 제공하는 사전 정의 규칙 ▸ restricted-ssh — 0.0.0.0/0에서 SSH 차단 여부 검사 ▸ 자동 수정 — 비준수 상태 감지 시 자동 알림/조치 【정답 포인트】 ▸ Config restricted-ssh 규칙: 보안 그룹의 지속적 준수 모니터링 ▸ 0.0.0.0/0 SSH 허용 = 자동으로 NON_COMPLIANT 표시 ▸ 자동 수정 액션으로 SNS 알림: 규정 위반 감지 시 즉시 보안팀 통보 ▸ 클라우드트레일보다 지속적: CloudTrail은 API 호출 기록일 뿐, 상태 추적 아님 【오답 체크】 (A) EventBridge + CloudTrail: API 이벤트만 감지, 이미 위반된 규칙 탐지 불가, 사후 대응 (B) GuardDuty: 위협 탐지 도구, 설정 준수 검사 도구 아님 (D) Inspector: EC2 인스턴스 취약점 스캔, 보안 그룹 규칙 감시 아님 【시험 포인트】 "자동 모니터링 + 규정 위반 감시" → AWS Config 관리형 규칙. 지속적 준수 상태 추적이 핵심

해설

【핵심 용어】 ▸ 지연시간 분석 — 응답 시간이 높은 이유 파악 ▸ X-Ray 추적 — 요청/응답 흐름의 세밀한 분석 ▸ CloudWatch 에이전트 — OS/애플리케이션 수준의 로그 및 메트릭 수집 ▸ 오버헤드 최소화 — 성능 영향 없이 데이터 수집 【정답 포인트】 ▸ (A) CloudWatch 에이전트: 온프레미스 서버의 CPU, 메모리, 디스크, 네트워크 메트릭 수집 (비동기, 오버헤드 최소) ▸ (C) X-Ray + 데몬: API Gateway → 온프레미스 애플리케이션 간 요청 추적 (비동기 데몬 사용으로 성능 영향 최소) ▸ 두 조합: 인프라 메트릭 (A) + 요청 경로 추적 (C) = 지연시간 원인 특정 가능 【오답 체크】 (B) X-Ray 동기 업로드: 요청 처리 중 직접 업로드 → 추가 지연 발생 (D) 애플리케이션 로그 반환: 각 요청마다 추가 왕복 → 오버헤드 증가 (E) 통계만 업로드: 개별 요청 추적 불가, 문제 원인 파악 어려움 【시험 포인트】 "추가 지연 없이" → 비동기 수집 방식(에이전트, 데몬) 선택. 동기 API 호출 (B) 제외

해설

【핵심 용어】 ▸ Parameter Store — 구성 데이터의 중앙 집중식 저장소, 동적 업데이트 지원 ▸ EventBridge — Aurora 장애 이벤트 자동 감지 ▸ RDS 프로모션 자동화 — 읽기 복제본 → 독립 DB 승격 ▸ 클라이언트 재연결 — 애플리케이션이 새 엔드포인트 감지 후 재접속 【정답 포인트】 ▸ EventBridge: RDS 장애 이벤트 실시간 감지 (aws.rds events) ▸ Lambda: 복제본 승격 + Parameter Store 엔드포인트 URL 업데이트 ▸ 애플리케이션: 연결 실패 시 Parameter Store에서 새 엔드포인트 재로드 ▸ 자동화 완성: 감지 → 승격 → 엔드포인트 변경 → 클라이언트 재접속 (모두 자동) ▸ 가장 깨끗한 아키텍처: 애플리케이션과 DB 계층 분리 【오답 체크】 (A) Route 53 지연시간 라우팅: 두 엔드포인트 모두 활성 필요, 읽기 복제본은 쓰기 불가 (B) CloudTrail + 람다: CloudTrail은 API 호출 기록, 실시간 이벤트 아님 (지연 발생) (C) CloudFormation 스택 수정: 인프라 재배포 필요 (시간 소요), 자동화 약함 【시험 포인트】 DR 자동 장애 조치 → EventBridge 이벤트 감지 + Parameter Store 동적 업데이트. 엔드포인트 재설정이 핵심

해설

【핵심 용어】 ▸ StatusCheckFailed System — 호스트 하드웨어 문제 (EC2 플랫폼 자체의 장애) ▸ StatusCheckFailed Instance — 게스트 OS/애플리케이션 문제 (인스턴스 내부 문제) ▸ EC2 복구(Recover) — System Check 실패 시 인스턴스를 다른 호스트로 재배치 ▸ 최소 데이터 손실 — EBS 볼륨 유지 (인스턴스 재배치만, 재시작 아님) 【정답 포인트】 ▸ 네트워크/전원 장애 = 호스트 수준 문제 = StatusCheckFailed System ▸ CloudWatch 알람 → EC2 복구 액션: 인스턴스가 다른 물리 호스트로 이동 ▸ EBS 볼륨 유지: 호스트 변경이지만 저장소는 그대로 (데이터 손실 없음) ▸ 빠른 복구: 재부팅보다 빠른 호스트 재배치 【오답 체크】 (A) Auto Scaling(용량=1): 복구 아님, 새로운 인스턴스 생성 (데이터 손실 가능) (B) 라이프사이클 훅: EBS 분리는 데이터 보존이지만 스테이징용으로 필수 아님 (D) StatusCheckFailed Instance + 재부팅: 인스턴스 문제용, 호스트 장애는 감지 불가 【시험 포인트】 호스트 장애(System Check) vs 인스턴스 문제(Instance Check). 최소 지연 + 데이터 보존 = EC2 복구(Recover) 액션

해설

【핵심 용어】 ▸ CodePipeline — CI/CD 워크플로우 오케스트레이션 ▸ CodeBuild — 빌드 및 테스트 실행 ▸ CodeDeploy — appspec.yml 기반 배포 자동화 ▸ 배포 그룹 — EC2 인스턴스 대상의 명시적 관리 ▸ appspec.yml — 배포 스크립트 및 파일 권한 정의 【정답 포인트】 ▸ CodePipeline: CodeBuild(단위 테스트) → CodeDeploy(배포 수행) ▸ CodeBuild: 커밋된 코드 테스트 실행 ▸ CodeDeploy 배포 그룹: 인스턴스 등록/등록 해제 자동 관리 ▸ appspec.yml: hooks(BeforeInstall, ApplicationStart 등)로 서비스 관리, 파일 권한 설정 ▸ bash 스크립트: appspec.yml 내에서만 호출 (필요한 부분만, 가능하면 최소화) 【오답 체크】 (A) CodeBuild만 테스트: 배포 조율 부재 (B) CodeDeploy로 테스트: CodeDeploy는 배포 도구, 테스트 도구 아님 (C) CodeBuild로 ALB 관리: CodeBuild는 빌드 환경, ALB 로드 밸런싱 제어 불가 【시험 포인트】 기존 bash 스크립트 → AWS 도구로 마이그레이션. CodePipeline(조율) + CodeBuild(테스트) + CodeDeploy(배포 + appspec.yml)

해설

【핵심 용어】 ▸ Systems Manager Hybrid Activations — 온프레미스 서버를 Systems Manager에 등록 ▸ IAM 역할 — EC2가 Systems Manager 호출 권한 획득 ▸ Maintenance Windows — 정기적 시간 윈도우 설정 ("업무 시간 외" 구현) ▸ 패치 표준화 — EC2 + 온프레미스 모두 같은 Systems Manager 정책 적용 【정답 포인트】 ▸ (A) Hybrid Activations: 온프레미스 서버 Systems Manager 관리 가능 ▸ (B) EC2 IAM 역할: EC2가 Systems Manager API 호출 권한 (보안: 액세스 키 불필요) ▸ (F) Maintenance Windows: "업무 시간 외"라는 시간 기반 정책 구현 (cron expression 활용) ▸ 세 조합: EC2/온프레미스 모두 Systems Manager 통합 + 정시간 예약 패칭 가능 【오답 체크】 (C) IAM 액세스 키: 보안 위험 (키 노출 → 권한 도용), Hybrid Activations로 충분 (D) Automation 매시간: "업무 시간 외"라는 정책 미반영, 지속적 실행은 비경제적 (E) EventBridge 예약: 시간 예약 가능하나, Systems Manager Maintenance Windows가 패칭 전용 【시험 포인트】 하이브리드 패칭 + 정책 준수 시간 → Hybrid Activations(EC2) + IAM 역할(권한) + Maintenance Windows(시간 정책)

해설

【핵심 용어】 ▸ Customizations for AWS Control Tower (CfCT) — Control Tower 통합 자동화 솔루션 ▸ CodeCommit 저장소 — 템플릿/SCP 코드 버전 관리 ▸ 사용자 정의 패키지 — OU/계정별 맞춤형 배포 설정 ▸ CreateManagedAccount 이벤트 — Control Tower Account Factory 생성 감지 【정답 포인트】 ▸ CfCT: Control Tower와 깊게 통합되어 새 계정 생성 자동 감지 (Account Factory) ▸ CodeCommit: 템플릿과 SCP를 IaC로 관리, 버전 추적 가능 ▸ 자동 배포: 사용자가 계정 생성 → CfCT가 자동으로 CloudFormation + SCP 적용 ▸ OU/계정별 커스터마이징: 패키지 구조로 세분화된 배포 정책 지원 ▸ "가장 자동화된 방식" = 사용자 개입 최소, 선언적 IaC 【오답 체크】 (A) Service Catalog: 사용자가 수동으로 제품 선택 필요 (반자동) (B) StackSets: Account Factory와 통합 없음, 수동 트리거 필요 (C) EventBridge + Service Catalog: EventBridge는 EventBridge 대상 지원, 자동화 부족 【시험 포인트】 Control Tower 완전 자동화 → CfCT 솔루션. Account Factory와 네이티브 통합이 필수

해설

【핵심 용어】 ▸ 읽기 전용 복제본(Read Replica) — 주 DB에서 비동기 복제, 읽기 부하 분산 ▸ 로컬 DB 인스턴스 — 각 리전의 독립적 쓰기/읽기 가능한 DB ▸ 글로벌 테이블(Global Table) — 다중 리전 활성-활성(active-active) 쓰기 ▸ 규정 준수 — 데이터 지역성 (데이터가 해당 리전에만 존재) 【정답 포인트】 ▸ 제품 카탈로그: Aurora 읽기 복제본 → 모든 리전에서 읽기만 수행, 중앙 갱신 ▸ 고객 데이터: 각 리전의 로컬 Aurora 인스턴스 → 지역별 독립 저장, 규정 준수 보장 ▸ 최소 애플리케이션 변경: 읽기 복제본은 기존 Aurora 쿼리와 호환, 엔드포인트만 변경 ▸ Redshift 불필요: OLTP 워크로드에는 Aurora가 적합 【오답 체크】 (A) Redshift: 분석 DB, OLTP 트랜잭션에 부적합, 마이그레이션 대비 변경 (B) DynamoDB 글로벌 + 지역별: 고객 데이터도 글로벌 테이블 → 규정 준수 위반 (데이터 복제) (D) Aurora + DynamoDB 글로벌: 카탈로그와 고객 데이터의 기술 스택 혼합 (일관성 문제) 【시험 포인트】 다중 리전 + "규정 준수 지역성" → 읽기 복제본(공유) + 로컬 인스턴스(격리). DynamoDB 글로벌은 규정 준수에 부적합

해설

【핵심 용어】 ▸ 지연시간 기반 라우팅(Latency-based routing) — Route 53이 사용자 위치별 최적 리전 자동 선택 ▸ DynamoDB 글로벌 테이블 — 다중 리전 활성-활성(active-active) 쓰기 가능 ▸ 고가용성 + 지연시간 최소화 — 로컬 리전에서 처리 ▸ 상태 검사(Health checks) — 엔드포인트 장애 감지 【정답 포인트】 ▸ Route 53 지연시간 라우팅: 북미 사용자 → 북미 API, 유럽 사용자 → 유럽 API (최소 지연) ▸ 각 리전의 API Gateway + Lambda: 로컬 처리로 응답 시간 단축 ▸ DynamoDB 글로벌 테이블: 모든 리전에서 데이터 쓰기 가능, 자동 동기화 (안정성 보장) ▸ 상태 검사: 장애 자동 감지, 사용자를 정상 엔드포인트로 자동 전환 【오답 체크】 (A) 상태 검사만: 지연시간 최적화 부족 (모든 사용자가 같은 엔드포인트 가능) (C) 단일 North America + 재해 복구: 유럽 사용자는 고지연 (지연시간 최소화 실패) (D) Lambda → "가장 가까운 리전": API Gateway에서 불가능, Route 53이 해야 하는 작업 【시험 포인트】 글로벌 안정성 + 지연시간 → 지연시간 기반 라우팅(Route 53) + 글로벌 데이터베이스(DynamoDB 글로벌 테이블)

해설

【핵심 용어】 ▸ 중첩 스택(Nested Stack) — 재사용 가능한 공통 구성 요소 모듈화 ▸ Fn::ImportValue — CloudFormation Stack Outputs 참조 (cross-stack 통합) ▸ ChangeSet — 스택 변경 사항 검토 후 적용 (안전한 업데이트) ▸ 템플릿 계층화 — 루트 스택 + 중첩 스택으로 복잡성 관리 【정답 포인트】 ▸ 중첩 스택: ALB, Auto Scaling, 보안 그룹, DynamoDB 등 공통 컴포넌트 재사용 ▸ Fn::ImportValue (Resources에서): 네트워킹 팀의 VPC/서브넷 스택 Outputs 참조 ▸ ChangeSet/ExecuteChangeSet: 업데이트 시 변경 사항 미리 검토 → 안전한 배포 ▸ 확장성: 새 개발 환경 = 루트 스택만 생성 (중첩 스택 재사용) 【오답 체크】 (A) StackSets: 여러 계정/리전 배포용, 단일 계정의 동일 리전 환경은 부적합. Count 파라미터 미지원 (B) Parameters에서 ImportValue: 파라미터는 정적 입력용, Outputs 참조는 Resources에서만 가능 (D) Parameters에서 ImportValue: 같은 이유로 부적절 (B와 중복) 【시험 포인트】 재사용 가능한 템플릿 + 안전한 업데이트 → 중첩 스택 + ChangeSet. Fn::ImportValue는 Resources 섹션에서만 사용

해설

【핵심 용어】 ▸ AWS Config 조직 규칙 — 조직의 모든 계정에 적용되는 관리형 규칙 ▸ 관리형 규칙(Managed Rules) — AWS가 제공하는 사전 정의된 준수 검사 ▸ 지속적 모니터링 — 규칙이 계속 실행되어 비준수 검사 ▸ SCP — 정책 실행 방지 (AWS Config 변조 방지) 【정답 포인트】 ▸ Config 조직 규칙: 새 계정 추가 시 자동으로 규칙 배포 (계정 생성 스크립트 불필요) ▸ 관리형 규칙: AWS가 유지보수 (템플릿 관리 부담 없음) ▸ 지속적 감시: 항상 존재 (CloudFormation 템플릿과 달리 의존성 없음) ▸ SCP로 보호: AWS Config 우회 불가 (정책 강제) 【오답 체크】 (A) CloudFormation 템플릿: 계정 생성 스크립트에 의존, 수동 업데이트 필요, 확장성 낮음 (C) SCP 정책: 미래 인스턴스만 차단, 이미 존재하는 암호화 안 된 볼륨은 감지 불가 (D) CodePipeline + Lambda: 보고서만 생성, 준수 상태 강제(remediation) 불가, 반복적 수동 검사 【시험 포인트】 조직 전체 지속적 준수 검사 → AWS Config 조직 규칙. 자동 배포 + 자동 감시

해설

【핵심 용어】 ▸ Amazon Inspector — EC2 인스턴스 취약점 스캔 (Systems Manager Agent 필요) ▸ Systems Manager Agent — EC2가 Systems Manager와 통신하는 필수 컴포넌트 ▸ 인스턴스 프로필(Instance Profile) — EC2가 AWS 서비스 권한 획득 ▸ 아웃바운드 통신 — 포트 443, Systems Manager 엔드포인트 【정답 포인트】 ▸ (A) SSM Agent 설치/실행: Inspector는 Agent를 통해 인스턴스 스캔 (Agent 없으면 스캔 불가) ▸ (B) 아웃바운드 포트 443: Agent가 Systems Manager 엔드포인트와 통신하는 네트워크 경로 확보 ▸ (E) 인스턴스 프로필: EC2가 Systems Manager API 호출 권한 획득 ▸ 세 조합: 필수 구성 요소 → Agent (A) + 네트워크 (B) + IAM 권한 (E) 【오답 체크】 (C) inspector:StartAssessmentRun: Inspector 스캔 시작 권한, "스캔 안 함" 해결 불가 (이미 활성화됨) (D) EC2 Instance Connect: SSH 접근용, Inspector 스캔과 무관 (F) 관리형 인스턴스 활성화: 온프레미스 서버용, EC2는 IAM 역할로 충분 【시험 포인트】 "스캔 안 함" → Systems Manager Agent + 네트워크 + IAM 권한의 세 가지 요소 검증. 온프레미스와 EC2의 차이

해설

【핵심 용어】 ▸ pullRequestCreated — 풀 요청이 새로 생성되었을 때 ▸ pullRequestSourceBranchUpdated — 소스 브랜치가 업데이트되었을 때 (새 커밋 푸시) ▸ 코드 리뷰 중 배지 표시 — 개발자들이 즉시 테스트 상태 확인 가능 ▸ 자동 테스트 트리거 — PR 생성/업데이트 시 자동으로 테스트 시작 【정답 포인트】 ▸ pullRequestCreated: PR 처음 생성 시 테스트 자동 시작 ▸ pullRequestSourceBranchUpdated: PR 수정 후 새 커밋 푸시 시 테스트 재실행 ▸ 배지 게시: CodeBuild 상태(성공/실패)를 시각적으로 표시 (리뷰 편의성) ▸ 두 이벤트 필요: 초기 PR과 이후 수정 모두 테스트 【오답 체크】 (A) pullRequestStatusChanged: PR 상태 변경 후 발동 (테스트 결과 완료 후), 초기 생성 시 미발동 (B) pullRequestCreated만: 수정된 커밋(브랜치 업데이트)에 대해 테스트 안 함 (D) pullRequestStatusChanged + 테스트 결과: 상태 변경 이벤트는 부적절 (변경 후 발동) 【시험 포인트】 PR 자동 테스트 → 생성(created) + 수정(SourceBranchUpdated) 두 이벤트. 배지(빠른 시각화) vs 전체 결과(상세 정보)

해설

【핵심 용어】 ▸ "거의 실시간" → 지연시간 최소화 ▸ "가장 비용 효과적" → CloudWatch 기반 (S3, Athena, OpenSearch보다 저비용) ▸ VPC 흐름 로그 → 수락된 트래픽만 분석 (거부 목록 탐지) ▸ 메트릭 필터 → 특정 IP 패턴 추출 ▸ CloudWatch 알람 → 실시간 감지 및 SNS 알림 【정답 포인트】 ▸ CloudWatch Logs: VPC 흐름 로그 스트림 (실시간) ▸ 메트릭 필터: 거부 목록 IP 주소 추출 (정규식) ▸ CloudWatch 알람: 5분 간격, 데이터 포인트=1 (거의 실시간) ▸ SNS 주제: 보안팀 즉각 통보 ▸ 저비용: CloudWatch는 기본 로깅 비용만 (분석 도구 추가 비용 없음) 【오답 체크】 (B) S3 + Athena + QuickSight: 대시보드 구성이 복잡, 비용 높음, "거의 실시간" 불가 (정기적 Athena 쿼리) (C) OpenSearch: 설정 복잡, Lambda 매 5분 실행 = 지연 가능성, 비용 높음 (D) Athena CloudWatch 커넥터: 정기적 쿼리 (지연 발생), S3 객체 생성 후 알림 (거의 실시간 아님) 【시험 포인트】 실시간 + 저비용 → CloudWatch Logs + 메트릭 필터 + 알람. Athena는 배치 분석용, 실시간 부적절

해설

【핵심 용어】 ▸ 수동 승인(Manual Approval) — CodePipeline의 네이티브 액션 (사람 개입) ▸ Lambda 통합 — 외부 도구와의 자동 통신 ▸ REST API 호출 — HTTP 방식의 침투 테스트 도구 트리거 ▸ 아티팩트 검사 — QA가 배포 전 코드 검증 【정답 포인트】 ▸ (A) 수동 승인 액션: 스테이징 배포 후, 프로덕션 배포 전에 삽입 (QA 검사 대기) ▸ (E) Lambda 함수: REST API 호출로 침투 테스트 자동 시작 (QA 도구 트리거) ▸ 워크플로우: 스테이징 배포 → 수동 승인 (A) → Lambda (E) 로 테스트 실행 → 프로덕션 배포 ▸ QA 팀 경험: 승인 시 자동으로 테스트 도구 실행 (수동 API 호출 필요 없음) 【오답 체크】 (B) buildspec.yml에서 수동 승인: CodeBuild는 배포 도구 아님, 수동 승인 지원 불가 (C) CodeDeploy에서 수동 승인: 배포 그룹 자체에 승인 메커니즘 없음 (D) 파이프라인이 직접 API 호출: CodePipeline은 HTTP 호출 지원 안 함 (Lambda 필요) 【시험 포인트】 CodePipeline의 "수동 승인" 액션 + "Lambda 호출"로 외부 도구 트리거. 두 조합으로 QA 검사 프로세스 완성

해설

【핵심 용어】 ▸ 가중치 라우팅(Weighted Routing) — Route 53이 가중치에 따라 트래픽 분배 (주: 99%, 보조: 1%) ▸ DynamoDB 글로벌 테이블 — 거의 실시간 다중 리전 복제 (세션 데이터) ▸ 상태 검사(Health Checks) — 주 리전 장애 감지 시 자동 장애 조치 ▸ Elastic Beanstalk — 자동 확장 가능한 관리형 플랫폼 【정답 포인트】 ▸ 가중치 라우팅(99/1): 주 리전 99%, 보조 리전 1% (정상 상태에서 1% 모니터링) ▸ 상태 검사: 주 리전 장애 감지 → 가중치 자동 변경 (100% → 보조로 전환) ▸ DynamoDB 글로벌 테이블: 거의 실시간 세션 복제 (RPO 최소화) ▸ Elastic Beanstalk: 자동 수평 확장 (보조 리전 트래픽 급증 시 대응) 【오답 체크】 (B) Route 53 장애 조치: 1% 모니터링 불가 (주/보조만 선택, 혼합 라우팅 불가) (C) Lambda + RDS: RDS 교차 리전 복제는 동기, 비용 높음. Lambda는 성능 이유로 Elastic Beanstalk보다 적절하지 않음 (D) CloudFront 적용: 불필요 (리전 간 라우팅이 목표, CDN 캐싱 불필요) 【시험 포인트】 주/보조 분배(99/1) + 자동 장애 조치 → 가중치 라우팅(Weighted) 사용. 장애 조치(Failover)는 자동 전환만 (혼합 불가)

해설

【핵심 용어】 ▸ CodeDeploy — EC2 인스턴스에 애플리케이션 배포 자동화 ▸ CloudFormation Change Sets — 스택 변경 전 검토 가능 ▸ CodePipeline — CI/CD 파이프라인 자동화 【정답 포인트】 ▸ A 선택: CodeDeploy의 기본 구성요소(애플리케이션, 배포 그룹)와 에이전트 설치가 필수 ▸ D 선택: Change Sets는 CloudFormation 변경을 안전하게 검토하고 수동 승인 후 실행할 수 있게 함 ▸ 조합: CodePipeline(자동화) → CodeBuild(빌드) → Change Sets(검토) → 수동승인 → CodeDeploy(배포) 【오답 체크】 (B) "애플리케이션 리비전"은 CodeDeploy 용어가 아니며, "환경"도 정확한 개념이 아님 (C) CloudFormation 직접 업데이트는 Change Sets를 활용하지 않아 검토 절차가 부족 (E) D와 유사하지만 CloudFormation 변경 세트를 실행하는 단계가 누락됨 【시험 포인트】 ▸ CodeDeploy 배포 그룹: 대상 EC2 인스턴스 관리 ▸ Change Sets의 역할: 스택 변경을 시각화하고 안전성 확보 ▸ DOP 시험의 CI/CD 파이프라인: 자동화와 수동 승인의 균형

해설

【핵심 용어】 ▸ Blue/Green 배포 — 원본(Blue)과 신규(Green) 환경을 병행 운영 후 전환 ▸ CodeDeploy — EC2 인스턴스 배포 자동화 ▸ Termination 정책 — 구환경 자동 정리 시간 설정 【정답 포인트】 ▸ C가 정답: CodeDeploy Blue/Green은 원본 플릿을 유지하면서 신규 플릿 배포 가능 ▸ "Terminate the original instances in the deployment group with a waiting period of 1 hour" 옵션이 요구사항의 모든 조건 충족 ▸ CodeDeploy는 자동으로 트래픽 전환과 종료 시간 관리 【오답 체크】 (A) CloudFormation retention policy는 인스턴스 자동 종료를 제어할 수 없음 (B) Elastic Beanstalk의 애플리케이션 버전 정책은 환경 종료를 자동화하지 못함 (D) Immutable 배포는 새 인스턴스 생성 후 전환하지만 원본 명시적 종료는 불가 【시험 포인트】 ▸ CodeDeploy Blue/Green: 정확한 타이밍 제어와 자동 종료 ▸ DOP 특화: 배포 전략의 세부 구현 및 타이밍 관리 ▸ "waiting period" 옵션이 핵심 키워드

해설

【핵심 용어】 ▸ S3 Server Access Logging — S3 접근 기록 자동 수집 ▸ Amazon Athena — S3 데이터에 대한 SQL 직접 실행(서버리스) ▸ 최소 노력(Least effort) — 관리 오버헤드 최소화 【정답 포인트】 ▸ B가 정답: S3 로깅 활성화 후 Athena로 직접 SQL 분석 가능 ▸ Athena는 S3 데이터에 대해 별도 ETL/데이터베이스 없이 즉시 쿼리 가능 ▸ 가장 간단한 구현: 로깅 → 외부 테이블 생성 → SQL 실행 ▸ 운영 복잡도 최소: 인프라 관리 불필요 【오답 체크】 (A) Aurora로 로그를 가져오려면 ETL 프로세스 필요(추가 관리) (C) Lambda 기반은 실시간 처리 필요하고 데이터베이스 관리 오버헤드 발생 (D) CloudWatch Logs + Kinesis는 불필요한 복잡성(실시간 분석 요구 없음) 【시험 포인트】 ▸ "최소한의 노력" 핵심: 서버리스 + 관리형 서비스 선택 ▸ Athena: S3 데이터 직접 분석의 표준 솔루션 ▸ DOP 특화: 운영 효율성과 비용 최적화