정답 · 해설

해설

【핵심 용어】 ▸ Datapoints to Alarm — 알람 발생에 필요한 위반 데이터포인트 수 ▸ Evaluation Period — 평가 기간 (1시간) ▸ Treat Missing Data — 누락 데이터 처리 방식 【정답 포인트】 ▸ 요구사항: "3시간 이상 5 미만" & "매시간 평가" & "누락 데이터 시 계속 실행" ▸ 평가 기간 1시간 × 12개 데이터포인트 = 12시간 윈도우 ▸ "3시간" = 12 중 3개 데이터포인트가 임계값 미만 (threshold < 5) ▸ "누락 데이터 시 계속 실행" = Treat Missing Data as NOT breaching ▸ EC2 작업: Datapoint를 12 중 3으로 설정하고 알람 트리거 시 중지 【오답 체크】 (A) 누락 데이터를 breach로 취급 = 누락 시에도 중지 (요구사항 위반) (C) 12 중 9개 필요 = 9시간 이상 필요 (3시간 요구사항 아님) (D) 누락 데이터를 breach로 취급 (요구사항 위반) 【시험 포인트】 ▸ Evaluation Periods 설정: 12시간 윈도우 = 1시간 × 12 datapoints ▸ Datapoints to Alarm = 3 (12중 최소 3개) ▸ Treat Missing Data = "notBreaching" (누락 시에도 알람 안함) ▸ Action: EC2 stop (Systems Manager 아님, 직접 EC2 action) ▸ NetworkPacketsIn < 5가 3시간 이상 = 유휴 인스턴스 = 중지 대상

해설

【핵심 용어】 ▸ CloudFormation StackSets — 여러 계정/리전에 템플릿 배포 ▸ Delegated Administrator — 조직 작업을 위한 위임 계정 ▸ Operational Efficiency — 관리 부담 최소화 【정답 포인트】 ▸ "500개 계정에 배포" = StackSets 필수 (manual deployment 불가) ▸ "가장 효율적" = 위임된 관리자 계정에서 한 번에 배포 ▸ CloudFormation 템플릿에 Lambda + EventBridge 예약 규칙 포함 ▸ StackSets는 멤버 계정마다 자동으로 배포 및 EventBridge 로컬 실행 ▸ 각 멤버 계정에서 로컬 EventBridge 규칙이 30분마다 Lambda 트리거 【오답 체크】 (A) 위임 관리자 계정의 EventBridge로 "각 멤버의 Lambda 호출" = 크로스 계정 복잡성 증가 (B) 수동 스크립트 + custom deployment = 운영 효율성 떨어짐, 확장성 제한 (D) CodeDeploy는 애플리케이션 배포용, Lambda 함수 배포에 부적합 【시험 포인트】 ▸ 멀티 계정 배포: CloudFormation StackSets (self-managed 또는 service-managed) ▸ 위임된 관리자 설정 후 StackSets 사용 (Organizations 권한 활용) ▸ 각 계정마다 자체 EventBridge 규칙 배포 (로컬 트리거) ▸ Lambda의 권한: 해당 계정의 EC2/EBS 리소스만 접근 (IAM 역할) ▸ "operationally efficient" = automated, centralized management

해설

【핵심 용어】 ▸ appspec.yml hooks — CodeDeploy 배포 라이프사이클 이벤트 ▸ Blue/Green Deployment — 구 인스턴스(Blue) → 신 인스턴스(Green) 전환 ▸ License Installation — 배포 전 필수 구성 요소 【정답 포인트】 ▸ "대체 인스턴스가 요청을 처리하기 전에" = 트래픽 받기 전 준비 완료 필요 ▸ CodeDeploy hooks 순서: BeforeInstall → AfterInstall → ApplicationStart → ValidateService → BeforeAllowTraffic → AfterAllowTraffic ▸ BeforeInstall: 애플리케이션 코드 다운로드 전, 시스템 구성 단계 ▸ 라이선스 파일: 애플리케이션 코드보다 먼저 준비되어야 함 【오답 체크】 (A) AfterBlockTraffic: 구 인스턴스에 트래픽 차단 후 (너무 늦음) (B) BeforeBlockTraffic: 구 인스턴스에 아직 트래픽 있는 상태 (혼란스러움) (D) DownloadBundle: appspec.yml에 존재하지 않는 hook 【시험 포인트】 ▸ CodeDeploy 라이프사이클: ApplicationStop → BeforeInstall → AfterInstall → ApplicationStart → ValidateService → BeforeAllowTraffic → AfterAllowTraffic ▸ BeforeInstall은 가장 초기 단계 (애플리케이션 설치 전) ▸ Blue/Green에서 Green 인스턴스는 모든 준비 후 트래픽 수신 ▸ 필수 파일 설치: BeforeInstall에서 처리

해설

【핵심 용어】 ▸ CodeBuild Report Group — 테스트 결과 집계 및 시각화 ▸ JUnit XML Format — 테스트 프레임워크 표준 보고 형식 ▸ buildspec.yml reports section — 테스트 결과 생성 및 저장 【정답 포인트】 ▸ "테스트 보고서를 생성해야 함" = CodeBuild Report Group 필수 ▸ JUnit XML은 Python unittest, pytest 등 표준 형식 ▸ buildspec.yml의 reports 섹션에서 리포트 그룹 지정 ▸ CodePipeline에서 테스트 단계 후 CodeBuild 프로젝트 실행 ▸ 보고서는 CodeBuild 콘솔에서 시각화 및 추적 가능 【오답 체크】 (A) CodeGuru Reviewer는 정적 코드 분석 (단위 테스트 아님) (C) CodeArtifact는 패키지 저장소, appspec.yml은 Lambda 배포용 아님 (D) S3에 업로드는 가능하지만 reports section 형식이 없음 (가시성 떨어짐) 【시험 포인트】 ▸ CodeBuild test 단계: buildspec.yml으로 테스트 실행 ▸ 결과 형식: JUNITXML, CUCUMBERJSON 등 표준 형식 지원 ▸ CodeBuild Report Group: 테스트 결과 수집 및 대시보드 표시 ▸ 보고서는 CodePipeline 콘솔에서 링크로 접근 가능 ▸ Python unittest → JUnit XML 형식으로 변환 가능

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — AWS Organizations에서 계정의 최대 권한 범위를 정의하는 정책. 조직 루트 수준에서 적용하면 모든 멤버 계정에 영향 ▸ Root User — AWS 계정 최상위 주체, ARN 형식: arn:aws:iam::ACCOUNT-ID:root ▸ Explicit Deny — IAM 정책보다 우선순위가 높은 명시적 거부 효과 ▸ Principal/Condition — 정책에서 루트 사용자만 선별적으로 타게팅하기 위한 요소 【정답 포인트】 ▸ SCP는 Effect "Deny", Action "*"로 설정하여 루트 사용자의 모든 API 호출 차단 ▸ Principal 또는 Condition에서 루트 사용자만 지정: aws:PrincipalArn으로 arn:aws:iam::*/root 패턴 활용 ▸ 조직 루트에 적용되면 모든 멤버 계정의 루트 사용자가 제한됨 ▸ 일반 IAM 사용자는 제외되어야 하므로 조건부 필터링 필수 ▸ 정책 구조: {"Effect": "Deny", "Action": "*", "Resource": "*", "Principal": {"AWS": "arn:aws:iam::*/root"}} 【오답 체크】 ▸ Allow 효과 정책 — 루트 사용자 거부 불가능. Deny가 아니면 제약이 작동하지 않음 ▸ Condition 생략 또는 범위 과다 — 모든 사용자를 차단하면 비즈니스 운영 중단, 루트만 정확히 필터링해야 함 ▸ Resource를 특정 서비스(EC2)로 제한 — 요구사항은 "모든 API 호출" 차단이므로 부족 ▸ NotPrincipal과 Deny 혼합 — SCP는 NotPrincipal 미지원, Principal 또는 Condition 사용 ▸ 루트 ARN을 정확하지 않게 지정 — arn:aws:iam::ACCOUNT-ID:root 형식 필수, 와일드카드 불명확하면 오동작 【시험 포인트】 ▸ 조직 수준 SCP는 모든 멤버 계정에 일괄 적용되므로, 루트 계정 보안의 핵심 통제 수단 ▸ 루트 사용자 ARN 패턴 정확히 인식: arn:aws:iam::123456789012:root (계정별 고유) ▸ aws:PrincipalArn 조건으로 루트만 필터링하면 IAM 사용자 정상 운영 보장 ▸ SCP의 Deny는 IAM 정책, 리소스 기반 정책보다 상위 우선순위로 루트 사용자 제약 반드시 적용 ▸ 의도하지 않은 서비스 중단 방지 목표이므로, 루트와 IAM 사용자 구분이 정책 설계의 핵심

해설

【핵심 용어】 ▸ Lookout for Metrics — ML 기반 이상 탐지 ▸ Kinesis Data Firehose — 대량 데이터를 S3로 전달 ▸ Anomaly Detection — 시계열 데이터에서 패턴 이탈 탐지 【정답 포인트】 ▸ "시간 경과에 따라 이상 현상 식별" = ML 기반 탐지 필요 ▸ CloudWatch Logs → Kinesis Firehose → S3 → Lookout for Metrics ▸ Lookout for Metrics는 S3 데이터에 대한 자동 이상 탐지 ▸ 이상 탐지 → EventBridge → Lambda로 자동 대응 ▸ 예측 가능한 트래픽이므로 baseline 대비 편차 탐지 효과적 【오답 체크】 (A) Kinesis Data Analytics는 스트림 처리용이지 이상 탐지 AI 아님 (C) Lambda로 수동 구현 = 복잡하고 ML 기능 없음 (D) Kinesis만으로는 이상 탐지 기능 제한적 (Lookout 없음) 【시험 포인트】 ▸ VPC Flow Logs → CloudWatch Logs → Kinesis Firehose → S3 ▸ Lookout for Metrics: 자동 이상 탐지 (baseline 학습 포함) ▸ Lookout 이상 탐지 → EventBridge Rule → Lambda (자동 응답) ▸ "예측 가능한 트래픽" = 이상 탐지에 최적의 조건 ▸ ML 기반 탐지는 수동 정의보다 정확도 높음

해설

【핵심 용어】 ▸ OrganizationAccountAccessRole — 멤버 계정 접근용 기본 역할 ▸ Trust Policy — 역할을 가정할 수 있는 주체 정의 ▸ Cross-Account Access — 계정 간 역할 가정 【정답 포인트】 ▸ 에러 원인: 새 멤버 계정에 OrganizationAccountAccessRole이 없음 ▸ Organizations 초대 후 자동 생성되지 않음 (수동 생성 필요) ▸ (C) 해결책: 새 계정에서 역할 생성 + Trust Policy에 관리 계정 ARN 추가 ▸ AdministratorAccess 정책 필수 (관리 계정 사용자의 권한 수준) ▸ Trust Policy: Principal: AWS: arn:aws:iam::MANAGEMENT_ACCOUNT_ID:root 【오답 체크】 (A) 관리 계정에서 권한 추가해도 멤버 계정의 역할이 없으면 가정 불가 (B) SCP는 최대 권한 정의이지 역할 가정 권한과 무관 (D) OrganizationAccountAccessRole이 존재해야 신뢰 정책 편집 가능 【시험 포인트】 ▸ Organizations 초대 시 자동 생성: OrganizationAccountAccessRole (기본 역할) ▸ 외부 계정 참여 시: 역할을 수동으로 생성해야 함 ▸ Cross-account 접근: 신뢰 정책에 다른 계정의 AWS principal 지정 ▸ AdministratorAccess 정책: 모든 AWS 서비스 및 리소스 접근 허용

해설

【핵심 용어】 ▸ Batch Processing — Kinesis 레코드를 배치로 처리 ▸ Bisect Batch on Function Error — 배치 분할로 오류 격리 ▸ DLQ (Dead Letter Queue) — 처리 실패 메시지 저장 【정답 포인트】 ▸ 문제: 배치에 1개 오류 → 전체 배치 실패 → 모든 레코드가 DLQ로 ▸ (B) Bisect Batch: 오류 시 배치를 반으로 분할 ▸ 오류 없는 레코드만 빠르게 처리, 오류만 격리 ▸ 재시도 후에도 실패한 레코드만 DLQ 전송 ▸ 결과: "이미 처리된 레코드" DLQ 진입 방지 【오답 체크】 (A) 재시도 증가: 같은 레코드가 여전히 DLQ 진입 (C) 동시 배치: DLQ 레코드 수와 무관 (D) 최대 나이 감소: 레코드 만료만 가속, 처리 문제 해결 안함 【시험 포인트】 ▸ Lambda Event Source Mapping에서 "Bisect Batch on Function Error" 옵션 ▸ 배치 크기가 1이 될 때까지 반복 분할 ▸ 최대 재시도 횟수 후 DLQ 전송 ▸ 결과: 오류 레코드만 DLQ, 성공 레코드는 즉시 처리 완료 ▸ REST API 호출 성공 + DLQ 오류만 = 정확한 오류 처리

해설

【핵심 용어】 ▸ CodePipeline — 자동화된 CI/CD 파이프라인 ▸ CodeDeploy Linear Traffic Shift — 일정 시간 간격으로 트래픽 점진 이동 ▸ Lambda Gradual Deployment — Lambda 버전의 점진적 배포 【정답 포인트】 ▸ "자동화 + 클라우드" = CodePipeline + CodeBuild ▸ "점진적 트래픽 이동" = CodeDeploy with traffic shift config ▸ CodeDeployDefault.LambdaLinear10PercentEvery3Minutes = 3분마다 10% 트래픽 이동 ▸ CodePipeline 자동 트리거: 코드 푸시 → CodeBuild 테스트 → CodeDeploy 배포 ▸ 개발자 속도: 모든 단계 자동화, 수동 개입 최소화 【오답 체크】 (A) Canary는 AWS SAM을 통해 자동 설정하고, CodePipeline만으로는 불완전 (B) CloudFormation은 Lambda 배포 일부만 처리, traffic shift 설정 복잡 (D) Lambda 함수로 수동 배포 = 자동화 부족, 복잡도 높음 【시험 포인트】 ▸ CodePipeline 자동화: Source → Build (CodeBuild) → Deploy (CodeDeploy) ▸ CodeDeploy Lambda 배포 옵션: - CodeDeployDefault.LambdaAllAtOnce: 즉시 100% 이동 - CodeDeployDefault.LambdaLinear10PercentEvery3Minutes: 3분마다 10% - CodeDeployDefault.LambdaLinear10Percent: 매분 10% - CodeDeployDefault.LambdaCanary: 카나리 배포 ▸ 개발자 속도 최대화: 완전 자동화 + 표준 배포 전략 ▸ DynamoDB 읽기 마이크로서비스 = Lambda의 일반적 사용 사례

해설

【핵심 용어】 ▸ Multi-Environment Pipeline — 환경별 별도 파이프라인 ▸ Git Branching — 환경별 브랜치 전략 (test, prod) ▸ Manual Approval Gate — 프로덕션 배포의 컨트롤 【정답 포인트】 ▸ "테스트 환경만 자동 배포" = 테스트: 자동, 프로덕션: 수동 승인 ▸ 두 개의 CodePipeline = 두 환경 분리 (독립적 트리거) ▸ 하나의 CodeCommit repo + 환경별 브랜치 = 코드 관리 중앙화 ▸ 테스트 파이프라인: develop/test 브랜치 자동 배포 ▸ 프로덕션 파이프라인: main/prod 브랜치 + 수동 승인 【오답 체크】 (A) 단일 파이프라인, 환경 분리 불가능 (B) 리포지토리 분리 = 코드 관리 복잡도 증가 (D) CodeBuild만 사용, CodePipeline 없음 = 자동화 불완전 【시험 포인트】 ▸ CodePipeline 2개: test-pipeline (자동), prod-pipeline (수동 승인) ▸ CodeCommit 1개: develop/test 브랜치, main/prod 브랜치 ▸ test-pipeline 트리거: develop/test 푸시 → 자동 배포 ▸ prod-pipeline 트리거: main/prod 푸시 → 수동 승인 후 배포 ▸ CloudFormation: Lambda 배포 및 버전 관리 ▸ 효율성: 코드 중앙화 + 환경별 독립 제어

해설

【핵심 용어】 ▸ appspec.yml — CodeDeploy 배포 구성 파일 ▸ EC2 Auto Scaling — 자동 확장 및 오류 인스턴스 교체 ▸ 특정 소프트웨어 버전 — Tomcat, HAProxy, Varnish 설치 【정답 포인트】 ▸ "특정 버전의 Apache Tomcat, HAProxy, Varnish" = OS 레벨 제어 필요 ▸ "OS 수준 매개변수 조정" = EC2 인스턴스 제어 필수 ▸ CodeDeploy: appspec.yml의 lifecycle hooks로 소프트웨어 설치 및 설정 ▸ EC2 Auto Scaling: 오류 인스턴스 자동 교체 ▸ CodeDeploy + Auto Scaling 통합: 배포 및 확장성 자동화 【오답 체크】 (A) Docker 이미지: 특정 OS 버전 조정 어려움, ECS/Fargate 고정화 (B) Elastic Beanstalk 웹 서버: 한정된 소프트웨어 지원, OS 매개변수 조정 제한 (C) Elastic Beanstalk 워커: 웹 서비스 배포용 아님, 구조 맞지 않음 【시험 포인트】 ▸ appspec.yml hooks: - ApplicationStop: 기존 애플리케이션 중지 - BeforeInstall: Tomcat, HAProxy, Varnish 설치 - AfterInstall: 설정 파일 적용 - ApplicationStart: 애플리케이션 시작 - ValidateService: 상태 검증 ▸ CodeDeploy의 EC2 Auto Scaling 통합: 배포 그룹 생성 후 Auto Scaling 그룹 지정 ▸ 오류 인스턴스: Auto Scaling이 자동으로 교체 ▸ 완전한 자동화: 소프트웨어 설치, 설정, 배포, 확장

해설

【핵심 용어】 ▸ CodeDeploy OneAtATime — 한 번에 1개 인스턴스씩 배포 ▸ EC2 Auto Scaling — 트래픽 기반 자동 확장 ▸ In-Place Deployment — 기존 인스턴스에서 직접 배포 【정답 포인트】 ▸ "전체 배포 성공" + "일부 인스턴스는 이전 버전" = 배포 후 새 인스턴스 시작 ▸ CodeDeployDefault.OneAtATime: 5개 인스턴스 순차 배포 ▸ 배포 중 Auto Scaling이 새 인스턴스 2개 시작 ▸ 새 인스턴스: 배포 대상 외 + 기존 AMI 사용 (이전 버전) ▸ 결과: 배포된 3개 + 신규 2개(이전 버전) = 총 5개 【오답 체크】 (A) 배포 실패면 "배포 성공"이라는 조건 위반 (B) AfterInstall 실패: 3개도 롤백되어야 함 (C) CodeDeploy 에이전트 미설치: 전체 배포 실패 【시험 포인트】 ▸ OneAtATime 배포 중: 일부 인스턴스만 배포됨 ▸ Auto Scaling 활동: 배포 그룹 트리거 가능 ▸ 새로 시작된 인스턴스: CodeDeploy 배포 대상 추가 필요 ▸ EC2 Auto Scaling과 CodeDeploy 통합 시 주의점: - Lifecycle hook으로 배포 중 확장 조절 - 또는 배포 후 Auto Scaling 재개 ▸ Blue/Green 배포로 이 문제 완전히 해결 가능

해설

【핵심 용어】 ▸ AWS Config — AWS 리소스 구성을 지속적으로 모니터링하는 서비스 ▸ IAM 정책 — 권한을 제어하기 위한 정책 문서 ▸ Elastic IP — 고정된 공인 IP 주소 【정답 포인트】 정답은 B입니다. 이 문제는 두 가지 요구사항을 만족해야 합니다: (1) 개발자가 Elastic IP를 연결하지 못하도록 예방, (2) 만약 Elastic IP가 연결되었을 경우 알림 수신. IAM 정책의 deny 명령으로 associate-address 권한을 거부하면 개발자가 이 작업을 수행할 수 없습니다. AWS Config의 사용자 지정 규칙은 프로덕션 인스턴스(태그 기반)에 Elastic IP가 연결된 상태를 지속적으로 감시하고 보안 팀에 알림을 보냅니다. 이는 실제 차단(preventive)과 감지(detective) 제어를 모두 구현합니다. 【오답 체크】 (A) Athena와 CloudTrail을 사용하면 사후(reactive) 분석만 가능하며, 예방 제어가 부족합니다. (C) Lambda 함수를 사용한 스케줄된 확인은 실시간 모니터링이 아니고 지연이 발생합니다. (D) EC2 IAM 역할의 deny 정책은 근본적인 문제 해결이 아니며 AWS Config의 지속적인 모니터링이 필요합니다. 【시험 포인트】 - IAM 정책: 예방적 제어(preventive control) - AWS Config: 규정 준수 감시(compliance monitoring) - 태그 기반 필터링: 특정 환경 대상화 - 정책 기반 거부 + 모니터링 규칙 조합 구성

해설

【핵심 용어】 ▸ EC2 Image Builder — AMI 생성 및 배포 자동화 서비스 ▸ Resource Access Manager — AWS 리소스를 조직 내 계정과 공유 ▸ 골든 이미지 — 표준 구성으로 미리 설정된 AMI 【정답 포인트】 정답은 B입니다. Amazon EC2 Image Builder는 이미지 생성 프로세스를 완전히 자동화하여 Linux 패치, Chef 에이전트 설치, 이미지 생성을 파이프라인으로 관리합니다. 관리 오버헤드가 가장 낮으며 일관된 결과를 보장합니다. AWS Resource Access Manager(RAM)는 생성된 이미지를 조직 내 부서 계정에 쉽게 공유하는 메커니즘을 제공합니다. 이는 완전 자동화된 솔루션으로 수동 작업이 최소화됩니다. 【오답 체크】 (A) 수동 스크립트 작성은 유지보수 부담이 크고 일관성을 보장할 수 없습니다. (C) Systems Manager runbook도 가능하지만 EC2 Image Builder보다 AMI 관리에 최적화되어 있지 않습니다. (D) Parameter Store를 사용한 ID 참조는 공유 메커니즘으로 부적절하며 RAM과 비교하여 확장성이 떨어집니다. 【시험 포인트】 - EC2 Image Builder: 이미지 파이프라인 자동화 - RAM: 조직 내 리소스 공유 - 자동화 기준: 관리 오버헤드 최소화 - 멀티 계정 배포 전략

해설

【핵심 용어】 ▸ AWS CodeDeploy — 배포 자동화 서비스 ▸ OneAtATime 전략 — 한 번에 하나의 인스턴스 배포 ▸ Auto Scaling — 자동 스케일링 그룹 관리 ▸ 자동 롤백 — 조건에 따른 배포 되돌리기 【정답 포인트】 정답은 B입니다. AWS CodeDeploy는 배포 전략에 'CodeDeployDefault OneAtAtime'을 제공하여 한 번에 하나의 인스턴스만 배포합니다. CloudWatch 알람으로 CPU 사용률 85% 임계값을 설정하면 메트릭을 지속적으로 모니터링합니다. CodeDeploy의 자동 롤백 기능은 알람이 트리거될 때 배포를 자동으로 되돌립니다. 이는 Auto Scaling 그룹과 완벽하게 통합되며 단계적 배포와 자동 롤백을 모두 지원합니다. 【오답 체크】 (A) Step Functions와 라이프사이클 후크는 복잡하고 자동 롤백 기능이 내장되어 있지 않습니다. (C) Elastic Beanstalk은 가능하지만 CodeDeploy보다 세분화된 롤백 제어가 부족합니다. (D) Systems Manager의 Blue/Green은 가능하지만 Auto Scaling 그룹과의 통합이 CodeDeploy보다 덜 자연스럽습니다. 【시험 포인트】 - CodeDeploy 배포 전략: 단계적 배포 구성 - 자동 롤백: 조건 기반 배포 되돌리기 - CloudWatch 알람: 메트릭 기반 모니터링 - Auto Scaling 통합: 배포 중 인스턴스 관리

해설

【핵심 용어】 ▸ AWS CodeCommit — 관리형 Git 저장소 서비스 ▸ 브랜치 전략 — Git 브랜칭 패턴 (main, develop, feature) ▸ Pull Request — 코드 리뷰 및 병합 제어 메커니즘 ▸ 분산 버전 관리 — 협업 코드 관리 【정답 포인트】 정답은 A입니다. AWS CodeCommit은 표준 Git 저장소로 여러 개발자의 동시 개발을 지원합니다. 메인 브랜치를 프로덕션, 테스팅 브랜치를 테스트 환경에 사용하는 표준 branching 전략은 코드 충돌을 방지합니다. 각 개발자는 feature 브랜치에서 작업하고 pull request로 코드 리뷰 후 병합하므로 코드 품질과 안정성을 보장합니다. S3 버킷은 버전 관리 기능이 부족하고 브랜칭 개념을 지원하지 않습니다. 【오답 체크】 (B) S3 버킷과 Lambda는 적절한 버전 제어 시스템이 아니며 충돌 해결 메커니즘이 부족합니다. (C) 메인 브랜치를 프로덕션과 테스트 모두에 사용하면 환경 분리가 불명확합니다. (D) S3에서 브랜치를 구현할 수 없으며 이는 Git의 강력한 기능을 활용하지 못합니다. 【시험 포인트】 - CodeCommit: 중앙 집중식 코드 저장소 - 브랜칭 전략: main/develop/feature 패턴 - Pull Request: 협업 개발 프로세스 - 환경별 브랜치 분리

해설

【핵심 용어】 ▸ Auto Scaling 상태 확인 교체 — 실패 인스턴스 자동 재시작 ▸ CloudWatch 에이전트 — 상세한 메트릭 수집 (메모리, 디스크) ▸ SNS 알림 — 임계값 초과 시 알림 ▸ 메모리 누수 대응 — 메모리 모니터링 + 인스턴스 교체 【정답 포인트】 정답은 A와 E입니다. 메모리 누수 문제 대응에는 두 가지가 필요합니다. (1) 응급 조치: Auto Scaling의 상태 확인 실패 시 인스턴스 교체 (A) — 건강하지 않은 인스턴스를 자동으로 재시작하여 서비스 복구; (2) 예방 및 모니터링: CloudWatch 에이전트로 메모리 사용률을 정확하게 수집 (E) — EC2 인스턴스 내부의 메모리 지표를 수집하여 SNS를 통해 알림하면 운영팀이 조치 가능합니다. 이 조합으로 자동 복구와 사전 경보를 동시에 구현합니다. 【오답 체크】 (B) 상태 확인 간격 단축은 근본 원인 해결이 아니며 오히려 부하를 증가시킵니다. (C) TCP 확인은 포트 연결성만 확인하고 애플리케이션 상태를 검증하지 못합니다. (D) CloudWatch 기본 메트릭은 EC2 인스턴스 수준의 상세 메모리 정보를 수집할 수 없습니다. 【시험 포인트】 - 상태 확인 기반 인스턴스 교체: 자가 치유(self-healing) - CloudWatch 에이전트: OS 수준 메트릭 수집 - 메모리 모니터링: 누수 조기 감지 - 알림 기반 운영: SNS 통합

해설

【핵심 용어】 ▸ AWS Health 이벤트 — AWS 인프라 관련 알림 ▸ EC2 인스턴스 폐기 — 호스트 유지보수로 인한 계획된 종료 ▸ EventBridge 규칙 — 이벤트 기반 트리거 ▸ Systems Manager Automation — 운영 작업 자동화 【정답 포인트】 정답은 D입니다. EC2 인스턴스 폐기는 AWS Health에서 'EC2 Instance Retirement' 이벤트로 제공되며, EventBridge는 이 이벤트를 감지할 수 있습니다. Systems Manager Automation runbook을 사용하여 폐기 예정 이벤트 발생 시 인스턴스를 중지(stop)하고 시작(start)하면 호스트 폐기를 우회하고 새로운 호스트에 인스턴스를 배치할 수 있습니다. EBS 기반 인스턴스는 중지/시작으로 다른 호스트로 이동되며 데이터는 유지됩니다. 이는 자동화되고 신속한 대응입니다. 【오답 체크】 (A) 일주일 단위 스케줄된 확인은 이미 폐기가 시작된 후 대응할 수 있어 너무 늦습니다. (B) Auto Recovery는 인스턴스 상태 확인 실패 대응으로 폐기 이벤트 감지 메커니즘이 아닙니다. (C) 수동 유지보수 윈도우는 자동화가 아니며 모든 폐기를 커버하지 못합니다. 【시험 포인트】 - AWS Health: 계획된 인프라 이벤트 감지 - EventBridge: 이벤트 기반 자동화 - Stop/Start: EBS 인스턴스 호스트 이동 - Systems Manager: 운영 runbook 실행

해설

【핵심 용어】 ▸ CloudFormation 사용자 지정 리소스 — Lambda 함수 기반 사용자 정의 로직 ▸ 조건부 활성화 — 기존 상태 확인 후 필요한 경우만 작업 ▸ StackSets 배포 — 여러 계정에 걸친 동시 배포 ▸ 멱등성(Idempotency) — 반복 실행 안전 【정답 포인트】 정답은 A입니다. CloudFormation StackSets을 여러 계정에 배포할 때, 일부 계정은 이미 GuardDuty가 활성화되어 있고 일부는 그렇지 않을 수 있습니다. Conditions 섹션으로는 각 계정의 현재 상태를 감지할 수 없으므로 배포 실패가 발생합니다. 그러나 CloudFormation 사용자 지정 리소스는 Lambda 함수를 통해 배포 전에 현재 상태를 검사하고, GuardDuty가 이미 활성화된 경우 건너뛰고, 활성화되지 않은 경우만 활성화할 수 있습니다. 이렇게 하면 StackSets 배포 오류를 방지하고 모든 계정이 일관된 상태를 유지합니다. 【오답 체크】 (B) Conditions 섹션은 템플릿 매개변수를 기반으로 조건부 처리하며 실시간 계정 상태 감지 불가능합니다. (C) Fn::GetAtt는 스택 내 리소스 속성만 가져올 수 있고 외부 GuardDuty 상태 조회 불가능합니다. (D) 수동 검색은 자동화 목표에 부합하지 않습니다. 【시험 포인트】 - 사용자 지정 리소스: 복잡한 배포 로직 구현 - Lambda 기반 검증: 배포 전 상태 확인 - StackSets 오류 방지: 멱등성 있는 배포 - Control Tower 통합: 관리 계정 기반 배포

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — 조직 수준의 권한 제어 ▸ OU 계층 구조 — 워크로드 > 개발/프로덕션 ▸ 명시적 거부 — SCP 거부 정책으로 권한 제한 ▸ 예외 조건 — 특정 역할 제외 로직 【정답 포인트】 정답은 B와 E입니다. 조직 구조에서 기본적으로 조직 루트에 FullAWSAccess SCP (B) 를 적용하여 기본적으로 모든 액세스를 허용합니다. 그러나 프로덕션 OU에만 IAM 작업을 거부하는 SCP (E) 를 추가로 적용하되, 특정 관리 IAM 역할은 제외합니다. 이렇게 하면 개발 OU의 사용자는 IAM 작업이 가능하지만 프로덕션 OU의 일반 사용자는 IAM 작업이 불가능하고, 지정된 관리 역할만 프로덕션의 IAM을 관리할 수 있습니다. 【오답 체크】 (A) 조직 루트에 거부 SCP를 적용하면 관리 역할도 액세스가 제한됩니다. (C) 개발 OU에 허용 SCP를 추가하면 불필요하며 프로덕션 제어가 부족합니다. (D) 워크로드 OU에 거부 SCP를 적용하면 개발과 프로덕션 모두에 적용되어 개발 OU도 제한됩니다. 【시험 포인트】 - SCP 계층: 조직 루트의 기본 정책 + OU 특정 정책 - 거부 원칙: 가장 제한적인 정책이 우선 - OU 수준 정책: 하위 OU에만 영향 - 역할 기반 예외: 관리 역할 조건부 허용