정답 · 해설

해설

【핵심 용어】 ▸ SAML 페더레이션 메타데이터 — IdP 서명 인증서 포함, 인증서 교체 시 IAM IdP 엔티티의 메타데이터 갱신 필요 ▸ "Response Signature Invalid" — IAM에 등록된 IdP 인증서가 IdP의 새 서명 인증서와 불일치 ▸ 기존 IAM IdP 엔티티 업데이트 — 역할 신뢰 관계 유지하며 즉시 복구 【정답 포인트】 ▸ (C) IdP에서 새 SAML 메타데이터를 받아 기존(문제의) IAM IdP 엔티티에 업로드 → 즉시 복구(새 엔티티 생성 불필요, 역할 참조 유지) ▸ (B) 재발 방지: 다음 교체 주기에 현재 인증서 만료 전 보조(secondary) 인증서를 IdP에 추가하고 메타데이터 갱신, 필요 시 자동/수동 로테이션 【오답 체크】 (A) 새 IAM IdP 엔티티 생성은 불필요하며 역할 신뢰 정책의 IdP 참조를 깨뜨림. (D) 마찬가지로 새 엔티티 생성이 불필요하고 기존 역할 매핑을 깨뜨림. (E) 새 엔티티 이름을 SAML assertion에 전달하도록 바꾸는 것은 과도하고 불필요한 변경. 【시험 포인트】 SAML 서명 오류(인증서 교체) = 기존 IAM IdP 엔티티에 새 메타데이터 업로드. 재발 방지는 만료 전 보조 인증서 추가.

해설

【핵심 용어】 ▸ 보안 그룹 참조(SG referencing) — 소스로 다른 SG를 지정, 피어링된 동일 리전 VPC 간에도 참조 가능 ▸ 상태 저장 SG — 특정 인스턴스만 선택적으로 DB 접근 허용, 인스턴스 생성/종료(churn)에 강함 ▸ TCP 1521 — Oracle DB 포트 【정답 포인트】 ▸ "일부 EC2만 DB 접근 + 인스턴스 수시 생성/종료" → 앱 VPC에 인바운드 없는 앱 SG 생성, DB VPC SG는 앱 SG를 소스로 1521 허용 ▸ DB 접근이 필요한 인스턴스에만 앱 SG를 붙이면 IP 변화와 무관하게 최소 권한 접근 보장 【오답 체크】 (A) 앱 VPC 전체 IP 범위 허용 + NACL 추가는 필요 없는 인스턴스까지 접근 가능해 최소 권한 위반. (B) IP 범위(앱 VPC 전체) 기반 허용은 특정 인스턴스만 선택 불가. (D) 앱 VPC 전체 IP 범위 허용은 접근 대상을 선별하지 못해 요구 위반. 【시험 포인트】 "특정 인스턴스만 + 수시 교체" 선택적 접근 = SG 참조(소스 SG 지정), IP 범위 지정은 선별 불가.

해설

【핵심 용어】 ▸ Amazon Kinesis — 로그 실시간 스트리밍, 보존 기간 내 메시지 재생(replay), 지속(persist) 가능 ▸ Amazon OpenSearch Service — 실시간 분석·검색 ▸ Amazon SQS — 메시지 소비 후 삭제되어 재생(replay) 미지원 【정답 포인트】 ▸ "실시간 분석 + 메시지 재생 + 로그 지속" → (B) Kinesis가 실시간 수집·재생·보존 담당, (D) OpenSearch가 실시간 분석·검색 담당 ▸ 두 서비스 조합으로 포렌식 로깅 요건(실시간 분석·replay·persist) 충족 【오답 체크】 (A) Athena는 S3 대상 배치 쿼리로 실시간 분석/스트리밍 재생에 부적합. (C) SQS는 메시지 소비 후 삭제되어 재생(replay)을 지원하지 않음. (E) EMR은 대규모 배치 처리용으로 실시간 요건에 맞지 않음. 【시험 포인트】 실시간 스트리밍 + replay + 지속 = Kinesis, 실시간 검색/분석 = OpenSearch.

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — Organizations의 계정 권한 상한(guardrail), 루트 사용자에게도 적용되어 서비스 접근 차단 가능 ▸ AWS account root user — 계정 최상위 자격 증명, IAM 정책으로 제한 불가하나 SCP는 예외 ▸ EventBridge — 루트 사용자 API 이벤트 탐지·알림용 (탐지일 뿐 차단은 아님) 【정답 포인트】 ▸ "루트 자격 증명이 탈취돼도 계정 보호" → 예방적 통제 필요 ▸ SCP는 멤버 계정의 루트 사용자에게도 적용되어 서비스 접근 자체를 차단 → 자격 증명이 유출돼도 실제 행동 봉쇄 【오답 체크】 (B) 루트 비밀번호 제거는 재설정으로 복구 가능, 근본 차단 아님. 관리 콘솔 접근만 막을 뿐. (C) 액세스 키 삭제는 좋은 관행이나 콘솔 로그인·행동 자체를 막지 못함. (D) EventBridge 탐지는 사후 알림일 뿐, 자격 증명 오용을 예방하지 못함. 【시험 포인트】 "루트 사용자 오용 예방" + Organizations 환경 → SCP로 루트에 대한 서비스 접근 차단. 탐지(EventBridge)와 예방(SCP)을 구분.

해설

【핵심 용어】 ▸ CloudWatch Logs — 로그 게시에는 logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents 등 logs: API 권한 필요 ▸ CloudWatch 커스텀 메트릭 — cloudwatch:PutMetricData 권한 (로그 게시와 별개) ▸ IAM 인스턴스 역할 — EC2가 AWS API 호출 시 사용하는 자격 증명 【정답 포인트】 ▸ 네트워크·에이전트는 정상이나 커스텀 메트릭만 게시 가능 → 정책에 cloudwatch: 권한만 있고 logs: 권한 누락 ▸ CloudWatch Logs 게시에 필요한 logs: API 액션을 IAM 정책에 추가해야 로그 전송 가능 【오답 체크】 (A) cloudwatch: API는 메트릭용, 로그 게시 액션이 아님 → 로그 문제 해결 불가. (B) Auto Scaling 서비스 연결 역할은 스케일링용이지 인스턴스의 로그 게시 권한과 무관. (D) 이미 NAT 게이트웨이로 네트워크 통신이 정상 확인됨 → VPC 엔드포인트 불필요. 【시험 포인트】권한 문제 원인 분리: 메트릭(cloudwatch:PutMetricData) vs 로그(logs:PutLogEvents). 로그 미게시는 logs: 권한 누락 의심.

해설

【핵심 용어】 ▸ Amazon Inspector — EC2·ECR·Lambda의 OS 패키지·프로그래밍 언어 라이브러리 취약점 자동 스캔, ECR 강화 스캔 지원 ▸ AWS Security Hub — 다계정 findings 집계·중앙 관리, 감사팀 검토 지점 ▸ AWS Config / Audit Manager / GuardDuty — 각각 구성 규정 준수, 감사 증거 수집, 위협 탐지용 (취약점 스캔 아님) 【정답 포인트】 ▸ "OS·언어 라이브러리 취약점 스캔" → Amazon Inspector가 ECR 이미지·컨테이너 취약점 스캔의 표준 ▸ "여러 계정의 취약점을 감사팀이 식별" → Inspector findings를 중앙 보안 계정 Security Hub로 집계 【오답 체크】 (B) AWS Config는 리소스 구성 규정 준수 평가용, 소프트웨어 취약점 스캔 기능 없음. (C) Audit Manager는 규정 준수 감사 증거 수집 도구지 취약점 스캐너 아님. (D) GuardDuty는 위협 탐지(악성 행위)용이지 CVE 취약점 스캔 서비스 아님. 【시험 포인트】"취약점(CVE)·라이브러리 스캔" = Amazon Inspector. 다계정 findings 통합 = Security Hub 위임 관리자.

해설

【핵심 용어】 ▸ AWS Systems Manager Patch Manager — 인스턴스의 누락 패치·CVE 식별 및 자동 패치 배포, 규정 준수 리포트 제공 ▸ Amazon Inspector — CVE 취약점 탐지는 하나, 패치 적용(remediation) 기능 없음 ▸ GuardDuty / Shield — 위협 탐지, DDoS 보호용 (패치 무관) 【정답 포인트】 ▸ "위험 인스턴스 식별" + "자동 패치 적용" → 두 가지를 모두 수행하는 서비스는 Patch Manager ▸ Patch Manager로 누락 패치(취약점 ID) 확인 후 동일 서비스로 패치 자동화 【오답 체크】 (B) Shield Advanced는 DDoS 보호용, 취약점 식별과 무관. (C) GuardDuty는 위협 탐지용, Inspector는 패치 자동화 기능 없음. (D) Inspector는 취약점 탐지만 가능, 패치 적용(자동 업데이트) 기능이 없음. 【시험 포인트】EC2 패치 식별+적용 = Patch Manager. Inspector는 "탐지 전용"이라 remediation이 붙으면 오답.

해설

【핵심 용어】 ▸ VPC Traffic Mirroring — 인터페이스의 전체 패킷을 복제해 모니터링 대상으로 전달, IDS/DPI에 적합 (Nitro 기반 인스턴스 지원) ▸ VPC Flow Logs — 메타데이터(5-tuple)만 기록, 패킷 페이로드 미포함 ▸ Network Load Balancer — 미러링 트래픽을 모니터링 인스턴스 플릿으로 분산 【정답 포인트】 ▸ "전체 패킷 검사" + IDS → 패킷 페이로드까지 복제하는 Traffic Mirroring이 유일한 방법 ▸ 미러 대상을 NLB 뒤 모니터링 EC2로 지정해 트래픽 검사 【오답 체크】 (A) EC2는 하이퍼바이저가 promiscuous 모드를 지원하지 않아 다른 인스턴스 트래픽 캡처 불가. (B) Flow Logs는 헤더 메타데이터만 기록, 전체 패킷 검사 요건 불충족. (D) Inspector는 취약점 스캐너이지 실시간 네트워크 패킷 검사·전달 기능 없음. 【시험 포인트】"전체 패킷 검사"·"IDS" = VPC Traffic Mirroring. Flow Logs는 메타데이터뿐이라 페이로드 요건에서 탈락.

해설

【핵심 용어】 ▸ Perfect Forward Secrecy (PFS) — 세션마다 임시 키 사용, 서버 개인키가 유출돼도 과거 세션 복호화 불가 (ECDHE 계열 암호군) ▸ ALB Security Policy — HTTPS 리스너의 지원 암호군·프로토콜 정의, PFS 지원 정책 선택 가능 ▸ ACM — 인증서 관리용이나 PFS 자체를 보장하진 않음 【정답 포인트】 ▸ "개인키 유출돼도 과거 TLS 트래픽 보호" → PFS의 정의 그 자체 ▸ ALB HTTPS 리스너에 PFS 암호군을 포함한 보안 정책 적용 【오답 체크】 (A) ACM 인증서 사용은 신뢰 체인 제공일 뿐, 개인키 유출 시 과거 세션 보호(PFS)와 무관. (C) Server Order Preference는 서버가 암호군 우선순위를 정할 뿐 PFS를 강제하지 않음. (D) TCP 리스너는 ALB에 없고(NLB용), ALB는 HTTPS/HTTP 리스너로 TLS 종료 → 요건과 맞지 않음. 【시험 포인트】"개인키 유출돼도 안전" = PFS(ECDHE). ALB는 보안 정책으로 PFS 암호군 선택.

해설

【핵심 용어】 ▸ CloudTrail Organization Trail — 조직 전체 계정의 API 활동을 중앙 기록 ▸ CloudWatch Logs 메트릭 필터 + 알람 — 지정 이벤트 발생 시 근실시간 감지·알람 ▸ Amazon SNS — 알람을 이메일 배포 목록으로 전달 【정답 포인트】 ▸ "조직 모든 계정 로깅" → 조직 트레일 필요 ▸ "지정 액션에 알람 + 이메일 + 근실시간" → CloudWatch Logs 메트릭 필터·알람 → SNS 이메일 게시 【오답 체크】 (B) 조직 트레일이 아니라 단일 계정 트레일이며, SQS 큐는 이메일 알림에 부적합. (C) EC2에 S3를 파일 시스템으로 마운트해 폴링하는 방식은 복잡·비실시간·비효율. (D) 시간별 Glue/Athena 배치 쿼리는 근실시간이 아니고 알람·이메일 요건 미충족. 【시험 포인트】"조직 전체 + 근실시간 알람 + 이메일" = 조직 트레일 → CloudWatch Logs 메트릭 필터/알람 → SNS.

해설

【핵심 용어】 ▸ Kinesis Agent + Kinesis Data Firehose — 온프레미스 로그를 스트리밍 수집하는 관리형 파이프라인 ▸ Managed Service for Apache Flink — 근실시간 스트림 처리·분석 ▸ Amazon OpenSearch Service — 패턴 매칭·부분 문자열 검색 및 인덱스 저장, ISM 정책으로 365일 후 자동 삭제 【정답 포인트】 ▸ "근실시간 분석" + "패턴 매칭·부분 문자열 검색" + "365일 보관" + "개발 오버헤드 최소" → 관리형 서비스 조합 ▸ Firehose→Flink 실시간 처리, OpenSearch 검색·보관, ISM으로 자동 만료 【오답 체크】 (A) DynamoDB는 부분 문자열/패턴 검색에 부적합, Athena 내보내기 등 다단계로 개발 오버헤드 큼. (B) 온프레미스에 MSK를 직접 설치·운영하는 방식은 관리 부담이 크고 검색 요건 미흡. (D) API Gateway+Lambda+DynamoDB는 커스텀 코드 다수·검색 부적합으로 개발 오버헤드 큼. 【시험 포인트】"근실시간 로그 분석 + 텍스트 검색 + 최소 개발" = Firehose + OpenSearch. DynamoDB는 부분 문자열 검색에 부적합.

해설

【핵심 용어】 ▸ Systems Manager Session Manager — SSH 키·인바운드 포트·베스천 없이 IAM·SSM 기반으로 프라이빗 인스턴스에 안전한 셸 접속, 감사 로깅 지원 ▸ EC2 Instance Connect — SSH 기반(포트 22 필요), 주로 퍼블릭 접근·임시 키 주입 방식 ▸ SSH-RSA 키 — 관리·유출 위험, 키 없는 접근이 더 안전 【정답 포인트】 ▸ "가장 안전한 원격 관리" + 프라이빗 서브넷 → SSH 키·개방 포트 불필요한 Session Manager ▸ 신규 인스턴스에 SSH-RSA 키를 사용하지 않고 Session Manager로 접속 【오답 체크】 (B) 새 SSH 키 생성은 여전히 키 관리·포트 개방 부담 유지 → 최선의 보안 아님. (C) EC2 Instance Connect는 SSH(포트 22)에 의존, Session Manager보다 노출 큼. (D) 새 SSH 키 + Instance Connect 모두 SSH·포트 의존으로 보안성 낮음. 【시험 포인트】"가장 안전한 원격 접속" = Session Manager (키 없음, 포트 개방 없음, IAM 통제·로깅).

해설

【핵심 용어】 ▸ CloudWatch Agent → CloudWatch Logs — 인스턴스 로그를 중앙에 실시간 전송, 스케일인 시에도 로그 보존 ▸ CloudWatch Logs Insights — 저장된 로그에 대한 쿼리 언어로 세션·사용자 이슈 분석 ▸ Auto Scaling 스케일인 — 인스턴스 종료 시 로컬 로그 소실 위험 【정답 포인트】 ▸ "스케일인 시 로그 소실 방지" → CloudWatch Agent로 CloudWatch Logs에 상시 전송 (C) ▸ "로그 쿼리로 세션·이슈 분석" → CloudWatch Logs Insights로 쿼리 (D) ▸ 두 관리형 서비스 조합이 가장 비용 효율적 【오답 체크】 (A) cron으로 주기적 S3 업로드는 마지막 주기 이후 로그 소실 위험·관리 부담. (B) Glue+Athena는 S3 저장 전제이며 별도 ETL 오버헤드 추가로 비용·복잡도 증가. (E) EFS 마운트는 추가 비용·복잡성, 로그 수집·쿼리의 표준 해법 아님. 【시험 포인트】"스케일인 로그 유실 방지 + 쿼리" = CloudWatch Agent + CloudWatch Logs Insights 조합.

해설

【핵심 용어】 ▸ CloudTrail 이벤트 기록(Event history) — 최근 90일 API 이벤트를 콘솔에서 즉시 필터 조회 가능 ▸ AssumeRoleWithSAML — SAML 페더레이션 로그인 이벤트, role session name·사용자명 포함 ▸ TerminateInstances — EC2 종료 API 이벤트 【정답 포인트】 ▸ "가장 빠르게" 페더레이션 사용자 식별 → CloudTrail 이벤트 기록에서 TerminateInstances 필터 → 사용한 IAM 역할 확인 ▸ AssumeRoleWithSAML 이벤트를 조회해 해당 세션의 실제 사용자명 매핑 【오답 체크】 (A) S3의 CloudTrail 로그를 뒤지는 것은 콘솔 이벤트 기록보다 느림. role session name만으로 부족할 수 있음. (C) IAM Access Advisor의 마지막 접근 시각은 서비스 수준 정보라 특정 사용자·행위를 정확히 특정 못함. (D) Athena 쿼리는 설정·실행 오버헤드로 느리며, SAML 페더레이션인데 WebIdentity 이벤트를 조회해 부적합. 【시험 포인트】"FASTEST 페더레이션 사용자 추적" = CloudTrail 이벤트 기록 필터 + AssumeRoleWithSAML로 사용자명 매핑.

해설

【핵심 용어】 ▸ VPC Flow Logs — 허용/거부(ACCEPT/REJECT) 패킷 기록, 거부 사유 파악에 유용 ▸ Network ACL — 서브넷 경계 스테이트리스 필터 (서브넷 간 통신 문제의 흔한 원인) ▸ Security Group — 이미 유효한 ALLOW 규칙 확인됨(거부 규칙 없음, 스테이트풀) 【정답 포인트】 ▸ SG는 정상, 서로 다른 서브넷 간 통신 실패 → 트래픽이 어디서 막히는지 근거 확보 필요 ▸ VPC Flow Logs의 거부(REJECT) 패킷 사유를 검토해 원인(예: NACL 차단) 규명 【오답 체크】 (A) SG에는 DENY 규칙 자체가 존재하지 않음(허용만 가능) → 잘못된 접근. (B) NACL 확인이 유력 원인이나, 먼저 Flow Logs로 거부 여부·지점을 확인하는 것이 진단 절차상 맞음. (D) X-Ray는 애플리케이션 추적용이지 네트워크 계층 연결 문제 진단 도구 아님. 【시험 포인트】네트워크 연결 실패 진단 → VPC Flow Logs의 REJECT 사유 확인. SG는 DENY 규칙이 없음(암묵적 거부만).

해설

【핵심 용어】 ▸ S3 GetObject 권한 — 객체 조회에 s3:GetObject/ListBucket 등 IAM 권한 필요 ▸ KMS 복호화 — SSE-KMS 객체 조회 시 kms:Decrypt 권한 필수(키 정책·IAM 양측) ▸ S3 게이트웨이 VPC 엔드포인트 — 인터넷 없이 S3 접근, 엔드포인트 정책·버킷 정책이 접근 허용해야 함 【정답 포인트】 ▸ 인터넷 없는 VPC에서 KMS 암호화 객체 조회 실패 원인 3가지: ▸ (A) IAM 인스턴스 프로파일에 s3:ListBucket 미허용 → 목록/조회 실패 ▸ (D) KMS 키 정책이 인스턴스 프로파일에 kms:Decrypt 미허용 → 복호화 실패 ▸ (E) 게이트웨이 VPC 엔드포인트에서의 접근을 버킷 정책이 거부 → 접근 차단 【오답 체크】 (B) s3:ListParts는 멀티파트 업로드 관련, 객체 GET 실패의 원인 아님. (C) kms:ListKeys는 키 나열용, 객체 복호화(kms:Decrypt)와 무관. (F) 보안 그룹은 스테이트풀이라 아웃바운드 응답에 인바운드 규칙 불필요 → prefix list 인바운드 규칙은 원인 아님. 【시험 포인트】SSE-KMS + VPC 엔드포인트 S3 실패 3대 원인 = IAM s3 권한, KMS kms:Decrypt, 엔드포인트/버킷 정책. SG 인바운드는 무관.

해설

【핵심 용어】 ▸ Secrets Manager 다중 리전 복제 — 기본 리전 시크릿을 다른 리전으로 복제, 각 리전 로컬 접근으로 지연 최소화 ▸ Customer managed KMS key — 복제된 시크릿을 리전에서 복호화하려면 해당 리전에서 접근 가능한 CMK 필요 ▸ AWS managed key — 리전·서비스 종속, 교차 리전 복제 시크릿 재암호화에 사용자 제어 불가 【정답 포인트】 ▸ "양 리전 저장 + 지연 최소 + 단일 리전만 가용해도 동작" → 복제 시크릿을 로컬에서 사용 ▸ CMK로 암호화 후 us-west-1로 복제, us-west-1에서도 사용자 관리 키로 암호화 → 각 리전 독립 복호화 가능 【오답 체크】 (A) AWS 관리형 키는 복제 시크릿 암호화 키를 사용자가 지정·제어할 수 없음. (B) us-east-1 엔드포인트를 호출하면 지연 증가·단일 리전 장애 시 동작 불가 요건 위반. (C) 복제하지 않고 원격 엔드포인트 호출 → 지연·가용성 요건 위반. 【시험 포인트】다중 리전 시크릿 + 지연 최소 + 리전 격리 = Secrets Manager 복제 + 각 리전에서 사용 가능한 CMK. 원격 엔드포인트 호출은 가용성 요건 위반.

해설

【핵심 용어】 ▸ KMS key alias — 애플리케이션이 참조하는 논리 이름, 실제 키를 교체해도 코드 변경 불필요 ▸ Customer managed key — 사용자가 생성·교체·정책 제어 가능 (온디맨드 교체 지원) ▸ AWS owned/managed key — 사용자가 온디맨드로 자유롭게 교체 불가 【정답 포인트】 ▸ "원할 때마다 새 키 자료로 교체" → 임의 시점 온디맨드 교체 필요 ▸ alias를 사용해 애플리케이션은 alias만 참조하고, 침해 의심 시 새 CMK 생성 후 alias를 새 키로 연결 → 신규 파일이 새 키로 암호화 【오답 체크】 (A) 로테이션 스케줄은 자동 주기(연 1회 등) 방식이며 임의 온디맨드 트리거로 즉시 새 키 자료 교체 요건에 부합하지 않음. (B) AWS 관리형 키는 사용자가 로테이션 시점을 임의 제어 불가. (D) AWS 관리형 키는 사용자가 자유롭게 생성·교체할 수 없어 요건 미충족. 【시험 포인트】"원하는 시점에 키 교체 + 코드 무변경" = alias + 신규 CMK 생성 후 alias 재연결.

해설

【핵심 용어】 ▸ CloudFront Origin Access Control (OAC) — CloudFront만 S3 오리진 접근 허용, 직접 S3 URL 접근 차단 ▸ AWS WAF web ACL + IP set rule — 지정 IP만 허용/차단, CloudFront에 연결 ▸ S3 버킷 정책 — OAC 주체만 접근 허용하도록 설정 【정답 포인트】 ▸ "지정 IP만 허용" → CloudFront에 WAF IP set 규칙 연결 ▸ "S3 직접 접근 차단" → OAC로 CloudFront만 S3 접근, 버킷 정책은 OAC만 허용 【오답 체크】 (A) aws:SourceIp로 IP 허용해도 S3 직접 URL 접근을 완전히 막지 못하며 IP 필터 관리 부담. OAC 미사용으로 요건 미흡. (C) 보안 그룹은 S3·CloudFront에 적용 불가한 개념 → 부적합. (D) S3 액세스 포인트만으로는 IP 제한 요건을 CloudFront 계층에서 처리하는 표준 방식이 아니며, OAC 기반 직접 접근 차단이 정석. 【시험 포인트】CloudFront+S3에서 "직접 접근 차단" = OAC, "IP 제한" = WAF IP set. 둘을 결합.

해설

【핵심 용어】 ▸ SSM Parameter Store SecureString — 민감 정보를 KMS로 암호화 저장, IAM으로 접근 통제 ▸ EC2 user data — 인스턴스 메타데이터로 평문 노출 위험 (콘솔·메타데이터에서 조회 가능) ▸ EC2 instance role — GetParameters 권한만 부여해 최소 권한 접근 【정답 포인트】 ▸ "부트스트랩 민감 정보가 노출됨" → user data에 평문으로 넣지 말 것 ▸ SecureString 파라미터에 저장하고 인스턴스 역할에 GetParameters 권한만 부여 → 런타임에 안전하게 조회 【오답 체크】 (A) AMI에 스크립트 저장+KMS는 관리 복잡·AMI 갱신 부담, Parameter Store보다 비효율. (C) S3 외부화+수동 로그 정리는 관리 부담·실수 여지 크고 표준 관행 아님. (D) 메타데이터 서비스 차단은 인스턴스 역할 자격 증명 조회도 막아 정상 동작 방해, 근본 해결 아님. 【시험 포인트】부트스트랩 시크릿 보호 = Parameter Store SecureString(또는 Secrets Manager) + 인스턴스 역할 최소 권한. user data 평문은 금지.