정답 · 해설

해설

【핵심 용어】 ▸ CloudWatch Logs Metric Filter — 로그 데이터에서 메트릭을 추출하고 수치화하는 메커니즘 ▸ Custom Metrics with Dimensions — 응답 코드, 버전과 같은 다중 속성으로 메트릭을 분류 【정답 포인트】 ▸ Lambda에서 수집한 데이터(API 작업명, 응답 코드, 버전)를 CloudWatch Logs로 기록 → 메트릭 필터로 정규화 및 메트릭 생성 ▸ 차원(Dimensions)을 통해 응답 코드와 버전별로 메트릭 분할 ▸ 간단하고 비용 효율적인 방식으로 커스텀 메트릭 구현 【오답 체크】 (B) CloudWatch Logs Insights는 실시간 쿼리 도구이지 메트릭 자동 생성 기능이 없음 (C) ALB 액세스 로그는 애플리케이션 수준의 세부 정보(API 작업명)를 포함하지 않음 (D) X-Ray는 추가 비용과 복잡도 증가, 메트릭 필터보다 무겁고 비효율적 【시험 포인트】 ▸ CloudWatch Logs Metric Filter는 DOP 시험의 핵심 모니터링 도구 ▸ 커스텀 애플리케이션 메트릭은 CloudWatch Logs 기반이 표준 ▸ Dimensions를 통한 메트릭 분류는 다중 버전 환경에서 필수

해설

【핵심 용어】 ▸ Provisioned Concurrency — Lambda 함수를 미리 초기화하여 cold-start 제거 ▸ Application Auto Scaling — 시간대별 트래픽 변동에 따라 동시성을 동적으로 조정 ▸ Cold-start — 새로운 Lambda 인스턴스 초기화 시간(8-10초) 【정답 포인트】 ▸ Provisioned Concurrency는 cold-start 지연 문제를 직접 해결 → 8-10초 제거 ▸ Auto Scaling을 결합하면 낮 중간 피크(10배) 시 확장, 저녁 저점(10%) 시 축소 가능 ▸ 최소값 1은 기본 가용성, 최대값 100은 피크 대응용량 【오답 체크】 (A) 동시성 1은 cold-start 문제 해결 못함, DAX 제거는 불필요 (B) 예약된 동시성은 cold-start를 제거하지 않음, cold-start는 프로비저닝된 동시성 필요 (D) API Gateway에는 Application Auto Scaling 불가능, 예약된 동시성도 부적절 【시험 포인트】 ▸ Cold-start 레이턴시 → Provisioned Concurrency 직결 ▸ 변동하는 트래픽 패턴 → Application Auto Scaling과 조합 ▸ DOP 시험은 실제 성능 문제 해결 능력 평가

해설

【핵심 용어】 ▸ CodeDeploy Environment Variables — 배포 시 자동으로 주입되는 배포 그룹 정보 ▸ DEPLOYMENT_GROUP_NAME — 현재 배포 그룹의 이름을 나타내는 내장 환경 변수 ▸ BeforeInstall Lifecycle Hook — 애플리케이션 설치 전에 실행되는 단계 【정답 포인트】 ▸ CodeDeploy는 DEPLOYMENT_GROUP_NAME을 자동으로 제공 → 추가 구성 불필요 ▸ 환경 변수는 각 배포 시마다 자동으로 주입되므로 리비전 재생성 불필요 ▸ BeforeInstall은 애플리케이션 설치 전에 실행되어 로그 레벨 구성 가능 ▸ 최소 오버헤드: 단일 스크립트로 모든 배포 그룹 대응 【오답 체크】 (A) 메타데이터 서비스, EC2 API 호출은 불필요 복잡도 증가, EC2 태깅 관리 필요 (C) CodeDeploy 커스텀 환경 변수는 기능 미지원, 검증 단계에서는 너무 늦음 (D) DEPLOYMENT_GROUP_ID는 존재하지 않는 환경 변수 【시험 포인트】 ▸ CodeDeploy 내장 환경 변수(DEPLOYMENT_GROUP_NAME) 숙지 필수 ▸ 수명 주기 훅(Lifecycle Hooks) 순서: ApplicationStop → BeforeInstall → ApplicationStart → ValidateService ▸ 설정 변경은 BeforeInstall에서 처리하는 것이 일반적

해설

【핵심 용어】 ▸ AWS Config Managed Rule — AWS에서 제공하는 사전 정의된 규칙(태그 검증, 리소스 준수) ▸ Remediation Action — 규정 비준수 리소스를 자동으로 수정하는 메커니즘 ▸ EventBridge vs Config — EventBridge는 신규 생성 이벤트만 감지, Config는 기존 리소스도 평가 【정답 포인트】 ▸ "모든 EBS 볼륨" → 기존 + 신규 리소스 모두 대응 필요 → AWS Config 필수 ▸ EC2::Volume 관리형 규칙은 태그 검증 기능 제공 → 커스텀 규칙보다 간단 ▸ 자동 수정(Remediation)으로 weekly 기본값 적용 → 수동 작업 제거 ▸ Config는 지속적 컴플라이언스 평가 기능 제공 【오답 체크】 (A) 커스텀 규칙은 관리형 규칙보다 복잡, EC2 리소스만 검증(EBS::Volume 아님) (C) EventBridge CreateVolume은 신규 볼륨만 감지, 기존 볼륨 미포함 (D) ModifyVolume 이벤트 추가도 신규/변경 이벤트만 감지, 기존 리소스 대응 불가 【시험 포인트】 ▸ Config = 지속적 규정 준수 평가 + 자동 수정 (모든 리소스) ▸ EventBridge = 이벤트 기반 트리거 (신규/변경 이벤트만) ▸ DOP 시험: 기존 리소스 대응 필요 → Config 선택

해설

【핵심 용어】 ▸ Aurora Cluster Endpoint — 모든 읽기/쓰기 요청을 단일 라이터 인스턴스로 라우팅 ▸ Reader Endpoint — 읽기 전용 작업을 여러 리더 인스턴스에 분산 ▸ Multi-AZ — 다중 AZ에 레플리카 배치 (고가용성), 하지만 유지보수 중단 여전히 발생 ▸ Custom ANY Endpoint — 특정 목적의 커스텀 엔드포인트 (일반적으로 필요 없음) 【정답 포인트】 ▸ 유지보수 중 최소 중단 → 리더 인스턴스 추가로 읽기 작업 분산 ▸ 인스턴스 엔드포인트(쓰기) + 리더 엔드포인트(읽기) 분리 → 쓰기 작업만 유지보수 영향 ▸ 리더 인스턴스는 유지보수 대상이 아니므로 읽기 작업 지속 가능 ▸ 최소 변경 + 최대 가용성 【오답 체크】 (B) 커스텀 ANY 엔드포인트는 필요 없음, 비효율적 (C) Multi-AZ는 고가용성이지만 유지보수 시 프라이머리 인스턴스 업그레이드 필수 → 중단 발생 (D) Multi-AZ + ANY 엔드포인트는 불필요한 추가 작업 【시험 포인트】 ▸ Aurora 유지보수: 리더 먼저 업그레이드 → 프라이머리 마지막 업그레이드 ▸ 읽기 분산 = Reader Endpoint 활용 ▸ Multi-AZ는 고가용성이지만 유지보수 중단 시간 단축에만 도움

해설

【핵심 용어】 ▸ AMI Copy with Encryption — 암호화되지 않은 AMI를 암호화된 AMI로 변환 ▸ KMS Grant — 교차 계정 KMS 키 사용 권한 위임 ▸ Cross-Account KMS — 다른 계정이 KMS 키를 사용할 수 있도록 설정 【정답 포인트】 ▸ A) 암호화되지 않은 AMI → 암호화 AMI 변환 (필수) ▸ D) 소스 계정 키 정책 수정 → 대상 계정의 그랜트 생성 권한 부여 ▸ F) 암호화된 AMI를 대상 계정과 공유 (암호화 상태로 공유) ▸ 3단계: 암호화 → 권한 위임 → 공유 【오답 체크】 (B) 기본 EBS 암호화 키는 계정별 고유 키, 교차 계정 공유 불가 (C) 소스 계정에서 대상 계정 역할에 직접 그랜트 생성 불가 (권한 부족) (E) 암호화되지 않은 AMI 공유는 보안 정책 위반 【시험 포인트】 ▸ 교차 계정 KMS: 키 정책(소스) + 그랜트(대상) 2단계 필수 ▸ 순서: 소스 키 정책 수정 → 대상에서 그랜트 생성 → AMI 공유 ▸ AMI 공유는 암호화 상태로만 가능

해설

【핵심 용어】 ▸ CodeDeploy Agent — EC2 인스턴스에서 배포를 수행하는 소프트웨어 ▸ AppSpec File — 배포 설정 및 라이프사이클 훅 정의 (스크립트 권한 설정 아님) ▸ Auto Scaling Group — CodeDeploy 배포 대상으로 지정 가능 ▸ IAM Role — CodeDeploy 에이전트가 S3, CodeDeploy 서비스 접근 필요 【정답 포인트】 ▸ A) AMI에 CodeDeploy 에이전트 사전 설치 → 새 인스턴스 자동 에이전트 포함 ▸ A) EC2 인스턴스 IAM 역할 권한 → CodeDeploy 서비스 접근 가능 ▸ D) CodePipeline에 CodeDeploy 액션 추가 → 자동 배포 트리거 ▸ Auto Scaling 그룹을 배포 대상으로 지정 가능 (동적 확장 대응) 【오답 체크】 (B) AppSpec 파일은 배포 스크립트만 정의, IAM 역할 권한 설정 기능 없음 (C) EC2 Image Builder 단계 불필요, RPM은 배포 시 설치 가능 (E) 특정 EC2 인스턴스 지정은 Auto Scaling 그룹 개념 위배 【시험 포인트】 ▸ CodeDeploy 사전 조건: 에이전트 설치 + IAM 역할 ▸ CodePipeline 통합: CodeDeploy 액션으로 자동 트리거 ▸ Auto Scaling 그룹 배포: 새 인스턴스 자동 포함 (동적 확장)

해설

【핵심 용어】 ▸ AWS Firewall Manager — 중앙 집중식 WAF/Shield 정책 관리 (조직 전체) ▸ Delegation Model — 중앙 보안 계정에서 모든 계정의 리소스 관리 ▸ GuardDuty — 위협 탐지 서비스 (WAF 정책 관리 기능 없음) ▸ AWS Config — 단일 계정 컴플라이언스 규칙 【정답 포인트】 ▸ A) Firewall Manager를 보안 계정에 위임 → 중앙 집중식 관리 가능 ▸ C) Firewall Manager 정책으로 ALB/API Gateway WAF 자동 연결 ▸ 조직 전체 수백 계정 → Firewall Manager 필수 ▸ 신규 리소스 자동 보호 가능 【오답 체크】 (B) GuardDuty는 위협 탐지만 수행, WAF 정책 관리 불가 (D) GuardDuty 정책은 존재하지 않음, WAF 연결 기능 없음 (E) AWS Config는 단일 계정 규칙, 조직 전체 정책 관리 불가 【시험 포인트】 ▸ 다중 계정 조직 관리 → Firewall Manager ▸ GuardDuty = 위협 탐지, Firewall Manager = 정책 관리 ▸ 신규 리소스 자동 보호 = Firewall Manager 정책

해설

【핵심 용어】 ▸ AWS Config Custom Rule — 리소스 규정 준수 평가 + 자동 수정 기능 ▸ KMS Key Rotation — 수동/자동 키 회전 ▸ Compliance Evaluation — 주기적 규칙 실행 (자동) ▸ SNS Notification — 규정 비준수 시 알림 【정답 포인트】 ▸ AWS Config는 KMS 키의 회전 날짜 메타데이터 접근 가능 ▸ 커스텀 규칙으로 마지막 회전 이후 경과 일수 계산 ▸ 90일 초과 시 규정 비준수 상태 → SNS 알림 ▸ 자동 주기 평가 (관리 오버헤드 최소) 【오답 체크】 (A) AWS KMS는 자동 SNS 게시 기능 없음 (B) Trusted Advisor는 일반 권장사항 도구, KMS 회전 세부 추적 불가 (D) Security Hub는 보안 구성 평가, KMS 회전 주기 세부 추적 불가 【시험 포인트】 ▸ KMS 회전 모니터링 → AWS Config Custom Rule ▸ 주기적 자동 평가 필요 → Config의 핵심 기능 ▸ 규정 준수 추적 → Config + SNS 조합

해설

【핵심 용어】 ▸ IAM-based Access — 역할 기반 S3 액세스 (보안 표준) ▸ Bucket Policy — 인증되지 않은 액세스 차단 ▸ Service Role — CodeBuild가 AWS 리소스 접근 권한 ▸ Temporary Credentials — IAM 역할 자동 제공 (수명 주기 관리) 【정답 포인트】 ▸ 보안 표준: IAM 역할을 통한 인증된 액세스 ▸ 버킷 정책으로 공개 액세스 차단 ▸ CodeBuild 서비스 역할에 S3 읽기 권한 추가 ▸ AWS CLI는 자동으로 임시 자격증명 사용 → 가장 안전 ▸ IAM 역할은 생명주기 관리 (자동 회전) 【오답 체크】 (A) AllowedBuckets는 CodeBuild 기능이 아님 (B) HTTPS 기본 인증은 표준 AWS 방식 아님, 토큰 수동 관리 필요 (위험) (D) IAM 액세스 키 사용은 권장되지 않음 (장기 자격증명, 수동 관리) 【시험 포인트】 ▸ AWS 보안 모범사례: IAM 역할 기반 접근 ▸ CodeBuild: 자동으로 임시 자격증명 주입 ▸ 버킷 정책으로 공개 액세스 명시적 차단 필수

해설

【핵심 용어】 ▸ Permission Sets — IAM Identity Center의 권한 정의 및 할당 메커니즘 ▸ aws:PrincipalTag — 사용자 태그 기반 리소스 액세스 제어 ▸ Attributes for Access Control — IdP 속성을 IAM Identity Center에서 사용 ▸ Inline Policy — 권한 집합에 직접 연결하는 정책 【정답 포인트】 ▸ B) 권한 집합 생성 + 인라인 정책 + PrincipalTag → 최소 권한 구현 ▸ C) IdP 그룹 → IAM Identity Center 권한 집합 연결 → 표준 SAML 통합 ▸ F) IdP 속성 매핑 → 태그 자동 주입 → PrincipalTag 조건 가능 ▸ 3단계: IdP 그룹 → 권한 집합 → 태그 기반 조건 【오답 체크】 (A) IAM 정책은 IAM Identity Center 권한 집합이 아님 (D) OU는 Control Tower 조직 단위, IAM Identity Center와 직접 연동 아님 (E) 사용자에게 수동 태그 적용 → 자동화 부족, IdP 속성 활용 안 함 【시험 포인트】 ▸ Control Tower + IAM Identity Center + SAML: 표준 구조 ▸ 최소 권한: Permission Set + PrincipalTag 조건 필수 ▸ IdP 속성 매핑: 자동화된 태그 주입 (수동 관리 제거)

해설

【핵심 용어】 ▸ ApproximateAgeOfOldestMessage — SQS에서 처리 대기 중인 가장 오래된 메시지의 나이 ▸ Reserved Concurrency — Lambda 함수의 최대 동시 실행 인스턴스 ▸ WriteThrottleEvents — DynamoDB 쓰기 용량 부족으로 인한 요청 거부 ▸ Auto Scaling — 수요에 따라 용량 자동 조정 【정답 포인트】 ▸ A) ApproximateAgeOfOldestMessage 증가 → 처리 지연 진단 ▸ A) Lambda 예약 동시성 한계 → 동시성 증가로 처리 속도 향상 ▸ D) WriteThrottleEvents 발생 → DynamoDB 쓰기 용량 부족 → Auto Scaling 최대값 상향 ▸ 메시지 나이 증가 + WriteThrottle = 처리 병목 2가지 【오답 체크】 (B) 재전송 정책은 처리 지연 해결 안 함, 실패 메시지 재시도만 함 (C) NumberOfMessagesSent는 전체 메시지 수 (지연 원인 불명확) (E) Throttles는 Lambda 동시성 한계, Lambda 시간 초과 증가는 불필요 【시험 포인트】 ▸ SQS + Lambda + DynamoDB 파이프라인 병목 진단 필수 ▸ ApproximateAgeOfOldestMessage = Lambda 처리 속도 지표 ▸ WriteThrottleEvents = DynamoDB 용량 부족 ▸ 두 메트릭 모두 확인하여 병목 지점 파악

해설

【핵심 용어】 ▸ ec2-instance-profile-attached — AWS Config 관리형 규칙 (EC2 인스턴스 프로필 검증) ▸ Configuration Changes Trigger — Config가 리소스 변경 시 규칙 자동 평가 ▸ Auto Remediation — 규정 비준수 리소스 자동 수정 ▸ EventBridge vs Config — EventBridge는 신규 이벤트만, Config는 기존 + 신규 모두 【정답 포인트】 ▸ 기존 + 신규 인스턴스 모두 대응 필요 → AWS Config 필수 ▸ ec2-instance-profile-attached는 정확한 관리형 규칙 ▸ 자동 수정으로 기본 인스턴스 프로필 연결 ▸ Config는 지속적 평가 (신규 인스턴스 자동 감지) 【오답 체크】 (A) EventBridge RunInstances는 신규 인스턴스만 감지, 기존 인스턴스 미포함 (C) EventBridge StartInstances는 재시작 이벤트만 감지, 신규 생성 이벤트 아님 (D) iam-role-managed-policy-check는 IAM 정책 검증, 인스턴스 프로필 검증 아님 【시험 포인트】 ▸ 기존 리소스 대응 → AWS Config 필수 ▸ 신규 리소스 대응 → EventBridge 가능 ▸ 둘 다 대응 → AWS Config + 자동 수정 ▸ Config 관리형 규칙: 리소스 유형별 사전 정의됨

해설

【핵심 용어】 ▸ AWS SAM — CloudFormation 기반 서버리스 배포 템플릿 ▸ Canary Deployment — 트래픽 10% → 메트릭 모니터링 → 100% 전환 ▸ CodeDeploy Deployment Preference — Lambda 배포 전략 (Linear, Canary, All-at-once) ▸ CloudWatch Alarms — 배포 실패 감지 및 자동 롤백 【정답 포인트】 ▸ SAM 템플릿 → CodeDeploy 통합 직접 지원 ▸ Canary10Percent15Minutes → 10% 트래픽으로 15분 모니터링 → 단계적 배포 ▸ CloudWatch 알람 → 메트릭 이상 감지 → 자동 롤백 ▸ 고객 영향 최소화 + 문제 감지 동시 충족 【오답 체크】 (B) 수동 승인 단계 → 자동 배포 전략 아님 (C) RoutingConfig는 Lambda Alias의 고급 기능이지만 CloudFormation 스택 레벨 배포 제어 불충분 (D) 프로덕션 별칭 수동 업데이트 → 자동화 부족, 단계적 배포 전략 없음 【시험 포인트】 ▸ 서버리스 배포: SAM + CodeDeploy + CloudWatch 조합 ▸ Canary 배포: 고객 영향 최소화의 표준 패턴 ▸ Lambda 배포 선호도: CodeDeploy가 SAM과 직접 통합 ▸ 롤백 자동화: CloudWatch 알람 필수

해설

【핵심 용어】 ▸ VPC Endpoint for S3 — 인터넷 게이트웨이 없이 S3 접근 (AWS 네트워크 내부) ▸ IAM Instance Profile — EC2가 S3 접근 권한 획득 ▸ Gateway Endpoint — S3/DynamoDB용 특별한 엔드포인트 (무료) ▸ No Internet Access — 인터넷 게이트웨이 및 NAT 미사용 【정답 포인트】 ▸ "인터넷 액세스 없음" → NAT 게이트웨이 사용 불가 (외부 IP) ▸ VPC Endpoint for S3 → AWS 네트워크 내부에서만 S3 접근 ▸ IAM 인스턴스 프로필 → EC2가 S3 버킷 읽기 권한 ▸ 사용자 데이터 스크립트: S3에서 아티팩트 다운로드 ▸ 보안 규칙 준수 + 인터넷 미사용 【오답 체크】 (A) "인터넷 액세스 없음" 정책 위반 (공개 IP = 인터넷 접근 경로) (B) NAT 게이트웨이 = 인터넷 게이트웨이 의존 → 인터넷 접근 불가 규칙 위반 (D) 보안 그룹은 아티팩트 저장소 정의 불가, 임시 규칙 추가는 부적절 【시험 포인트】 ▸ 인터넷 제한 환경 → VPC Endpoint 활용 ▸ Gateway Endpoint (S3): 비용 없음, Interface Endpoint보다 간단 ▸ IAM 인스턴스 프로필: EC2 권한 관리 표준 패턴

해설

【핵심 용어】 ▸ CodePipeline Trigger — 소스 저장소 변경을 감지하여 파이프라인 시작 ▸ EventBridge Rule — CodePipeline 트리거의 현대적 방식 (CloudWatch Events 대체) ▸ CodeCommit Push Event — main 브랜치 푸시 이벤트 【정답 포인트】 ▸ "파이프라인이 반응하지 않음" → 트리거 설정 문제 ▸ CodePipeline 트리거는 EventBridge 규칙으로 구성 ▸ main 브랜치 변경 이벤트 감지 필수 ▸ 푸시 자체는 성공 (코드 저장됨) → 권한 문제 아님 【오답 체크】 (B) CodePipeline 서비스 역할은 소스에서 읽기 권한 필요 (파이프라인 단계 내용) (C) 개발자 권한은 푸시 성공으로 이미 검증됨 (D) CloudWatch Logs의 CodeCommit 오류는 일반적이지 않음, EventBridge 규칙이 먼저 확인 대상 【시험 포인트】 ▸ 파이프라인 미트리거 → EventBridge 규칙 설정 확인 ▸ 소스 변경 감지 메커니즘: EventBridge (권장) 또는 CloudWatch Events (레거시) ▸ 특정 브랜치 필터링: 규칙의 event pattern에서 정의

해설

【핵심 용어】 ▸ EventBridge Event Pattern — 특정 리소스 유형 및 작업 필터링 ▸ Default Event Bus — AWS 서비스 이벤트를 수신하는 기본 버스 ▸ Near Real-time Detection — EC2 보안 그룹 이벤트 즉시 감지 ▸ Lambda Trigger — EventBridge 규칙이 Lambda 호출 【정답 포인트】 ▸ 실시간 감지 → EventBridge (CloudTrail 기반 이벤트) ▸ EC2 보안 그룹 생성/수정 → 특정 이벤트 패턴 정의 ▸ 기본 이벤트 버스 사용 (커스텀 불필요) ▸ EventBridge가 Lambda 직접 트리거 ▸ Lambda는 규칙 제거 + SNS 알림 수행 (이미 구현됨) 【오답 체크】 (A) CloudTrail은 감사 로그, 실시간 이벤트 소스 아님 (지연 발생) (B) 매시간 예약은 실시간 요구사항 미충족, 보안 그룹 변경 이벤트 감지 안 함 (D) 커스텀 이벤트 버스는 불필요, 기본 버스로 충분 【시험 포인트】 ▸ 실시간 감지: EventBridge + CloudTrail Events ▸ CloudTrail 기반 이벤트: API 호출 감지 (거의 실시간) ▸ 이벤트 패턴: 특정 리소스 유형/작업 필터링 ▸ 기본 버스: AWS 리소스 이벤트 자동 전송

해설

【핵심 용어】 ▸ Dualstack (IPv4 + IPv6) — ALB가 IPv4와 IPv6 모두 지원 ▸ IPv6 CIDR Block — VPC와 서브넷에 IPv6 주소 범위 할당 ▸ ALB vs NLB — ALB는 애플리케이션 레이어(HTTP/HTTPS), NLB는 전송 레이어 【정답 포인트】 ▸ ALB의 "Dualstack IP Address Type" 속성 → IPv4 + IPv6 동시 지원 ▸ VPC 및 서브넷에 IPv6 CIDR 블록 추가 필수 ▸ EC2 인스턴스: 프라이빗 서브넷에 위치 (IPv6 주소 할당 필요 없음) ▸ ALB 리스너: 포트 443 (HTTPS) 지정 ▸ 대상 그룹: EC2 인스턴스 포함 【오답 체크】 (A) EC2 인스턴스의 IPv6 주소 할당은 불필요 (ALB가 로드밸런싱 처리) (B) EC2 인스턴스에 IPv6 Elastic IP는 불필요 (프라이빗 서브넷) (C) NLB는 전송 레이어, 이 경우 ALB로 충분 (추가 복잡도) 【시험 포인트】 ▸ Dualstack ALB: IPv4와 IPv6를 동시에 지원 ▸ IPv6 CIDR 할당: VPC → 서브넷 계층 구조 필수 ▸ ALB IP address type 속성: "dualstack" 또는 "ipv4" ▸ 프라이빗 서브넷 EC2: 공개 IPv6 주소 불필요

해설

【핵심 용어】 ▸ Account Factory for Terraform (AFT) — Control Tower에서 Terraform 기반 계정 프로비저닝 ▸ Feature Flags — AFT 배포 구성에서 기능 활성화/비활성화 ▸ aft_feature_enterprise_support — Enterprise Support 플랜 자동 설정 플래그 ▸ AFT Deployment Configuration — AFT 동작 정의하는 핵심 설정 【정답 포인트】 ▸ AFT는 기능 플래그로 지원 플랜 설정 → aft_feature_enterprise_support = True ▸ AFT 배포 입력 구성 파일 수정 필수 ▸ 재배포 후 새 계정부터 Enterprise Support 자동 적용 ▸ 가장 직관적이고 AFT 표준 방식 【오답 체크】 (A) AWS Config는 규정 준수 감시, 지원 플랜 변경 기능 없음 (B) Lambda + Support API는 수동 승인 필요, 자동화 불충분 (C) control_tower_parameters는 지원 플랜 설정 기능 없음, AWSEnterpriseSupport 매개변수 존재하지 않음 【시험 포인트】 ▸ AFT 프로비저닝: 기능 플래그로 설정 (aft_feature_*) ▸ AFT 배포 구성 파일: 핵심 설정 위치 ▸ Enterprise Support: 새 계정 생성 시점에 설정 (사후 변경 복잡함) ▸ Control Tower + AFT 통합: 표준 멀티 계정 관리 패턴

해설

【핵심 용어】 ▸ AWS Health — 인프라 이벤트를 감지하여 알림 제공 ▸ EventBridge — AWS Health 이벤트를 캡처하여 Systems Manager 문서 실행 ▸ Systems Manager Document — 직접 작업 실행 가능 【정답 포인트】 ▸ AWS Health 이벤트 소스 필수 → 유지보수 알림 캡처 ▸ EC2 서비스 명시 → 특정 리소스 대상 지정 ▸ Systems Manager 문서 직접 대상 → 즉시 재시작 작업 실행 ▸ EventBridge → Systems Manager 직접 연동 지원 【오답 체크】 (B) Systems Manager를 이벤트 소스로는 사용하지 않음. 이미 발생한 유지보수 알림을 감지할 수 없음 (C) Lambda를 거칠 필요 없음. Systems Manager 문서가 직접 재시작 작업 수행 가능 (D) EC2를 이벤트 소스로 사용 불가. AWS Health에서만 유지보수 알림 발생 【시험 포인트】 EventBridge는 AWS Health 이벤트를 네이티브로 지원하며, 이를 통해 인프라 알림을 자동으로 처리할 수 있습니다. 간단한 재시작은 Lambda 추가 없이 Systems Manager 문서로 충분합니다.