정답 · 해설

해설

【핵심 용어】 ▸ Network ACL — 서브넷 단위 스테이트리스 방화벽, Allow·Deny 규칙 모두 지원, 특정 IP 차단 가능 ▸ Security Group — 인스턴스 단위 스테이트풀 방화벽, Allow 규칙만 지원(Deny 불가) ▸ 명시적 Deny — 특정 소스 IP·포트만 차단하고 나머지는 허용 유지 【정답 포인트】 ▸ "특정 외부 소스의 해당 포트 트래픽만 차단, 다른 사용자 서비스는 유지" → NACL에 해당 포트·소스 IP에 대한 Deny 규칙 추가로 그 소스만 차단 (A) 【오답 체크】 (B) 보안 그룹에서 포트를 인바운드 규칙에서 제거하면 모든 사용자 접근이 끊김 → 가용성 위배. (C) 보안 그룹은 Deny 규칙을 지원하지 않음 → 구성 불가. (D) 새 NACL로 EC2에서 나가는 모든 트래픽을 Deny하면 애플리케이션 전체가 마비. 【시험 포인트】 "특정 소스 IP만 차단하고 나머지 허용" → NACL Deny 규칙(보안 그룹은 Deny 불가).

해설

【핵심 용어】 ▸ CloudTrail → CloudWatch Logs + 메트릭 필터 + 알람 — 로그 패턴을 메트릭화해 알람·SNS로 알림 ▸ EventBridge 규칙 — 관리 이벤트(root 콘솔 로그인)를 실시간 매칭해 SNS로 전달 ▸ 근실시간 root 로그인 탐지 — 루트 자격증명 사용 시 즉시 통지 【정답 포인트】 ▸ 방법 1: CloudTrail을 CloudWatch Logs로 보내 root 로그인 성공 로그에 메트릭 필터를 걸고 알람 → SNS 통지 (C) ▸ 방법 2: EventBridge 규칙으로 root 콘솔 로그인 이벤트를 매칭해 SNS로 직접 통지 (E) 【오답 체크】 (A) Trusted Advisor는 정기 점검·권고 서비스로 근실시간 root 로그인 이벤트 알림에 부적합. (B) IAM Access Analyzer는 외부 액세스 분석용으로 root 로그인 이벤트를 생성하지 않음. (D) CloudTrail은 SNS로 "로그 파일 배달" 알림만 보낼 뿐 이벤트 내용 통지가 아니며, Lambda 파싱 구성이 복잡해 근실시간 통지에 부적합. 【시험 포인트】 "근실시간 root 로그인 알림" → CloudTrail→CloudWatch Logs 메트릭 필터/알람 또는 EventBridge 규칙 + SNS.

해설

【핵심 용어】 ▸ Security Hub 위임 관리자 + 자동 등록 — 조직의 기존/신규 계정을 자동으로 Security Hub 멤버로 관리 ▸ Finding 집계 리전(Aggregation Region) — 여러 리전의 findings를 한 리전으로 모아서 조회 ▸ AWS Organizations 통합 — 최소 운영 부담으로 전 계정 온보딩 【정답 포인트】 ▸ "모든 리전의 findings 수신" → 집계 리전을 지정하고 나머지 리전을 링크 (A) ▸ "기존·신규 계정 자동 관리" → 계정 자동 활성화 옵션을 켜서 신규 계정도 자동 등록 (C) 【오답 체크】 (B) Lambda+EventBridge로 리전 간 이벤트를 수작업 라우팅하는 방식은 운영 부담이 큼(집계 리전 기능이 표준). (D) securityhub:DisableSecurityHub를 막는 SCP는 자동 등록·리전 집계 요구와 무관. (E) CloudTrail 조직 트레일에서 이벤트를 읽는 방식은 Security Hub findings 집계 방법이 아님. 【시험 포인트】 "조직 전 계정 Security Hub 자동관리 + 전 리전 findings" → 계정 자동 활성화 + finding 집계 리전.

해설

【핵심 용어】 ▸ KMS 가져온 키 자료(Imported Key Material) — 외부에서 키 자료를 임포트, DeleteImportedKeyMaterial로 즉시 삭제 가능 ▸ SSE-KMS 투명 암호화 — 사용자가 키를 직접 다루지 않고 S3 객체를 암호화, 확장성 우수 ▸ ScheduleKeyDeletion — KMS 키 삭제 예약, 최소 대기 7일(즉시 삭제 불가) 【정답 포인트】 ▸ "키를 직접 다루지 않고 확장성 있게 S3 암호화 + 필요 시 즉시 삭제" → 가져온 키 자료를 사용하고, 필요 시 DeleteImportedKeyMaterial로 키 자료를 즉시 제거해 데이터 접근 불가화 (B) 【오답 체크】 (A) ScheduleKeyDeletion은 PendingWindowInDays 최소값이 7일이라 0으로 즉시 삭제 불가. AWS 관리형 키는 삭제 자체가 불가. (C) CloudHSM은 지속적 클러스터 관리가 필요해 "지속 관리 불필요" 요건 위배. (D) Parameter Store는 암호화 키 관리·즉시 무효화용 서비스가 아님(S3 투명 암호화와 무관). 【시험 포인트】 "키 즉시 삭제/무효화" → KMS 가져온 키 자료 + DeleteImportedKeyMaterial.

해설

【핵심 용어】 ▸ DNSSEC 신뢰 체인(Chain of Trust) — 상위 존이 하위 존의 키를 서명해 신뢰를 연결 ▸ KSK(Key-Signing Key) — 존의 키를 서명하는 키, 그 지문이 DS 레코드로 상위에 등록됨 ▸ DS(Delegation Signer) 레코드 — 상위 호스팅 존에 등록해 하위 존 KSK를 인증(신뢰 체인 완성) 【정답 포인트】 ▸ "DNSSEC 서명·KSK 생성 후 broken trust chain 오류" → 상위(부모) 호스팅 존에 DS 레코드를 등록해야 신뢰 체인이 연결됨 (C) 【오답 체크】 (A) KSK를 ZSK로 대체하는 것은 신뢰 체인 문제 해결과 무관하며 Route 53 DNSSEC 구성 방식도 아님. (B) KSK 비활성/재활성은 체인 연결과 무관. (D) DS 레코드는 하위(서브도메인) 존이 아니라 반드시 상위 부모 존에 등록해야 함 → 위치 오류. 【시험 포인트】 "DNSSEC broken trust chain" → 부모 호스팅 존에 DS 레코드 등록.

해설

【핵심 용어】 ▸ GuardDuty 위임 관리자(Delegated Administrator) — 조직 전 계정의 GuardDuty를 중앙 계정에서 통합 관리 ▸ 신규 계정 자동 활성화 — 조직에 추가되는 계정에 GuardDuty 자동 온보딩 ▸ 관리 계정과 분리된 전용 보안 계정 — 모범 사례(관리 계정에 직접 두지 않음) 【정답 포인트】 ▸ "기존·미래 계정 GuardDuty findings 중앙 조회 + 신규 계정 자동 활성화" → 신규 전용 계정을 GuardDuty 위임 관리자로 지정하고, 기존 계정을 멤버로 추가, 신규 계정 자동 추가 옵션 선택 (B) 【오답 체크】 (A) 관리 계정에서 GuardDuty를 켜는 방식은 위임 관리자 모범 사례에 어긋나고 신규 계정 자동 활성화가 빠짐. (C) 각 계정마다 Security Hub를 켜는 방식은 GuardDuty 중앙 관리가 아님. (D) Security Hub 위임 관리자는 findings 집계용이지 GuardDuty 자동 활성화·통합 관리 요구를 직접 충족하지 않음. 【시험 포인트】 "GuardDuty 조직 통합 + 신규 계정 자동 온보딩" → 전용 계정을 GuardDuty 위임 관리자로 지정.

해설

【핵심 용어】 ▸ Systems Manager Session Manager — SSH 키·개방 포트 없이 IAM 권한으로 셸 세션 접속, 감사 로깅 지원 ▸ SSM Agent + 인스턴스 프로파일 — 인스턴스가 Systems Manager 관리 대상이 되도록 IAM 역할 부여 ▸ 최소 권한 접근 — IAM 사용자에게 Session Manager 사용 권한만 부여 【정답 포인트】 ▸ "SSH 키 영구 제거 + 3명의 IAM 사용자만 셸 접속" → 인스턴스 프로파일에 SSM 관리 권한을 주고, 해당 IAM 사용자에게 Session Manager 권한 부여, SSH 키 제거 후 Session Manager로 접속 (C) 【오답 체크】 (A) Systems Manager Inventory는 소프트웨어/구성 수집 기능으로 인스턴스에 셸 접속하는 기능이 아님. (B) Run Command는 명령 실행용이지 대화형 SSH 세션을 여는 도구가 아님. (D) 콘솔의 EC2 SSH client(EC2 Instance Connect)는 SSH 키/포트 개방에 의존 → SSH 키 영구 제거 요건과 상충. 【시험 포인트】 "SSH 키·포트 없이 셸 접속" → Systems Manager Session Manager.

해설

【핵심 용어】 ▸ S3 Glacier Vault Lock — 볼트 잠금 정책을 불변으로 적용, initiate-vault-lock 후 24시간 유예 ▸ abort-vault-lock — 유예 기간(24시간) 내 진행 중인 잠금 정책을 취소 ▸ complete-vault-lock — 정책을 영구 확정(이후 변경 불가) 【정답 포인트】 ▸ "12시간 전 initiate-vault-lock, 정책 오타 발견" → 아직 24시간 유예 내이므로 abort-vault-lock으로 취소하고 정책 수정 후 다시 initiate-vault-lock (A). 데이터 이동 없이 가장 비용 효율적. 【오답 체크】 (B) 볼트 데이터를 새 버킷으로 복사·삭제·재생성은 10TB 전송·재저장 비용이 커서 비효율. (C) 정책을 그대로 두면 오타로 인한 의도치 않은 접근이 계속 허용됨. (D) 유예 기간 중에는 새 initiate 전에 abort가 필요하며, abort 없이 다시 initiate로 덮어쓸 수 없음. 【시험 포인트】 "Vault Lock 24시간 유예 내 정책 수정" → abort-vault-lock 후 재initiate.

해설

【핵심 용어】 ▸ CloudFront 서명된 쿠키(Signed Cookies) — 여러 파일/경로 접근을 한 번의 쿠키로 인증, URL 변경 불필요 ▸ CloudFront 서명된 URL(Signed URL) — 개별 파일마다 서명 URL 필요 ▸ HLS 청크 — 영상이 수천 개 청크로 분할되어 다수 파일 접근 필요 【정답 포인트】 ▸ "수천 개 청크 + 기존 URL 유지 + 가장 간단·효과적" → 서명된 쿠키를 설정하면 URL을 바꾸지 않고도 여러 청크 접근을 한 번에 인가 (B) 【오답 체크】 (A) 서명된 URL은 청크마다 별도 서명 URL이 필요해 수천 개 청크에 비효율적. (C) Lambda@Edge 토큰 검증은 추가 개발·복잡도가 커서 "가장 간단"에 어긋남(키 페어가 이미 있음). (D) URL을 KMS로 즉석 복호화하는 방식은 콘텐츠 접근 통제 메커니즘이 아니며 비표준. 【시험 포인트】 "다수 파일/청크 접근 보호(URL 유지)" → CloudFront 서명된 쿠키. 단일 파일이면 서명된 URL.

해설

【핵심 용어】 ▸ Secrets Manager 복제(Replicate) — 시크릿을 다른 리전으로 복제, 대상 리전에는 고객 관리형 KMS 키 필요 ▸ 고객 관리형 KMS 키(Customer Managed Key) — 시크릿 복제 암호화에 사용 가능(AWS 관리형 aws/secretsmanager는 복제에 사용 불가) ▸ 지연 최소화·단일 리전 장애 대응 — 각 리전에 로컬 사본 필요 【정답 포인트】 ▸ "양 리전에 시크릿 저장 + 지연 최소화 + 한 리전만 살아도 동작" → us-east-1에서 고객 관리형 키로 암호화한 뒤 us-west-1로 복제하고, 복제본도 고객 관리형 키로 암호화 (D). 리전별 로컬 사본으로 지연·가용성 요건 충족. 【오답 체크】 (A)(B) AWS 관리형 KMS 키는 Secrets Manager 복제 시 사용할 수 없음 → 구성 불가. (B)(C) us-west-1 리소스가 us-east-1 엔드포인트를 호출하면 리전 간 지연 발생 + us-east-1 장애 시 동작 불가 → 요건 위배. 【시험 포인트】 "멀티 리전 시크릿 + 리전 독립 가용성" → 고객 관리형 KMS 키로 암호화 후 Secrets Manager 복제.

해설

【핵심 용어】 ▸ Network ACL(스테이트리스) — CIDR 블록 기준으로 인바운드/아웃바운드를 각각 명시, NACL 자체를 소스로 참조 불가 ▸ 임시 포트(Ephemeral 1024-65535) — 스테이트리스 특성상 응답 트래픽용 아웃바운드 허용 필요 ▸ 3계층 격리 — RDS 서브넷(NACL3)은 앱 서브넷에서만 접근 허용 【정답 포인트】 ▸ "기능 유지하며 보안 강화" → NACL3에 앱 인스턴스 서브넷 CIDR에서 오는 5432 인바운드 허용, 앱 서브넷으로 나가는 1024-65535 아웃바운드(응답) 허용, 전체 허용 기본 규칙 제거 (B) 【오답 체크】 (A) NACL 규칙 소스로 "from NACL2"처럼 다른 NACL을 참조할 수 없음 → CIDR 블록으로 지정해야 함. (C) NACL2 아웃바운드만 5432 허용하고 인바운드 응답(임시 포트)을 막으면 DB 응답이 끊김. RDS 계층(NACL3) 강화가 빠짐. (D) NACL2에 RDS CIDR로부터 5432 인바운드 허용은 방향이 반대(DB→앱이 5432로 들어옴은 비정상). 【시험 포인트】 "NACL 강화" → 스테이트리스이므로 CIDR로 인바운드+응답용 임시 포트 아웃바운드를 함께 허용.

해설

【핵심 용어】 ▸ CloudTrail → S3 배달 — 트레일이 지정한 S3 버킷에 로그를 씀, 버킷 정책에 CloudTrail 쓰기 허용 필요 ▸ S3 버킷 정책 — cloudtrail.amazonaws.com의 s3:PutObject 허용이 있어야 배달 성공 ▸ 유효한 대상 버킷 — 트레일에 지정된 버킷이 실제 존재해야 함 【정답 포인트】 ▸ "CloudTrail이 S3에 이벤트 배달 실패" 초기 점검 → 버킷 정책이 CloudTrail의 객체 쓰기를 허용하는지 확인 (A), 트레일에 지정된 S3 버킷이 실제 존재하는지 확인 (D) 【오답 체크】 (B) CloudWatch Logs 쓰기 권한은 CloudTrail의 선택적 CloudWatch 통합용으로 S3 배달 실패와 무관. (C) Glacier로 아카이브하는 수명 주기 정책은 기존 객체 이동일 뿐 신규 로그 쓰기를 막지 않음. (E) 로그 파일 접두사는 사전에 존재할 필요가 없음(CloudTrail이 생성) → 배달 실패 원인 아님. 【시험 포인트】 "CloudTrail S3 배달 실패" → 버킷 존재 여부 + 버킷 정책의 CloudTrail 쓰기 허용 확인.

해설

【핵심 용어】 ▸ EventBridge 사전 정의 이벤트 "ACM Certificate Approaching Expiration" — ACM이 만료 임박 시 자동 발행하는 이벤트 ▸ ACM — 임포트/관리형 인증서 모두에 대해 만료 임박 이벤트 발행 ▸ SNS 이메일 타깃 — 이벤트를 이메일로 통지 【정답 포인트】 ▸ "인증서 만료 임박 시 이메일 알림 + 가장 운영 효율적" → ACM 사전 정의 패턴의 "ACM Certificate Approaching Expiration" 이벤트로 EventBridge 규칙을 만들고 SNS를 타깃으로 지정 (D). 코드/스케줄 관리 불필요. 【오답 체크】 (A) Lambda로 전 인증서를 순회·describe하는 커스텀 스크립트는 개발·유지보수 부담이 커 운영 효율 낮음. (B) DaysToExpiry 메트릭에 모든 인증서 ARN을 수동 추가하는 방식은 확장성·운영성 나쁨. (C) Security Hub·NotBefore 속성 매칭은 만료(NotAfter/임박) 통지 목적과 맞지 않음. 【시험 포인트】 "ACM 인증서 만료 임박 알림" → EventBridge 사전 정의 "Certificate Approaching Expiration" 이벤트 + SNS.

해설

【핵심 용어】 ▸ CloudTrail 다중 리전 트레일 — 하나의 트레일을 전 리전에 적용, 신규 리전도 자동 포함 ▸ 단일 S3 버킷 — 모든 리전 로그를 중앙 저장·보존 ▸ 중앙 집중 API 활동 기록 — 현재·미래 리전 모두 커버 【정답 포인트】 ▸ "현재·미래 전 리전 API 활동을 중앙 기록·보존 + 가장 단순" → 전 리전 적용 트레일을 하나 만들고 단일 S3 버킷을 저장소로 지정 (C). 신규 리전도 자동 포함. 【오답 체크】 (A) Trusted Advisor는 권고 점검 도구로 API 활동 기록·보존 용도가 아님. (B) 리전마다 개별 트레일을 만드는 방식은 복잡하고 신규 리전 자동 포함이 안 됨. (D) CloudWatch 로깅을 전 서비스에 켜서 집계하는 방식은 API 호출 감사(CloudTrail)의 대체가 아니며 복잡. 【시험 포인트】 "전 리전 API 감사 중앙화(현재+미래)" → 전 리전 적용 CloudTrail 트레일 하나 + 단일 S3 버킷.

해설

【핵심 용어】 ▸ CloudWatch Agent — EC2 로컬 로그를 CloudWatch Logs로 스트리밍, 인스턴스 종료와 무관하게 보존 ▸ Auto Scaling scale-in — 인스턴스 종료 시 로컬(EBS) 로그 유실 위험 ▸ CloudWatch Logs 보존 정책 — 1년 이상 보존 설정 가능 【정답 포인트】 ▸ "scale-in으로 로그 유실 + 내구성/가용성 + 1년 보존" → AMI에 CloudWatch Agent를 넣어 로그를 실시간으로 CloudWatch Logs로 전송 (C). 인스턴스가 사라져도 로그는 중앙에 남음. 【오답 체크】 (A) 종료 시 EBS 볼륨을 재부착하는 방식은 수작업·복잡하고 자동 내구성 확보가 아님. (B) 하루 한 번 EFS로 복사하면 마지막 복사 이후 로그가 유실될 수 있고 구성이 복잡. (D) 종료 대기 훅으로 1시간 수동 검토는 자동 내구성 보존책이 아니며 확장성 나쁨. 【시험 포인트】 "인스턴스 로컬 로그 유실 방지·중앙 보존" → CloudWatch Agent → CloudWatch Logs.

해설

【핵심 용어】 ▸ AWS Backup — EC2·S3 등 다양한 리소스의 중앙화된 정책 기반 백업, 스케줄(예: 시간당) 지원 ▸ RPO 1시간 — 최대 1시간 데이터 손실 허용 → 최소 시간당 백업 필요 ▸ IaC 재구성 — CloudFormation 템플릿을 CodeCommit에 보관해 아키텍처 신속 복구 【정답 포인트】 ▸ "랜섬웨어 대비 DR + RPO 1시간" → AWS Backup으로 EC2·S3를 시간당 백업하고, CloudFormation 템플릿으로 아키텍처를 재현, CodeCommit에 코드와 함께 보관 (A) 【오답 체크】 (B) 매일 백업은 RPO 1시간을 충족 못 함. Security Lake는 로그 분석용으로 복구책이 아님. (C) Security Lake·Security Hub는 탐지·분석 중심으로 RPO 1시간 백업 복구를 제공하지 않음. (D) 4시간 주기 스냅샷은 RPO 1시간 위배. GuardDuty finding 기반 자동 복원은 데이터 백업 주기 요건과 별개. 【시험 포인트】 "RPO 1시간 DR" → 시간당 백업 필요 → AWS Backup 시간당 + IaC 재구성.

해설

【핵심 용어】 ▸ 포렌식 증거 보존 순서 — 격리 → 휘발성(메모리) → 비휘발성(디스크) 순, 실행 중 상태 보존 ▸ ASG 분리·ALB 등록 해제 — 인스턴스를 격리해 스케일링·트래픽 영향 차단(종료 방지) ▸ 메모리 스냅샷 vs EBS 스냅샷 — 메모리는 인스턴스 실행 중 확보, 중지 전 수집 【정답 포인트】 ▸ "포렌식 증거 보존" → ①ASG에서 분리 ②ALB에서 등록 해제(격리) ③EBS 볼륨 스냅샷 ④메모리 스냅샷 ⑤인스턴스 중지 순 (C). 먼저 격리해 인스턴스가 종료/교체되지 않게 하고, 중지 전에 증거를 확보. 【오답 체크】 (A) 격리(ASG 분리·ALB 해제)보다 스냅샷을 먼저 하면 ASG가 인스턴스를 종료·교체해 증거가 사라질 수 있음. (B) 격리 전에 중지하고 스냅샷을 뒤늦게 하며, ASG 분리도 뒤로 밀려 순서가 부적절. (D) 격리 후 곧바로 중지하면 휘발성 메모리 증거 확보 전에 상태가 손실될 위험. 【시험 포인트】 "포렌식 순서" → 먼저 격리(ASG 분리·ALB 해제) → 스냅샷 확보 → 마지막에 중지.

해설

【핵심 용어】 ▸ CloudFront용 ACM 인증서 — 반드시 us-east-1 리전에서 발급받아야 함 ▸ ACM DNS 검증 — 도메인 DNS 존에 CNAME 레코드 삽입, 자동 갱신 무기한 지원(이메일 검증은 갱신 제약) ▸ CloudFront 대체 도메인 이름(Alternate Domain Names) — 커스텀 기본 도메인 + 여러 대체 도메인 【정답 포인트】 ▸ "AWS 관리형 배포/캐싱(CloudFront) + 자동 무기한 갱신 + 커스텀·대체 도메인" 조합: ▸ us-east-1에서 인증서 발급(CloudFront 요건) (F) ▸ DNS 검증으로 CNAME 레코드 삽입(자동 갱신 보장) (C) ▸ CloudFront 배포 생성 후 대체 도메인 이름 설정 + ACM 인증서 지정 (E) 【오답 체크】 (A) CloudFront 인증서는 us-west-2가 아니라 us-east-1에서 발급해야 함. (B) 이메일 검증은 무기한 자동 갱신을 보장하지 못함 → DNS 검증 사용. (D) ALB는 문제의 "AWS 관리형 배포·캐싱 + PoP 최적화" 요구(=CloudFront)에 맞지 않음. 【시험 포인트】 "CloudFront 인증서" → us-east-1 발급 + DNS 검증(자동 갱신) + 대체 도메인 설정.

해설

【핵심 용어】 ▸ Security Hub 통합 — GuardDuty·IAM Access Analyzer·Macie findings를 표준화해 한곳에 수집 ▸ EventBridge Security Hub Findings 이벤트 — findings를 심각도 등으로 필터해 SNS 등으로 라우팅 ▸ 최소 운영 부담 — Security Hub가 이미 통합 수집 중이므로 단일 규칙으로 처리 【정답 포인트】 ▸ "GuardDuty·Access Analyzer·Macie의 고심각도 finding 이메일 알림 + 최소 운영 부담" → Security Hub가 이미 세 서비스 findings를 모으므로, 고심각도 Security Hub findings를 매칭하는 EventBridge 규칙 하나로 SNS 이메일 발송 (B) 【오답 체크】 (A) 서비스별 Lambda를 각각 만들어 API 폴링하는 방식은 개발·운영 부담이 큼. (C) Control Tower 이벤트에는 이들 보안 서비스의 finding 심각도가 담기지 않음. (D) EC2에서 API를 호출하는 커스텀 앱은 인프라·운영 부담이 크고 비효율. 【시험 포인트】 "여러 보안 서비스 findings 통합 알림" → Security Hub findings + 단일 EventBridge 규칙 + SNS.

해설

【핵심 용어】 ▸ Gateway VPC Endpoint — S3·DynamoDB 전용, 라우팅 기반 프라이빗 접근 ▸ Interface VPC Endpoint(PrivateLink) — SQS 등 서비스용 ENI 기반 프라이빗 접근 ▸ 엔드포인트 정책(Endpoint Policy) — 엔드포인트로 접근 가능한 리소스를 최소 권한으로 제한 【정답 포인트】 ▸ "AWS 서비스로 프라이빗 연결 + 최소 권한" 조합: ▸ SQS는 Interface 엔드포인트로 프라이빗 접근 (A) ▸ S3는 Gateway 엔드포인트로 프라이빗 접근 (C) ▸ 엔드포인트 정책에서 애플리케이션이 쓰는 특정 SQS·S3 리소스만 지정(최소 권한) (E) 【오답 체크】 (B)(F) Transit Gateway·Firewall Manager는 S3 프라이빗 접근 수단이 아님(S3는 Gateway 엔드포인트). (D) IAM 역할은 네트워크 아웃바운드 트래픽을 제어하지 않음(엔드포인트로의 접근은 보안 그룹/라우팅이 담당). 【시험 포인트】 "프라이빗 연결" → S3=Gateway, SQS=Interface, 최소 권한은 엔드포인트 정책으로 리소스 제한.