정답 · 해설

해설

【핵심 용어】 ▸ S3 Cross-Account Replication — 다른 AWS 계정의 버킷 간 복제 ▸ Object Ownership — 복제된 객체의 소유권 설정(source vs destination) ▸ Access Denied — 권한 부족으로 인한 접근 거부 오류 【정답 포인트】 ▸ "Object Ownership" → Replication Configuration에서 소유권 변경 옵션 ▸ Cross-Account 문제 → 대상 계정 소유자가 객체에 접근 불가능 ▸ Access Denied 해결 → Destination 객체의 소유권을 대상 계정으로 이전 【오답 체크】 (B) Replication Rule 범위는 Access Denied와 직접 관련 없음 (C) S3 RTC는 복제 지연 시간 제어이며 권한 문제와 무관 (D) Storage Class 변경은 접근 거부 원인이 아님 【시험 포인트】 ▸ Cross-Account 권한 문제 → Object Ownership 설정으로 해결 ▸ Replication 구성 시 → "Change object ownership to the destination bucket owner" 옵션 필수 ▸ 복제 후 접근 불가 → 소유권 문제 의심

해설

【핵심 용어】 ▸ IAM Role vs IAM User — EC2에는 Role 사용(임시 자격증명) ▸ Least Privilege Principle — 필요한 최소 권한만 부여 ▸ Temporary Credentials — STS 자동 발급으로 안전성 향상 ▸ sqs:* — 모든 SQS 권한(과도한 권한 부여) 【정답 포인트】 ▸ "IAM Role" → EC2에 권장(자격증명 파일 불필요) ▸ "가장 안전" → Least Privilege(3개 권한만 지정) ▸ "적절한 대기열" → 특정 리소스에 제한된 권한 ▸ 임시 자격증명 → IAM Role 사용 시 자동 관리 【오답 체크】 (A) IAM User 자격증명을 애플리케이션 코드에 임베드하면 탈취 위험 높음 (B) Access Key/Secret을 환경 변수로 노출하면 보안 위험 발생 (C) sqs:* 권한은 Least Privilege 위반(DeleteQueue 등 불필요한 권한 포함) 【시험 포인트】 ▸ EC2 보안 → IAM Role 필수(임베드 자격증명 금지) ▸ SQS 권한 → 정확한 3개(SendMessage, ReceiveMessage, DeleteMessage) ▸ 리소스 제한 → ARN으로 특정 대기열만 지정

해설

【핵심 용어】 ▸ AWS Secrets Manager — DB 자격증명 자동 회전(credentials) ▸ AWS KMS — 암호화 키 관리(encryption keys) ▸ RDS Proxy — 연결 풀링으로 DB 연결 효율화 ▸ RDS Read Replica — 읽기 트래픽 분산(쓰기는 분산 불가) 【정답 포인트】 ▸ "자격증명 회전" → Secrets Manager(KMS는 암호화 키 용도) ▸ "Write-Intensive" → RDS Proxy(연결 풀링만으로 충분) ▸ "클라이언트 연결 증가" → RDS Proxy의 Connection Pooling 기능 ▸ "매월 회전" → Secrets Manager 자동 회전 기능 【오답 체크】 (A) KMS는 암호화 키 관리이며, 자격증명 회전 불가 (B) KMS 오류 + RDS Read Replica는 읽기만 분산(쓰기 연결은 증가) (D) Read Replica는 write-heavy 워크로드에서 연결 증가 해결 불가 【시험 포인트】 ▸ 자격증명 관리 → Secrets Manager(회전, 암호화 모두 지원) ▸ 데이터베이스 연결 폭주 → RDS Proxy(Connection Pooling) ▸ KMS vs Secrets Manager → KMS는 암호화, Secrets Manager는 자격증명

해설

【핵심 용어】 ▸ Route 53 Resolver — DNS 쿼리 해석 및 전달 서비스 ▸ Outbound Endpoint — VPC에서 온프레미스 DNS로의 쿼리 전달 ▸ Private Hosted Zone — AWS 내부용 DNS 영역 ▸ Direct Connect — 전용 네트워크 연결 【정답 포인트】 ▸ "온프레미스 DNS 이름 해석" → Resolver Outbound Endpoint(자동 전달) ▸ "가장 적은 유지보수" → 자동 DNS 전달(수동 호스트 파일 관리 불필요) ▸ "확장성" → Private Hosted Zone은 수천 개 호스트 관리 곤란 ▸ Direct Connect 활용 → 안전한 온프레미스 DNS 서버와의 통신 【오답 체크】 (A) Private Hosted Zone은 수동으로 모든 호스트를 입력해야 하며 관리 부담 증가 (C) 역방향 DNS는 이 요구 사항과 무관 (D) /etc/hosts 파일은 각 인스턴스마다 수동 관리 필요(확장성 없음) 【시험 포인트】 ▸ 온프레미스 DNS 통합 → Route 53 Resolver Outbound Endpoint 최적 ▸ 자동 전달 규칙 → Conditional Forwarding(도메인별 DNS 서버 지정) ▸ 관리 효율 → 일괄 설정으로 모든 EC2 인스턴스에 적용

해설

【핵심 용어】 ▸ CloudWatch Logs Metric Filter — 로그에서 메트릭 추출(자동화) ▸ CloudWatch Logs Subscription Filter — 다른 대상으로 로그 스트리밍 ▸ CloudWatch Logs Insights — 임시 쿼리(실시간 모니터링 부적합) ▸ HTTP 404 — 찾을 수 없음(모니터링 대상) 【정답 포인트】 ▸ "모니터링" → 지속적 추적 필요(Metric Filter 최적) ▸ "가장 운영 효율적" → 자동 메트릭 생성(Lambda 관리 불필요) ▸ "CloudWatch Logs Metric Filter" → 로그 패턴 매칭으로 메트릭 자동 생성 ▸ "알람 설정 가능" → 메트릭 기반 CloudWatch Alarm 생성 가능 【오답 체크】 (B) Subscription Filter는 로그를 다른 곳으로 전달(메트릭 생성 불가) (C) Lambda 함수는 추가 코드 작성 및 관리 부담 발생 (D) 스크립트는 수동 실행 필요(자동화 없음) 【시험 포인트】 ▸ 지속적 모니터링 → Metric Filter(자동 메트릭 생성) ▸ 로그 분석 → Insights는 임시 쿼리용(모니터링 용도 부적합) ▸ 알람 연계 → 메트릭 필터로 생성한 메트릭에 CloudWatch Alarm 설정 가능

해설

【핵심 용어】 ▸ Availability Zone(AZ) — AWS 데이터센터 단위(단일 장애점 방지) ▸ Multi-AZ 배포 — 고가용성의 기본(같은 Region 내 AZ 분산) ▸ Auto Scaling Group — 인스턴스 개수 자동 조정 ▸ 고가용성 — 한 AZ의 장애에도 서비스 지속 가능 【정답 포인트】 ▸ "고가용성" → 다중 AZ 필수(단일 AZ는 단일 장애점) ▸ "같은 Region" → AZ 간 지연시간 최소, 추가 비용 없음 ▸ "Auto Scaling Group" → AZ 목록 추가로 자동 분산 ▸ "Multi-AZ" → 한 AZ 장애 시에도 다른 AZ에서 서비스 지속 【오답 체크】 (A) 최대값 증가는 용량만 증가(AZ 분산과 무관) (B) 최소값 증가도 단일 AZ 문제 해결 불가 (D) 다른 Region은 비용 증가 및 지연시간 악화(Cross-Region) 【시험 포인트】 ▸ 고가용성 = Multi-AZ(같은 Region 내 분산) ▸ Auto Scaling Group 설정 → AvailabilityZones에 여러 AZ 추가 ▸ ALB는 여러 AZ의 인스턴스 자동 감지(별도 설정 불필요)

해설

【핵심 용어】 ▸ Security Group — Stateful(아웃바운드 자동 허용) ▸ Network ACL — Stateless(양방향 규칙 필수) ▸ Ephemeral Port — 클라이언트 요청의 반환 포트(1024~65535) ▸ Stateful vs Stateless — 응답 트래픽 자동 허용 여부 【정답 포인트】 ▸ "Network ACL Stateless" → 요청(inbound 80)과 응답(outbound ephemeral) 모두 필요 ▸ "Ephemeral Port" → 클라이언트가 사용하는 임시 포트(1024~65535) ▸ "아웃바운드 규칙" → Network ACL에서 필수(Security Group과 다름) ▸ 문제 원인 → 응답 패킷이 Network ACL 아웃바운드에 차단됨 【오답 체크】 (B) Security Group은 Stateful이므로 아웃바운드 규칙 없어도 응답 자동 허용 (C) Elastic IP는 할당 후 변경 없음(이 요구사항에서) (D) 새로운 Network ACL이 적용되었으므로 추가 ACL 불가능 【시험 포인트】 ▸ Security Group 아웃바운드 → 기본값: 모든 트래픽 허용(규칙 불필요) ▸ Network ACL 아웃바운드 → 명시적 규칙 필요(인바운드만으로 불충분) ▸ Stateless 네트워크 필터링 → 양방향 규칙 설정 필수

해설

【핵심 용어】 ▸ Systems Manager Fleet Manager — EC2 인스턴스 중앙 관리 ▸ SSM Agent — Systems Manager와 통신하는 EC2 에이전트 ▸ AmazonSSMManagedInstanceCore — 필수 IAM Policy ▸ VPC Endpoint vs IAM Policy — 네트워크 연결 vs 권한 문제 【정답 포인트】 ▸ "Fleet Manager에 나타나지 않음" → 권한 부족(IAM Policy 필요) ▸ "AmazonSSMManagedInstanceCore" → Systems Manager 통신에 필수 Policy ▸ "Instance Profile" → EC2에 IAM Role을 통해 권한 부여 ▸ "NAT Gateway 이미 있음" → 네트워크 연결은 정상 【오답 체크】 (A) NAT Gateway는 이미 작동(Network 문제 아님) (B) VPC Endpoint는 네트워크 선택사항(권한 문제가 아님) (D) ssm:* 권한은 Least Privilege 위반(AmazonSSMManagedInstanceCore 사용) 【시험 포인트】 ▸ Systems Manager 접근 불가 → IAM Policy 확인(권한 문제) ▸ Fleet Manager 인스턴스 미표시 → AmazonSSMManagedInstanceCore Policy 필수 ▸ Instance Profile 연결 → AssumeRole Trust Policy에 EC2 서비스 포함 확인

해설

【핵심 용어】 ▸ Message Priority — 메시지 우선순위 처리 ▸ FIFO Queue — 순서 보장(우선순위 X) ▸ Standard Queue — 처리 순서 보장 불가 ▸ SQS 우선순위 패턴 — 여러 대기열 분리 【정답 포인트】 ▸ "알람 알림 우선" → 별도 대기열 사용 ▸ "정보 알림은 나중" → 별도 대기열에서 순차 처리 ▸ "애플리케이션 로직" → 알람 대기열을 먼저 확인(poll) ▸ "우선순위 구현" → SQS의 기본 방식(MessageGroupId X) 【오답 체크】 (A) Auto Scaling은 용량만 증가(우선순위 처리 불가) (B) SNS fanout은 병렬 분배(우선순위 적용 불가) (C) DynamoDB Stream은 메시지 우선순위 처리 불가 【시험 포인트】 ▸ SQS 우선순위 → SQS 자체 미지원(애플리케이션 로직 필요) ▸ 다중 대기열 패턴 → 알람/정보 별 대기열 분리 ▸ Consumer 로직 → 우선 대기열을 먼저 poll하고 빈 경우 다음 대기열 처리

해설

【핵심 용어】 ▸ AWS Trusted Advisor — AWS 계정 최적화 권장 사항 도구 ▸ Support Plan Tiers — Basic(무료), Developer, Business, Enterprise ▸ Check 개수 제한 — Support Plan에 따라 다름 ▸ Core Checks vs Full Checks — 제한된 vs 전체 검사 【정답 포인트】 ▸ "Trusted Advisor 검사 개수" → Support Plan의 등급 ▸ Basic Plan → 6개 Core Check만 지원 ▸ Business/Enterprise → 전체 검사(100+) 지원 ▸ Developer Plan → Basic과 동일(6개) 【오답 체크】 (A) EC2 인스턴스 실행 여부는 Trusted Advisor 검사 개수와 무관 (C) SCP는 IAM 정책(Trusted Advisor 검사 개수와 무관) (D) MFA 설정은 Trusted Advisor 검사 개수와 무관 【시험 포인트】 ▸ Trusted Advisor 제약 → Support Plan(유료 플랜일수록 많은 검사) ▸ Core vs Full → Free/Developer: 6 Core, Business/Enterprise: 전체 ▸ 리프레시 빈도 → Support Plan에 따라 수동/자동 차이

해설

【핵심 용어】 ▸ CloudFormation StackSets — 다중 계정/Region 배포 자동화 ▸ OrganizationAccountAccessRole — Organizations 관리 역할 ▸ Lambda 기반 배포 — 수동 코딩 필요 ▸ 운영 오버헤드 — 관리 부담 【정답 포인트】 ▸ "다중 계정 배포" → CloudFormation StackSets(자동화) ▸ "가장 적은 오버헤드" → StackSets가 자동 관리 ▸ "AWS Organizations 통합" → StackSets는 Organizations 지원 ▸ "일괄 배포" → 한 번의 설정으로 모든 계정에 자동 배포 【오답 체크】 (A) OrganizationAccountAccessRole 수동 가정(각 계정마다 반복) (B) Lambda 함수 작성 및 관리 필요(복잡성 증가) (C) Lambda 함수로 계정 조회 후 배포(자동화 수준 낮음) 【시험 포인트】 ▸ StackSets = CloudFormation 다중 배포의 표준 솔루션 ▸ Organizations 통합 → StackSet Service-Managed 권한 ▸ 자동 업데이트 → StackSet 수정 시 모든 계정에 반영

해설

【핵심 용어】 ▸ CNAME Record — 도메인 이름을 다른 도메인 이름으로 별칭 지정 ▸ A Record — 도메인을 IPv4 주소로 매핑 ▸ Alias Record — AWS Route 53 고유 기능(AWS 리소스만) ▸ PTR Record — 역방향 DNS(IP → 도메인) 【정답 포인트】 ▸ "www.company.com → app.example.com" → CNAME 동작 ▸ "외부 공급자 호스팅" → AWS 리소스 아님(Alias 불가) ▸ "도메인 별칭" → CNAME이 정확한 용도 ▸ "Route 53에서 관리" → CNAME 생성 지원 【오답 체크】 (A) A Record는 IPv4 주소 필요(도메인 주소는 모름) (B) Alias Record는 AWS 리소스만 지원(외부 호스팅 불가) (D) PTR Record는 역방향 조회용(이 목적에 부적합) 【시험 포인트】 ▸ 도메인 → 도메인 매핑 = CNAME ▸ 도메인 → IP 주소 = A Record ▸ Alias는 AWS 리소스 전용(CloudFront, ALB, S3 등) ▸ 외부 호스팅 서비스 → CNAME만 가능

해설

【핵심 용어】 ▸ ElastiCache Multi-AZ — 자동 Failover 지원 ▸ Read Replica — 데이터 복제본(읽기 전용) ▸ RTO(Recovery Time Objective) — 복구 시간 ▸ Memcached vs Redis — Memcached는 persistence 미지원 【정답 포인트】 ▸ "복원력 증가" → Multi-AZ 활성화(자동 Failover) ▸ "RTO 최소화" → 즉시 Failover(백업 복구보다 빠름) ▸ "Redis OSS Multi-AZ" → 한 AZ 장애 시 다른 AZ로 자동 전환 ▸ "Read Replica" → 데이터 이중화와 성능 향상 【오답 체크】 (A) Memcached는 persistence 미지원(메모리 캐시만) (B) 백업 복원은 RTO가 높음(자동 Failover보다 느림) (D) 백업 복원도 RTO가 높음(Multi-AZ 자동 Failover가 더 빠름) 【시험 포인트】 ▸ 고가용성 = Multi-AZ(RTO 최소) ▸ 백업은 보조 수단(RTO는 길어짐) ▸ ElastiCache Redis Multi-AZ → 자동 Failover(클러스터 모드 필수) ▸ Memcached는 무상태(persistence/replication 미지원)

해설

【핵심 용어】 ▸ CloudFormation Stack Drift — 배포 후 예기치 않은 변경 감지 ▸ Drift Detection — 현재 상태와 Template 비교 ▸ EventBridge Rule — 이벤트 기반 자동화 ▸ CloudTrail vs Drift Detection — 감사 로그 vs 상태 비교 【정답 포인트】 ▸ "배포 후 변경 감지" → CloudFormation Drift Detection 최적 ▸ "자동 알림" → EventBridge Rule + Lambda + SNS ▸ "가장 적은 관리" → CloudFormation 자체 기능(별도 비교 로직 불필요) ▸ "Policy 변경 감지" → Drift Detection은 정확한 상태 비교 【오답 체크】 (A) CloudTrail은 감사 로그(변경 감지는 되지만 자동 알림 미지원) (C) Access Analyzer는 Policy 생성용(비교 목적과 다름) (D) 수동 JSON 비교는 관리 부담 높음 【시험 포인트】 ▸ Stack Drift = CloudFormation의 표준 변경 감지 기능 ▸ Drift Detection 실행 → EventBridge + Lambda로 자동화 ▸ Template과 실제 상태 비교 → 가장 정확한 변경 감지 ▸ 최소 관리 = AWS 관리형 서비스 활용

해설

【핵심 용어】 ▸ Interface VPC Endpoint(PrivateLink) — AWS 서비스를 VPC 내부에서 접근 ▸ Gateway VPC Endpoint — S3/DynamoDB용 엔드포인트(인터페이스 X) ▸ NAT Gateway — 인터넷 게이트웨이(VPC 외부로 나감) ▸ PrivateLink — VPC와 AWS 서비스 간 보안 연결 【정답 포인트】 ▸ "모든 통신 VPC 내" → Interface VPC Endpoint(PrivateLink) ▸ "QuickSight 접근" → PrivateLink Interface Endpoint ▸ "S3 데이터 접근" → S3 Gateway Endpoint(별도) + IAM Policy ▸ "보안성" → VPC 외부 인터넷 미경유 【오답 체크】 (B) EC2 프록시는 추가 관리 부담 및 복잡성 증가 (C) S3 Gateway Endpoint만으로는 QuickSight 접근 불가(QuickSight 엔드포인트 필요) (D) NAT Gateway는 인터넷으로 나감("VPC 경계 내"에 위배) 【시험 포인트】 ▸ AWS 서비스 접근 → Interface VPC Endpoint(PrivateLink 기반) ▸ S3 접근 → Gateway Endpoint(별도 구성 가능) ▸ "VPC 경계 내" = VPC Endpoint 사용(인터넷 미경유) ▸ QuickSight + S3 = Interface Endpoint(QuickSight) + Manifest + IAM

해설

【핵심 용어】 ▸ Amazon FSx for Windows File Server — SMB/NFS 지원 관리형 파일 시스템 ▸ Multi-AZ — 자동 Failover(높은 가용성) ▸ AWS Storage Gateway — 온프레미스 연결용 게이트웨이 ▸ DFSR — 수동 파일 동기화(관리 부담) 【정답 포인트】 ▸ "Availability Zone 장애 견디기" → Multi-AZ 지원 필수 ▸ "SMB 프로토콜" → FSx for Windows File Server(Storage Gateway도 지원하지만) ▸ "Windows ACL" → FSx가 기본 지원(완벽한 호환성) ▸ "자동 Failover" → FSx Multi-AZ 【오답 체크】 (A) 단일 Storage Gateway는 단일 AZ(고가용성 미지원) (C) Storage Gateway ALB 구성은 복잡하고 DFSR 등 수동 관리 필요 (D) Single-AZ 2개 + DFSR은 수동 동기화(관리 부담 높음) 【시험 포인트】 ▸ Windows 파일 서버 마이그레이션 → FSx for Windows(최적 솔루션) ▸ Multi-AZ = 자동 고가용성 및 자동 백업 ▸ SMB + Windows ACL = FSx의 기본 기능 ▸ Storage Gateway는 주로 온프레미스 캐싱용

해설

【핵심 용어】 ▸ CloudWatch Agent procstat Plugin — 프로세스별 CPU 메트릭 수집 ▸ Metric — CloudWatch에 저장된 시계열 데이터 ▸ CloudWatch CPU 메트릭 — 인스턴스 전체 CPU(PID 정보 없음) ▸ Lambda — 이벤트 기반 실행(지속적 모니터링 어려움) 【정답 포인트】 ▸ "PID 식별" → procstat Plugin(프로세스 레벨 메트릭) ▸ "가장 적은 노력" → 자동화된 메트릭 수집 ▸ "CloudWatch Agent" → 에이전트가 자동 수집 및 메트릭 저장 ▸ "지속적 모니터링" → procstat는 주기적 데이터 수집 【오답 체크】 (B) Lambda는 1분 간격 실행 시 비용 증가(비효율) (C) 수동 로그인은 장애 발생 후 대응(사후 조치) (D) 기본 CPU 메트릭은 인스턴스 전체 CPU(PID 정보 없음) 【시험 포인트】 ▸ 프로세스 메트릭 = CloudWatch Agent procstat Plugin ▸ 자동 수집 = CloudWatch Agent 데몬(항상 실행) ▸ 인스턴스 레벨 vs 프로세스 레벨 메트릭 구분 ▸ 사전 모니터링(proactive) vs 사후 조사(reactive)

해설

【핵심 용어】 ▸ CloudWatch Synthetics Canary — 합성 모니터링(사용자 경험 시뮬레이션) ▸ Heartbeat Monitoring — 기본 가용성 확인(엔드포인트 응답) ▸ Broken Link Checker — 링크 유효성 검사(전체 가용성 X) ▸ SuccessPercent — 성공률 메트릭(99% 기준) 【정답 포인트】 ▸ "최종 사용자 경험" → Synthetics Canary(실제 사용자 관점) ▸ "99% 업시간" → SuccessPercent 메트릭 모니터링 ▸ "Heartbeat Monitoring" → 기본 HTTP 응답 확인(가장 적합) ▸ "정확한 보기" → 실제 사용자 행동 시뮬레이션 【오답 체크】 (A) 로그 분석은 이미 발생한 오류(사전 모니터링 X) (B) CloudWatch 메트릭은 애플리케이션 내부 메트릭(사용자 경험과 다름) (D) Broken Link Checker는 링크 검사(전체 가용성 미포함) 【시험 포인트】 ▸ 사용자 경험 모니터링 = CloudWatch Synthetics(최적) ▸ Heartbeat vs Broken Link → Heartbeat가 기본 가용성(가장 적합) ▸ Canary = 일정 간격으로 웹사이트 접근 및 메트릭 수집 ▸ SuccessPercent = 성공한 Canary 실행 비율

해설

【핵심 용어】 ▸ NAT Gateway — Private subnet의 리소스가 인터넷과 통신하기 위한 관리형 서비스 ▸ Route Table — 서브넷의 트래픽을 어느 목적지로 라우팅할지 정의 ▸ Private Subnet — 인터넷 직접 접근 불가, NAT를 통해 아웃바운드 연결만 가능 【정답 포인트】 ▸ "Route table 업데이트"→Private subnet의 route table에서 0.0.0.0/0을 NAT gateway로 대상 지정 ▸ 여러 AZ의 인스턴스가 NAT gateway에 도달하려면 각 AZ의 route table이 해당 AZ의 NAT gateway를 가리켜야 함 ▸ NAT gateway는 이미 존재하므로 추가 설정 불필요 【오답 체크】 (A) NAT instance로 변경 — 수동 관리 필요, 가용성 떨어짐, 관리 오버헤드 증가 (C) Internet Gateway 사용 — Private subnet은 IGW에 직접 연결 불가, public IP 필요 (D) 보조 IP 추가 — NAT gateway 용량 문제 아님, IP 주소 추가해도 라우팅 문제 해결 안 됨 【시험 포인트】 ▸ NAT gateway의 기본 개념: 수평적 확장 불가, 각 AZ당 1개 권장 ▸ Private subnet → NAT gateway 연결은 route table을 통해서만 가능 ▸ 인프라 최적화 후 route table 미업데이트가 근본 원인

해설

【핵심 용어】 ▸ DeletionPolicy — CloudFormation stack 삭제 시 리소스의 동작 정의 ▸ Retain — 리소스를 stack에서 제거하지만 물리적으로는 유지 ▸ Snapshot — 특정 시점의 EBS 볼륨 복사본 【정답 포인트】 ▸ "인스턴스와 모든 데이터 유지"→DeletionPolicy: Retain 사용 ▸ Retain은 EC2 인스턴스와 연결된 EBS 볼륨(데이터) 모두를 보존 ▸ Stack 삭제 후에도 인스턴스가 실행 상태로 남아 언제든 접근 가능 【오답 체크】 (A) Snapshot으로 설정 — 스냅샷 생성만 하고 인스턴스는 삭제됨, "인스턴스 유지" 요구사항 미충족 (B) Amazon DLM — 자동 백업 관리용, 명시적 데이터 보존 보장 안 함 (C) AWS Backup — 선택사항, DeletionPolicy가 더 간단하고 직접적 【시험 포인트】 ▸ DeletionPolicy의 세 가지 주요 값: Delete(기본), Retain, Snapshot ▸ Retain은 "인스턴스는 남지만 stack에서 관리 해제"를 의미 ▸ 스냅샷 (A)과 Retain (D)의 차이 이해 필수