정답 · 해설

해설

【핵심 용어】 ▸ AWS Config: 구성 규정 준수 모니터링 및 자동 수정. S3 Public Access Block: S3 공용 접근 차단 기능. Automatic Remediation: 비준수 설정 자동 해결. 【정답 포인트】 ▸ A: AWS Config는 s3-bucket-public-read-prohibited, s3-bucket-public-write-prohibited 관리 규칙 제공 → 공용 권한 자동 감지. AWS Systems Manager Automation과 연계하여 자동 수정(PublicAccessBlockConfiguration 적용) → 운영 오버헤드 최소화. 정책 준수 완벽 자동화. 【오답 체크】 ▸ (B) Security Hub: 보안 이슈 집계 및 대시보드 → 자동 수정 기능 미제공(식별만). (C) Trusted Advisor: 주간 실행 권장사항 → 실시간 규정 준수/자동 수정 미제공. (D) Inspector: 취약점 스캔 → S3 권한 정책 검사 미전문. 【시험 포인트】 ▸ AWS Config의 s3-bucket-public 관련 규칙들은 S3 보안의 기본. Automatic Remediation 설정으로 감지 즉시 적용 → 거버넌스 자동화. 규정 준수 조직 필수 구성. CloudTrail과 함께 사용하면 누가 변경했는지도 추적 가능.

해설

【핵심 용어】 ▸ IAM Policy Evaluation: Allow/Deny 문장 기반 권한 평가. Action 필드: 정책이 허용하는 API 작업 나열. Resource: 정책 적용 대상 리소스(* = 모든 리소스). 【정답 포인트】 ▸ 이 문제는 정책 내용 제시 필요하나, 일반적인 AWS 정책 평가 원칙: Action 배열에 있는 작업만 허용 → Describe* 권한(읽기 전용)으로 로드 밸런서 설명 가능. Invoke* 권한(Lambda 실행)으로 함수 호출 가능. Create/Delete 작업은 Action 미포함 → 거부. 정책이 'elasticloadbalancing:Describe*'와 'lambda:Invoke*' 포함 시 답변은 D, E. 【오답 체크】 ▸ (A) Storage Gateway 생성 = CreateStorageGateway → Create* 권한 필요(일반적 정책 미포함). (B) Lambda 역할 생성 = CreateRole(IAM) → Lambda만의 정책으로 미포함. (C) SQS 삭제 = DeleteQueue → Delete 권한 필요(일반적 정책 미포함). 【시험 포인트】 ▸ IAM 정책 평가: Action 배열 기반 판단 → 나열된 작업만 허용. Describe/List/Get = 읽기, Create/Update = 쓰기, Delete = 삭제. 와일드카드(*) 사용은 주의 → 광범위 권한 부여. 정책 제시 없이 판단 시 Action 유형별 분류 필수.

해설

【핵심 용어】 ▸ Lambda VPC Connectivity: Lambda를 VPC에 연결하여 프라이빗 리소스 접근. PrivateLink Interface Endpoint: AWS 서비스 접근용 프라이빗 연결. Database Private Endpoint: VPC 내부 프라이빗 연결 주소. 【정답 포인트】 ▸ B: Lambda 함수를 데이터베이스의 VPC에 연결(VPC 설정) → Lambda는 VPC 내부 보안 그룹/네트워크를 통해 프라이빗 엔드포인트 접근 가능. 프라이빗 엔드포인트 사용으로 공용 인터넷 우회 → 보안 유지. 간단하고 안전한 솔루션. 【오답 체크】 ▸ (A) PrivateLink는 AWS 서비스(S3, DynamoDB 등) 접근용 → 데이터베이스 접근 용도 미적합. Interface Endpoint 불필요. (C) IAM 역할은 데이터베이스 네트워크 접근성 미제공 → 연결 자체 불가. (D) 공용 서브넷 복귀 = 보안 손상 → 요구사항 위반. 【시험 포인트】 ▸ Lambda의 VPC 연결은 필수 설정(인스턴스 유형 선택 시 고려) → VPC 내 ENI 할당 필요 → 약간의 시작 지연 발생. RDS 프라이빗 엔드포인트는 VPC 내에서만 접근 가능(기본값) → Lambda VPC 연결 필수. 데이터베이스 보안 그룹도 Lambda 보안 그룹 트래픽 허용 설정 필요.

해설

【핵심 용어】 ▸ Cookie Forwarding(쿠키 전달): CloudFront가 원본 서버로 쿠키 전송. Session Affinity Cookie: ALB의 기간/애플리케이션 기반 세션 고정 쿠키. CloudFront Cache Behavior: 캐시 정책 및 쿠키 처리 규칙. 【정답 포인트】 ▸ B: CloudFront는 기본 쿠키 미전달(캐시 키에 포함 안 함) → 세션 쿠키 손실 → 매 요청마다 새로운 인스턴스 라우팅 → 강제 로그아웃. 캐시 동작에서 'Forward Cookies' 설정하여 All 또는 특정 쿠키(AWSALB, 애플리케이션 쿠키) 전달 → 세션 유지. E: 애플리케이션 기반 쿠키로 변경하면 ALB가 애플리케이션이 제공하는 쿠키 인식 → 더 정확한 세션 추적(기간 기반보다 안정적). 【오답 체크】 ▸ (A) 로드 밸런싱 알고리즘 변경은 쿠키 전달 문제 미해결. (C) 쿠키 이름 지정은 선택적 → 근본 원인인 CloudFront 전달 문제 미해결. (D) 만료 쿠키 헤더는 기존 기간 기반 쿠키와 중복/혼동 가능. 【시험 포인트】 ▸ CloudFront + ALB + Stateful App의 전형적 시험 주제. CloudFront 기본 동작은 쿠키 무시 → 명시적 전달 설정 필수. 애플리케이션 쿠키가 중요하면 TargetGroupStickinessConfig에서 ApplicationBasedCookie 선택. 세션 유지 + CloudFront 캐싱 = 쿠키 전달 필수.

해설

【핵심 용어】 ▸ Route 53 지리적 위치(Geolocation) 라우팅 - 사용자의 지리적 위치를 기반으로 트래픽을 라우팅하는 정책. 데이터 상주 요건이 있을 때 특정 리전으로만 요청을 보낼 수 있습니다. 【정답 포인트】 ▸ 데이터 상주 요건(Data Residency Requirements)이 명시되어 있고 사용자의 '위치(location)'를 기반으로 라우팅해야 하므로 Geolocation 정책이 정답입니다. Geolocation 라우팅은 사용자의 지리적 위치를 감지하여 특정 리전으로만 트래픽을 제한할 수 있습니다. 【오답 체크】 ▸ (A) Latency 정책은 최저 지연 시간을 기준으로 라우팅하며 특정 리전 제한을 보장하지 않습니다. (B) Multivalue 정책은 여러 IP를 반환하며 위치 기반 제한이 없습니다. (D) IP 기반 라우팅은 개별 IP를 등록해야 하므로 확장성이 떨어집니다. 【시험 포인트】 ▸ 데이터 상주 요건이 있을 때는 Route 53 Geolocation 라우팅을 사용합니다. Latency와 Geolocation의 차이를 명확히 이해해야 합니다. Latency는 성능 최적화, Geolocation은 위치 제한입니다.

해설

【핵심 용어】 ▸ FSR(Fast Snapshot Restore) - EBS 스냅샷 복원 시 전체 초기화(initialize) 없이 즉시 전체 성능을 제공하는 기능. Spot Instance 기반의 자동 시작/중지 워크로드에 최적화됩니다. 【정답 포인트】 ▸ EBS 스냅샷에서 복원된 볼륨의 초기 성능 문제는 Lazy Loading으로 인한 것입니다. FSR을 사용하면 복원 직후부터 전체 IOPS 성능을 즉시 얻을 수 있어, 스냅샷에서 복원된 직후 워크로드를 바로 처리할 수 있습니다. 【오답 체크】 ▸ (B) 암호화 상태 변경은 성능 문제의 근본 해결책이 아닙니다. (C) 파일 시스템 포맷은 EBS 성능에 영향을 주지 않습니다. (D) read-ahead 버퍼 설정은 제한적이고 Lazy Loading 문제를 해결하지 못합니다. 【시험 포인트】 ▸ EBS 스냅샷 복원 후 성능 저하 → FSR 사용. Lazy Loading 개념과 FSR의 차이를 이해해야 합니다. SysOps 시험에서 자주 출제되는 EBS 최적화 주제입니다.

해설

【핵심 용어】 ▸ High Availability (HA) - 애플리케이션과 데이터베이스가 여러 가용 영역에 걸쳐 분산 배포되어야 함. Multi-AZ, Auto Scaling, Load Balancer가 필수 구성 요소. 【정답 포인트】 ▸ 고가용성을 위해서는: (1) RDS Multi-AZ로 데이터베이스 자동 페일오버, (2) Auto Scaling으로 애플리케이션 수평 확장, (3) Load Balancer로 트래픽 분산. 이 세 가지 모두 필요합니다. 옵션 A는 모든 요구 사항을 충족합니다. 【오답 체크】 ▸ (B) Lambda Multi-AZ 옵션은 존재하지 않으며 Lambda는 이미 관리형 다중 AZ 서비스입니다. (C) 매분 상태 확인은 RPO/RTO 목표를 맞추기 어렵고 관리 복잡도가 높습니다. (D) 대기 데이터베이스는 수동 페일오버가 필요하며 자동화되지 않습니다. 【시험 포인트】 ▸ 프로덕션 HA 요구 사항 → RDS Multi-AZ + Auto Scaling + Load Balancer 조합을 항상 생각하세요. Lambda Multi-AZ, 수동 페일오버 등은 올바른 HA 솔루션이 아닙니다.

해설

【핵심 용어】 ▸ Managed Instance Activation - 온프레미스 서버를 Systems Manager에 등록하는 메커니즘. 장기 자격 증명 대신 일회성 활성화 코드/ID를 사용합니다. SSM Agent 필수. 【정답 포인트】 ▸ 요구 사항은 '장기 자격 증명 미사용'입니다. Managed Instance Activation을 사용하면 활성화 코드(activation code)와 ID(activation ID)만으로 SSM에 등록 가능하며, 이후 AWS Systems Manager가 자동으로 에이전트를 관리합니다. 이것이 유일한 안전한 방법입니다. 【오답 체크】 ▸ (A) IAM 역할은 EC2에만 적용되며 온프레미스 서버에 연결 불가. (C) 정책 다운로드는 보안이 취약하고 작동하지 않습니다. (D) IAM 사용자와 액세스 키는 장기 자격 증명이므로 요구 사항 위반입니다. 【시험 포인트】 ▸ 온프레미스 + Systems Manager = Managed Instance Activation. 액세스 키 생성은 절대 안 됩니다. SSM Agent 설치와 Activation Code/ID의 역할을 이해해야 합니다.

해설

【핵심 용어】 ▸ EFS (Elastic File System) - 여러 EC2 인스턴스가 동시에 마운트 가능한 관리형 NFS 파일 시스템. 데이터 일관성과 공유를 보장합니다. Auto Scaling과 완벽하게 호환됩니다. 【정답 포인트】 ▸ '모든 EC2 인스턴스가 동일한 파일을 공유'하고 '데이터 일관성 보장'이 필수 요건입니다. EFS는 이러한 요구 사항을 위해 설계된 AWS 서비스입니다. 시작 템플릿의 사용자 데이터에서 EFS 마운트를 구성하면 Auto Scaling 그룹의 모든 인스턴스가 자동으로 같은 파일을 공유합니다. 【오답 체크】 ▸ (B) EBS Multi-Attach는 최대 16개 인스턴스만 지원하고 프로토콜 수준에서 일관성 관리가 필요하며 복잡합니다. (C) Cron 동기화는 결국 일관성 문제를 초래하고 관리 오버헤드가 높습니다. (D) 시작 템플릿에서 EFS를 생성하면 안 되며, EFS는 사전에 생성되어야 합니다. 【시험 포인트】 ▸ 여러 EC2 인스턴스의 파일 공유 → EFS. EBS Multi-Attach는 특수한 경우에만 사용. 시작 템플릿은 마운트만 수행하고 EFS 생성은 별도로 수행해야 합니다.

해설

【핵심 용어】 ▸ CloudFormation StackSet - 여러 AWS 계정과 리전에 CloudFormation 스택을 동시에 배포 및 관리하는 도구. 중앙 집중식 관리와 동일 업데이트를 가능하게 합니다. 【정답 포인트】 ▸ '50개 계정에 동일 VPC 배포' + '향후 모든 변경을 모든 VPC에 적용'은 StackSet의 정확한 사용 사례입니다. StackSet을 사용하면 한 번의 템플릿 업데이트로 모든 계정의 스택이 자동으로 업데이트됩니다. 운영상 효율성이 가장 높습니다. 【오답 체크】 ▸ (A) 각 계정별로 수동 로그인하여 스택을 생성해야 하므로 50회 반복 작업 필요. (B) 쉘 스크립트는 크로스 계정 권한 설정이 복잡하고 관리가 어렵습니다. (C) Lambda와 DynamoDB 솔루션은 과도하게 복잡하고 중앙 관리가 어렵습니다. 【시험 포인트】 ▸ 다중 계정 + 동일 배포 = StackSet. 수동 배포, 스크립트 기반, Lambda 기반은 확장성과 관리성이 낮습니다. StackSet은 'Stack Instance'로 각 계정의 스택을 관리합니다.

해설

【핵심 용어】 ▸ Network ACL (Access Control List) - VPC 서브넷 수준에서 작동하는 상태 비저장(stateless) 방화벽. 보안 그룹과 달리 명시적 거부 규칙으로 트래픽을 차단할 수 있습니다. 【정답 포인트】 ▸ VPC 플로우 로그에서 연결 실패를 보면 REJECT 상태를 확인합니다. 보안 그룹은 상태 저장이므로 응답 트래픽을 자동으로 허용하지만, Network ACL은 상태 비저장이므로 응답 트래픽도 명시적으로 허용해야 합니다. HTTPS(포트 443) 차단은 Network ACL 설정 오류일 가능성이 높습니다. 【오답 체크】 ▸ (A) 보안 그룹 거부는 VPC 플로우 로그에서 특이한 패턴을 보입니다. (B) 인스턴스 종료 시 RST 또는 다른 패턴이 나타납니다. (D) IGW 미연결은 공인 IP 문제이지 443 포트 차단과 무관합니다. 【시험 포인트】 ▸ 보안 그룹은 상태 저장, Network ACL은 상태 비저장. 비대칭 트래픽(요청 OK, 응답 BLOCK) → Network ACL. HTTPS 포트 차단 → Network ACL 확인이 우선입니다.

해설

【핵심 용어】 ▸ ConsumedReadCapacityUnits - DynamoDB가 실제로 소비한 읽기 용량 단위를 측정하는 CloudWatch 메트릭. 프로비저닝된 용량에 도달하기 전에 조기 경고를 설정할 수 있습니다. 【정답 포인트】 ▸ DynamoDB 제한(Throttling)을 예방하려면 제한이 발생하기 전에 경고를 받아야 합니다. ConsumedReadCapacityUnits 메트릭을 모니터링하여 프로비저닝된 용량의 80~90% 수준에서 경고를 설정하면, 실제 제한이 발생하기 전에 용량을 증가시킬 수 있습니다. 이는 사전 대응(proactive) 방식입니다. 【오답 체크】 ▸ (B) Auto Scaling 활성화만으로는 사전 경고가 없으며, EventBridge는 이미 스케일링 후 알림을 보냅니다. (C) (D) THROTTLING_EXCEPTION을 감지하는 것은 이미 제한이 발생한 후의 반응 방식입니다. 【시험 포인트】 ▸ DynamoDB 제한 예방 → CloudWatch 메트릭 기반 경보 (ConsumedReadCapacityUnits). 예외 감지는 너무 늦습니다. Auto Scaling도 도움이 되지만, 경고 요구 사항을 충족하려면 CloudWatch 경보가 필수입니다.

해설

【핵심 용어】 ▸ Dynamic Scaling (Target Tracking) - CloudWatch 메트릭(예: CPU, 요청 수)을 기반으로 자동으로 인스턴스 수를 조정하는 스케일링 방식. 실시간으로 수요에 반응합니다. 【정답 포인트】 ▸ 'CPU 사용률이 50%를 초과하자마자' 스케일 아웃해야 한다는 것은 즉시 반응하는 메트릭 기반 스케일링을 의미합니다. Dynamic Scaling (또는 Target Tracking Scaling Policy)은 정확히 이 요구 사항을 충족합니다. CPU > 50% → 자동 확장. 【오답 체크】 ▸ (A) 이벤트 기반은 특정 이벤트 발생 시 스케일링하는 방식이며 CPU 메트릭과 무관합니다. (B) 일정 기반은 사전 정해진 시간에 스케일링하므로 실시간 수요 대응이 불가능합니다. (D) 예측 스케일링은 과거 데이터로 미래를 예측하여 사전 스케일링하는 방식입니다. 【시험 포인트】 ▸ 메트릭 기반 + 즉시 반응 = Dynamic Scaling. Target Tracking Policy로 CPU > 50% 조건을 설정하면 됩니다. 'CPU 초과 시 즉시' = 동적 스케일링의 핵심입니다.

해설

【핵심 용어】 ▸ Egress-only Internet Gateway (EIGW) - IPv6 전용 게이트웨이. 아웃바운드 트래픽만 허용하고 인바운드는 거부합니다. IPv4의 NAT 게이트웨이에 해당하는 IPv6 솔루션입니다. 【정답 포인트】 ▸ IPv6에서 프라이빗 서브넷의 아웃바운드 전용 연결이 필요하면 Egress-only 인터넷 게이트웨이를 사용합니다. NAT 게이트웨이는 IPv4용이며, IPv6 NAT는 존재하지 않습니다. EIGW는 IPv6의 표준 방식입니다. 【오답 체크】 ▸ (B) IPv6 NAT는 존재하지 않는 기능입니다. (C) IPv6 전용 NAT 게이트웨이도 존재하지 않습니다. (D) IGW는 인바운드를 허용하므로 아웃바운드 전용이 아닙니다. 【시험 포인트】 ▸ IPv4 프라이빗 아웃바운드 = NAT Gateway, IPv6 프라이빗 아웃바운드 = Egress-only IGW. 이 구분을 명확히 알아야 합니다. IPv6 NAT는 존재하지 않습니다.

해설

【핵심 용어】 ▸ Metric Math (메트릭 수학) - CloudWatch에서 여러 메트릭을 수학 연산으로 결합하여 새로운 메트릭을 생성하는 기능. ApproximateNumberOfMessagesVisible을 인스턴스 수로 나누어 메시지/인스턴스 비율을 계산합니다. 【정답 포인트】 ▸ SQS 기반 워커는 '메시지 수 / 인스턴스 수' 비율에 기반한 스케일링이 효과적입니다. CloudWatch 메트릭 수학으로 ApproximateNumberOfMessagesVisible을 ASG 인스턴스 수로 나누면 인스턴스당 메시지 수를 구할 수 있습니다. 이 값을 목표 추적 정책의 타겟으로 설정하면 자동으로 최적 스케일링됩니다. 【오답 체크】 ▸ (A) 메시지 나이는 스케일링의 좋은 지표가 아니며 지연을 측정할 뿐입니다. (C) (D) ALB는 HTTP/HTTPS 기반 로드 밸런싱이며 SQS는 지원하지 않습니다. 【시험 포인트】 ▸ SQS + Auto Scaling = ApproximateNumberOfMessagesVisible을 인스턴스 수로 정규화합니다. 메트릭 수학과 목표 추적 정책의 조합을 이해해야 합니다. ALB는 SQS와 무관합니다.

해설

【핵심 용어】 ▸ CloudWatch Logs Insights - CloudWatch Logs에 저장된 로그를 쿼리 언어로 분석하는 서비스. SQL 같은 문법으로 로그에서 통계를 추출합니다. VPC 플로우 로그 분석에 최적화되어 있습니다. 【정답 포인트】 ▸ VPC 플로우 로그가 이미 CloudWatch Logs에 게시되어 있으므로, CloudWatch Logs Insights로 직접 쿼리하는 것이 가장 효율적입니다. dstaddr 필드를 기반으로 상위 5개를 그룹화하는 간단한 쿼리로 목표를 달성할 수 있습니다. 추가 설정이 불필요합니다. 【오답 체크】 ▸ (A) CloudTrail은 AWS API 호출을 추적하며 인터넷 연결과 무관합니다. (B) CloudFront 로그는 CDN 액세스 로그이며 NAT 게이트웨이와 무관합니다. (D) S3 + Athena는 가능하지만 로그 리디렉션 설정이 필요하여 운영상 비효율적입니다. 【시험 포인트】 ▸ VPC 플로우 로그 분석 → CloudWatch Logs Insights (이미 CloudWatch에 있으면). S3 + Athena는 대규모 로그에서는 비용/성능이 우수하지만, 이미 CloudWatch Logs에 있으면 Insights가 더 효율적입니다.

해설

【핵심 용어】 ▸ Route 53 VPC Association Authorization - 다른 AWS 계정의 VPC를 자신의 프라이빗 호스팅 영역과 연결하기 위한 권한 메커니즘. PHZ 소유 계정이 먼저 권한을 생성합니다. 【정답 포인트】 ▸ 크로스 계정 Route 53 PHZ 연결 절차: (1) 계정 B(PHZ 소유)에서 VPC Association Authorization 생성 (2) 계정 A에서 이 권한을 사용하여 계정 B의 PHZ와 VPC를 연결. 권한 부여 방향은 PHZ 소유 계정 → 다른 계정 순입니다. 【오답 체크】 ▸ (A) /etc/resolv.conf 수정은 비표준 방식이고 확장성이 없습니다. (B) CloudFormation 템플릿은 자동으로 권한을 생성하지 않으며 권한이 필요합니다. (C) 권한 부여 방향이 반대입니다. 계정 A가 권한을 생성하면 계정 B는 이를 사용할 수 없습니다. 【시험 포인트】 ▸ 크로스 계정 Route 53 PHZ 연결: PHZ 소유 계정이 권한 부여(Authorization) 생성 → 다른 계정이 권한 사용하여 VPC 연결. 이 순서를 명확히 알아야 합니다.

해설

【핵심 용어】 ▸ IAM Policy (정책) - 특정 AWS 서비스와 리전에 대한 작업 권한을 정의합니다. 리전 조건(Condition)이 명시되면 해당 리전에서만 작동합니다. 【정답 포인트】 ▸ 문제에서 'EC2 DescribeInstances in us-east-1'을 허용하는 정책이 있다고 가정하면, 옵션 C가 정답입니다. Allow 정책이 명시적으로 이 작업을 허용하기 때문입니다. 다른 작업이나 리전은 정책에 포함되지 않으므로 거부됩니다. 【오답 체크】 ▸ (A) RDS 작업은 정책에 포함되지 않으므로 거부됩니다. (B) S3 PutObject는 일반적으로 나열 권한만 있고 쓰기 권한이 없습니다. (D) eu-west-1은 정책에 명시된 리전(us-east-1)이 아니므로 거부됩니다. 【시험 포인트】 ▸ IAM 정책 분석 문제에서는 Allow/Deny 명시, 리전 조건, 서비스 확인이 필수입니다. 정책 문서를 직접 확인해야 정확한 답을 도출할 수 있습니다. 암묵적 거부(Implicit Deny) 원칙을 이해해야 합니다.

해설

【핵심 용어】 ▸ Route 53 Resolver Inbound Endpoint - 온프레미스 또는 외부 시스템이 AWS Route 53 프라이빗 호스팅 영역의 DNS를 쿼리할 수 있도록 하는 엔드포인트. 인바운드 쿼리를 수신합니다. 【정답 포인트】 ▸ 온프레미스 서버가 AWS의 프라이빗 호스팅 영역을 쿼리해야 하므로 Inbound Endpoint가 필요합니다. 온프레미스에서 AWS의 Inbound Endpoint로 DNS 쿼리(포트 53)를 보내면, 엔드포인트가 이를 수신하고 Route 53 PHZ에서 레코드를 반환합니다. 보안 그룹은 인바운드(온프레미스 → AWS)를 허용해야 합니다. 【오답 체크】 ▸ (B) 아웃바운드는 AWS에서 외부로 나가는 방향이므로 반대입니다. (C) (D) 아웃바운드 엔드포인트는 AWS가 외부 DNS를 쿼리할 때 사용하므로 이 경우 맞지 않습니다. 【시험 포인트】 ▸ 온프레미스 → AWS Route 53 PHZ 쿼리 = Inbound Endpoint. AWS → 온프레미스 DNS 쿼리 = Outbound Endpoint. 방향을 명확히 이해해야 합니다. Direct Connect는 네트워크 기반일 뿐 DNS 방향과는 별개입니다.

해설

【핵심 용어】 ▸ CloudFormation Stack Policy - 스택의 리소스에 대한 업데이트 권한을 세밀하게 제어합니다. Update:* 작업을 특정 리소스에 대해 명시적으로 거부할 수 있습니다. 【정답 포인트】 ▸ Stack Policy를 사용하면 CloudFormation 업데이트 시점에 특정 리소스의 수정을 차단할 수 있습니다. 정책 구조: (1) 모든 리소스에 대해 Update 허용 (2) 보호할 리소스에 대해 Update:* 거부. 이는 가장 직접적이고 운영상 효율적인 방법입니다. 【오답 체크】 ▸ (A) (B) Config와 EventBridge는 사후 감지(retrospective)이며 이미 변경이 적용된 후에 탐지합니다. (D) IAM 정책은 CloudFormation 스택 자체를 제어하지 리소스별 업데이트 통제는 어렵습니다. 【시험 포인트】 ▸ 특정 리소스 업데이트 보호 → Stack Policy가 정답입니다. Stack Policy는 UpdatePolicy와 다르며, 리소스 수정을 사전(preventive)에 차단합니다. Lambda 기반 사후 처리는 비효율적입니다.