정답 · 해설

해설

【핵심 용어】 ▸ AWS Config rules — 리소스 구성의 규정 준수 여부를 지속 평가(예: encrypted-volumes, ec2 public IP) ▸ AWS Systems Manager Automation — 미준수 리소스에 대한 자동 수정(remediation) 실행 ▸ Config 자동 수정 — Config 규칙 + SSM Automation 문서 연계로 탐지+교정을 관리형으로 처리 【정답 포인트】 ▸ "미암호화 EBS + 퍼블릭 IP 예방·교정" + "최소 노력" → Config 관리형 규칙으로 탐지 + SSM Automation으로 자동 교정 ▸ 커스텀 코드 없이 관리형 구성만으로 완성 → B가 정답 【오답 체크】 (A) CloudTrail은 API 이벤트 로그일 뿐 구성 준수 평가 도구가 아니며 Lambda 커스텀 개발 필요. (C) GuardDuty는 위협 탐지용으로 구성 미준수(미암호화 볼륨 등) 평가에 부적합 + Lambda 개발 부담. (D) SSM Compliance는 패치/연결 상태 중심으로 EBS 암호화·퍼블릭 IP 준수 평가 용도가 아님. 【시험 포인트】 구성 준수 탐지 → AWS Config 규칙, 자동 교정 → SSM Automation. "최소 노력"이면 관리형 규칙 조합.

해설

【핵심 용어】 ▸ EBS 기본 암호화(default encryption) — 리전 단위 설정, 활성화 후 신규 볼륨 자동 암호화 ▸ Auto Scaling instance refresh — 기존 인스턴스를 순차 교체해 새 설정(암호화 볼륨) 반영 ▸ Aurora 암호화 — 기존 클러스터는 in-place 암호화 불가, 암호화 스냅샷에서 새 클러스터 생성 필요 【정답 포인트】 ▸ EC2 계층: (A) 리전 EBS 기본 암호화 활성화 + Auto Scaling instance refresh로 새 암호화 볼륨 인스턴스로 교체 ▸ DB 계층: (C) 기존 DB 스냅샷으로부터 KMS 암호화된 새 Aurora 클러스터 생성 → 저장 시 암호화 달성 【오답 체크】 (B) ACM은 TLS 인증서용이며 EBS 볼륨 암호화 수단이 아님(EBS는 KMS). (D) 기존 DB 클러스터에 암호화를 직접 적용(in-place) 불가 — 스냅샷 재생성 필요. (E) ACM으로 DB 클러스터 저장 암호화를 적용할 수 없음(KMS 사용). 【시험 포인트】 EBS 저장 암호화 = 리전 기본 암호화 + instance refresh. RDS/Aurora 기존 클러스터 암호화 = 암호화 스냅샷에서 새 클러스터 생성. 암호화는 항상 KMS(ACM 아님).

해설

【핵심 용어】 ▸ AWS PrivateLink / VPC endpoint — VPC 간 프라이빗 연결, 인터넷·NAT 없이 서비스 접근 ▸ 퍼블릭 접근 금지 정책 — DB가 인터넷/NAT IP 경로로 노출되면 안 됨 ▸ NAT gateway IP 허용 — 현재 구성은 퍼블릭 경로 노출로 보안 정책 위반 【정답 포인트】 ▸ Lambda VPC에서 Aurora VPC의 DB로 퍼블릭 노출 없이 접근 → VPC endpoint(PrivateLink) 기반 프라이빗 연결 ▸ Aurora VPC에 서비스 엔드포인트, Lambda VPC에 인터페이스 엔드포인트를 구성해 Lambda만 허용 → B가 가장 안전 【오답 체크】 (A) DB를 프라이빗 서브넷으로 옮겨도 서로 다른 VPC 간 라우팅/피어링 문제는 해결되지 않고 여전히 크로스 VPC 접근 미해결. (C) VPC 간에는 Direct Connect를 쓰지 않음(온프레미스-AWS 연결용), 개념 부적합. (D) Lambda를 퍼블릭 서브넷에 두고 퍼블릭 IP 허용은 퍼블릭 노출로 보안 정책 위반. 【시험 포인트】 퍼블릭 노출 없이 VPC 간 서비스 접근 → PrivateLink(인터페이스 VPC 엔드포인트). DB의 퍼블릭 IP/NAT 경로 허용은 정책 위반.

해설

【핵심 용어】 ▸ Network ACL — 서브넷 단위 stateless 방화벽, 반환 트래픽을 위해 ephemeral 포트 아웃바운드 명시 필요 ▸ Security Group — stateful, 인바운드 허용 시 반환 트래픽 자동 허용(아웃바운드 별도 불필요) ▸ Ephemeral ports — 외부 클라이언트로 돌아가는 응답이 사용하는 임시 포트 범위 【정답 포인트】 ▸ SG·NACL 인바운드는 이미 허용했는데 접속 불가 → stateless NACL의 아웃바운드(반환) 규칙 누락이 원인 ▸ 해당 CIDR NACL에 ephemeral 포트로 나가는 아웃바운드 허용 추가 → B가 정답 【오답 체크】 (A) SG는 stateful이라 인바운드 허용 시 반환 자동 처리, 아웃바운드=인바운드 규칙 복사는 불필요하며 원인 아님. (C) 인터넷 게이트웨이에는 인바운드 규칙(포트 허용) 개념이 없음. (D) 아웃바운드를 인바운드와 동일 규칙으로 두면 서비스 포트만 열리고 응답용 ephemeral 포트가 빠져 여전히 실패. 【시험 포인트】 SG는 통되는데 NACL에서 막히면 → stateless NACL의 ephemeral 포트 아웃바운드(반환 트래픽) 확인.

해설

【핵심 용어】 ▸ Amazon SQS resource policy — 큐 접근 제어, aws:SourceVpce, aws:PrincipalOrgId 등 조건 지원 ▸ Interface VPC endpoint (PrivateLink) — SQS를 VPC 내에서 프라이빗 접근, 엔드포인트 정책 부착 가능 ▸ aws:PrincipalOrgId / aws:SourceVpce — 조직 소속·특정 엔드포인트 경유만 허용하는 조건 키 【정답 포인트】 ▸ 예상치 못한 주체의 SQS 접근 차단 + AWS 외부 도구 투자 최소화 → 각 VPC에 SQS 인터페이스 엔드포인트 생성 ▸ SQS 정책에 aws:SourceVpce로 엔드포인트 경유만, 엔드포인트 정책에 aws:PrincipalOrgId로 조직 주체만 허용 → C가 정답 【오답 체크】 (A) Security Group은 SQS 큐에 연결할 수 없음. (B) Network ACL은 서브넷 트래픽용이며 SQS 접근 제어 수단이 아님. (D) CASB는 AWS 외부 서드파티 도구로 "AWS 외 투자 최소화" 요구에 반함. 【시험 포인트】 SQS 등 서비스 접근을 조직·특정 VPC로 제한 → 인터페이스 엔드포인트 + aws:SourceVpce/aws:PrincipalOrgId 조건. SG/NACL은 큐에 적용 불가.

해설

【핵심 용어】 ▸ AWS WAF rate-based rule — 5분 창 내 IP별 요청 수를 추적해 임계값 초과 시 차단 ▸ ALB 앞단 WAF — 웹 요청을 애플리케이션 도달 전 검사·제한, 관리형으로 최소 노력 ▸ 요청 속도 제한 — 클라이언트 IP별 read 횟수 제한 요구에 부합 【정답 포인트】 ▸ "IP별 5분간 N회 제한" + "최소 노력" → ALB 앞 WAF의 rate-based(속도 기반) 규칙으로 초과 IP 차단 ▸ 관리형 규칙 하나로 스캐닝·DDoS 완화 → A가 정답 【오답 체크】 (B) CloudWatch+Lambda 카운팅은 알림만 하고 실제 차단·제한을 자동 수행하지 않으며 개발 부담 큼. (C) EC2 애플리케이션 코드에 카운팅 로직 구현은 상당한 개발·운영 부담. (D) DynamoDB TTL + read capacity 조정은 IP별 속도 제한 메커니즘이 아니며 요구 미충족. 【시험 포인트】 IP별 요청 속도 제한 + 최소 노력 → WAF rate-based rule. 커스텀 Lambda/코드/DB TTL은 과한 노력.

해설

【핵심 용어】 ▸ Virtual Private Gateway (VGW) — VPC 측 Site-to-Site VPN 종단점, 라우트 대상으로 지정 ▸ Route Table 라우트 대상 — 데이터센터 CIDR을 VGW로 향하게 해 VPN 터널 경유 ▸ Customer Gateway — 온프레미스 측 장비로, VPC 라우트 테이블의 대상(target)이 될 수 없음 【정답 포인트】 ▸ VPC→데이터센터 트래픽이 공용 인터넷을 타지 않도록 → 데이터센터 CIDR을 VGW(VPN)로 라우팅 ▸ (C) 퍼블릭 서브넷 라우트 테이블 + (E) 프라이빗 서브넷 라우트 테이블 모두 데이터센터 CIDR을 VGW로 지정 → VPN 경유 【오답 체크】 (A) 퍼블릭 서브넷 default route를 NAT로 바꿔도 여전히 인터넷 경유, VPN 미사용. (B)(D) Customer Gateway는 온프레미스 장비로 VPC 라우트 테이블의 target이 될 수 없음(대상은 VGW). 【시험 포인트】 VPC에서 온프레미스로 인터넷을 우회해 VPN으로 보내려면 → 데이터센터 CIDR을 Virtual Private Gateway로 라우팅(모든 관련 서브넷 라우트 테이블에).

해설

【핵심 용어】 ▸ EventBridge 사전 정의 패턴(ACM) — "ACM Certificate Approaching Expiration" 이벤트를 자동 발생 ▸ ACM 만료 임박 이벤트 — 관리형·가져온 인증서 모두에 대해 만료 접근 시 EventBridge로 통지 ▸ Amazon SNS — 이벤트 대상으로 이메일 알림 발송 【정답 포인트】 ▸ "인증서 만료 임박 이메일 알림" + "운영 효율 최대" → ACM용 EventBridge 사전 정의 패턴으로 만료 임박 이벤트 캡처 → SNS로 이메일 ▸ 커스텀 코드 없이 관리형 이벤트로 처리 → D가 정답 【오답 체크】 (A) Lambda로 인증서를 순회·필터링하는 방식은 코드 작성·유지 부담으로 운영 효율 낮음. (B) CloudWatch DaysToExpiry는 ARN 수동 추가·관리 부담이 크고 가져온 인증서 처리에 한계. (C) Security Hub의 NotBefore 속성은 만료(NotAfter)와 무관한 필드, 요구와 어긋남. 【시험 포인트】 ACM 인증서 만료 임박 알림 → EventBridge 사전 정의 패턴(ACM Certificate Approaching Expiration) + SNS. 관리형 이벤트가 가장 효율적.

해설

【핵심 용어】 ▸ Amazon GuardDuty — 관리형 위협 탐지(IDS 역할), VPC Flow Logs·DNS·CloudTrail을 자동 분석 ▸ CloudTrail + VPC Flow Logs(all traffic) — GuardDuty 및 침입 탐지 커버리지를 위한 로그 소스 ▸ EventBridge → SNS — GuardDuty finding을 이메일 배포 그룹으로 전달 【정답 포인트】 ▸ IDS 커버리지 최대화 → (A) CloudTrail 관리 이벤트+S3 데이터 이벤트+모든 트래픽 VPC Flow Logs로 가시성 확보 ▸ (C) GuardDuty 구성 + EventBridge 규칙으로 finding을 SNS 토픽에 전달해 이메일 알림 → A,C가 정답 【오답 체크】 (B) Flow Logs를 accepted 트래픽만 캡처하면 거부/이상 트래픽을 놓쳐 커버리지 축소. (D) Security Hub는 finding 집계 도구로 IDS 탐지 엔진 자체가 아니며 커버리지 극대화 요구와 결이 다름. (E) Lambda로 ACCEPT 필터만 분석하면 커버리지가 제한되고 커스텀 부담 큼. 【시험 포인트】 관리형 IDS = GuardDuty(+로그 소스 최대 활성화), 알림 = EventBridge→SNS. 커버리지 최대화면 all traffic Flow Logs.

해설

【핵심 용어】 ▸ AWS WAF rate-based rule — IP별 요청 속도를 추적, 임계값 초과 IP를 자동 차단(동적 IP 대응) ▸ 변화하는 IP 대역 — 정적 IP 차단으로는 대응 불가, 속도 기반 동적 차단 필요 ▸ GuardDuty/Inspector — 탐지 서비스로, 요청 속도 기반 차단 규칙을 직접 제공하지 않음 【정답 포인트】 ▸ "IP별 요청 속도 추적 후 초과 시 트래픽 제한" + "IP가 계속 바뀜" → WAF rate-based 규칙으로 임계값 초과 IP 동적 차단 → B가 정답 【오답 체크】 (A) Inspector는 취약점 평가 서비스로 rate 기반 IP 차단 기능이 없음. (C) 정적(regular) 규칙은 고정 IP 대역 차단용이라 계속 바뀌는 IP에 대응 불가. (D) GuardDuty에는 rate-based 차단 규칙 기능이 없음(위협 탐지 전용). 【시험 포인트】 요청 속도 기반 동적 IP 차단 → WAF rate-based rule. IP가 계속 바뀌면 정적 IP 차단은 부적합.

해설

【핵심 용어】 ▸ 노출된 액세스 키 대응 — 유출 키 즉시 비활성화·순환(rotate)이 최우선 ▸ IAM 자격 증명 정리 — 무단 생성 IAM 사용자 삭제, 나머지 사용자 비밀번호 변경 ▸ 침해 계정 복구 순서 — 자격 증명 무효화 → 무단 주체 제거 【정답 포인트】 ▸ 공개 저장소에 액세스 키 유출 → (A) 침해 계정의 모든 액세스 키 쌍 순환으로 유출 키 무효화 ▸ (E) 무단 생성된 IAM 사용자 삭제 + 나머지 IAM 사용자 비밀번호 변경으로 침입자 접근 차단 → A,E가 정답 【오답 체크】 (B) 인터넷 차단 SG를 모든 EC2에 붙이면 정상 서비스까지 중단, 자격 증명 침해 대응 본질과 무관. (C) 조직에서 계정을 일시 제거해도 계정 내 유효 자격 증명은 그대로라 보안 확보 안 됨. (D) EC2 키 페어(SSH용) 삭제는 유출된 것은 IAM 액세스 키이므로 핵심 대응이 아님. 【시험 포인트】 액세스 키 유출 = 즉시 키 순환/무효화 + 무단 IAM 주체 제거·자격 증명 재설정. SSH 키 페어와 IAM 액세스 키를 혼동하지 말 것.

해설

【핵심 용어】 ▸ 포렌식 증거 보존 — 조사 전 인스턴스·볼륨 상태를 훼손 없이 보존하는 것이 원칙 ▸ Termination protection — 인스턴스 실수 종료 방지, 증거 보존을 위해 활성화 ▸ EBS 스냅샷 + 격리 태그 — 볼륨 스냅샷으로 증거 보존, 메타데이터 수집 후 quarantine 태그 【정답 포인트】 ▸ 조사 착수 전 증거 보존 단계 → (B) termination protection 활성화(실수 종료 방지) + (C) EBS 데이터 볼륨 스냅샷 + (E) 인스턴스 메타데이터 수집 후 quarantine 태그 → B,C,E가 정답 【오답 체크】 (A) termination protection을 비활성화하면 실수 종료 위험 증가, 증거 보존 원칙에 반함. (D) EBS 스냅샷을 제거하면 증거를 파괴 — 정반대 조치. (F) 메타데이터의 민감 정보를 삭제하면 조사에 필요한 증거를 훼손. 【시험 포인트】 침해 인스턴스 조사 전 = 증거 보존(termination protection ON, EBS 스냅샷, 메타데이터 수집·격리 태그). 삭제·비활성화는 증거 훼손.

해설

【핵심 용어】 ▸ Instance profile / IAM role — EC2에 부여된 권한, S3 접근은 role 정책으로 결정 ▸ s3:ListBucket vs s3:GetObject — 목록 조회는 List, 객체 읽기는 GetObject 권한 필요 ▸ 동일 계정 접근 — 같은 계정 내 IAM 권한만으로 S3 접근 충분(버킷 정책 불필요) 【정답 포인트】 ▸ 목록은 되는데 읽기 불가 → GetObject(읽기) 권한 부족 → 인스턴스 role에 GetObject를 허용하는 IAM 정책 추가 → B가 정답 ▸ (같은 계정이므로 role 정책에 읽기 권한만 보강하면 접근 가능) 【오답 체크】 (A) s3:GetObjectVersion은 버전 조회용으로 기본 객체 읽기(GetObject) 부재 문제를 해결하지 못함. (C) 동일 계정에서는 IAM 정책만으로 충분하며 버킷 정책 추가는 불필요(least 접근 원칙에도 어긋남). (D) bucket-owner-full-control ACL은 쓰기 시 소유권 관련 설정으로 읽기 실패 원인과 무관. 【시험 포인트】 "list는 되는데 read 불가" → s3:GetObject 권한 누락. 동일 계정이면 IAM 정책 보강으로 해결(버킷 정책 불필요).

해설

【핵심 용어】 ▸ 옵트인 리전(me-south-1 등) — 기본 비활성, 활성화해도 STS 글로벌 토큰이 기본으론 유효하지 않을 수 있음 ▸ AWS STS 리전 엔드포인트 — 해당 리전 엔드포인트에서 발급받은 토큰은 그 리전에서 유효 ▸ STS 글로벌 엔드포인트 토큰 버전 — 모든 리전 호환 세션 토큰을 발급하도록 설정 가능 【정답 포인트】 ▸ 새 리전 API 호출 시 자격 증명 검증 실패 → (B) me-south-1의 STS 리전 엔드포인트에서 토큰 획득 ▸ (E) STS 글로벌 엔드포인트를 리전 호환 세션 토큰 발급 방식으로 변경 → 옵트인 리전에서도 유효 → B,E가 정답 【오답 체크】 (A) iam:SetSecurityTokenServicePreferences는 계정 설정 액션이지만 개별 IAM role에 부여해 해결하는 방식이 아님. (C) us-east-1 글로벌 엔드포인트의 기본 토큰은 옵트인 리전에서 기본적으로 유효하지 않아 실패 재현. (D) me-south-1의 STS 엔드포인트를 "수동 활성화"하는 별도 액션은 해결책으로 부적합. 【시험 포인트】 옵트인 리전 AuthFailure → 해당 리전 STS 리전 엔드포인트 사용, 또는 글로벌 STS 토큰을 모든 리전 유효(valid in all regions)로 설정.

해설

【핵심 용어】 ▸ ABAC(속성 기반 접근 제어) — 태그 기반 권한 분리, 팀별 워크로드 접근을 태그 조건으로 제어 ▸ Cost allocation tags — 태그 기반 세분화 비용 청구 ▸ 단일 계정 유지 — 계정 분할/마이그레이션 없이 운영 효율 극대화 【정답 포인트】 ▸ 단일 계정 내에서 팀 격리 + 자기 워크로드만 접근 + 세분 청구 → (A) ABAC 태깅 전략으로 팀 분리 + cost allocation tags로 세분 청구 ▸ 마이그레이션 없이 가장 운영 효율적 → A가 정답 【오답 체크】 (B) RBAC 태깅은 역할 수 증가로 확장성·운영성이 ABAC보다 떨어짐(태그 기반 동적 분리가 더 효율적). (C) Control Tower로 계정 2개 생성 후 마이그레이션은 운영 부담이 크고 "가장 효율적"과 거리 있음. (D) Application B만 새 계정으로 이전하는 것도 마이그레이션 부담이 큼. 【시험 포인트】 단일 계정에서 팀/워크로드 격리 + 최소 운영 → ABAC(태그 기반) + cost allocation tags. 계정 분할·마이그레이션은 무거운 선택.

해설

【핵심 용어】 ▸ Imported key material — 고객이 키 자료를 KMS로 가져오기, 사본 유지·재가져오기 가능, 만료 기간(expiration) 설정 시 만료되면 AWS가 자동 삭제 ▸ AWS managed keys — 삭제 대기 기간 적용, 세밀한 만료 제어 불필요한 Set 2에 적합 ▸ 키 삭제 대기 기간 — CMK 삭제 예약 시 7~30일 대기(14일 수용 가능) 【정답 포인트】 ▸ Set 1(사본 유지·재가져오기·3일 만료) → imported key material, 만료 기간 설정 시 AWS가 만료 후 자동 삭제 ▸ Set 2(즉시 삭제 제한 없음, 14일 대기 수용) → AWS managed keys → B가 정답 【오답 체크】 (A) imported 키의 만료 기간이 지나면 AWS가 자동 삭제 — "수동 삭제"는 불필요하고 요구와 어긋남. (C)(D) Set 1/Set 2가 뒤바뀜: 재가져오기·세밀한 만료 제어가 필요한 Set 1은 AWS managed가 아니라 imported 키여야 함. 【시험 포인트】 키 자료 사본 유지·재가져오기·짧은 만료 제어 → imported key material(만료 시 AWS 자동 삭제). 표준 삭제 대기로 충분하면 AWS managed keys.

해설

【핵심 용어】 ▸ AWS managed key — 크로스 계정 공유·스냅샷 복사 암호화에 사용 불가, 커스텀 KMS 키 필요 ▸ Customer managed KMS key — 키 정책·grant로 크로스 계정 권한 부여 가능 ▸ 스냅샷 크로스 계정 복사 — 원본 스냅샷을 커스텀 키로 재암호화해야 다른 계정으로 복사 가능 【정답 포인트】 ▸ AWS managed key 암호화 스냅샷은 크로스 계정 복사 불가 → (B) 대상 계정에 customer managed KMS 키 생성 + 자동화 role에 KMS 권한 ▸ (D) 보안팀 계정 role에 customer managed 키에 대한 KMS 권한 + (F) 자동화 코드가 customer managed 키로 스냅샷 생성 → B,D,F가 정답 【오답 체크】 (A) AWS managed key는 키 정책 수정 자체가 불가(고객이 편집 불가)해 이 경로로 해결 못 함. (C) 보안팀 계정에서 AWS managed key에 대해 권한을 부여해도 크로스 계정 공유 불가. (E) AWS managed key로 스냅샷을 만들면 크로스 계정 복사가 되지 않음 — customer managed 키여야 함. 【시험 포인트】 크로스 계정 스냅샷 복사·공유 = customer managed KMS 키 필수. AWS managed key는 크로스 계정 grant/공유 불가.

해설

【핵심 용어】 ▸ Secrets Manager 자동 순환 — 지원 DB(DocumentDB 포함)는 순환 활성화 시 Secrets Manager가 순환 Lambda를 자동 생성 ▸ 순환 Lambda 자동 생성 — 콘솔에서 순환 켜면 관리형 템플릿 기반 함수 자동 구성 ▸ DocumentDB 자격 증명 순환 — 내장 통합으로 최소 관리 부담 【정답 포인트】 ▸ "자동 비밀번호 순환" + "최소 관리 부담" → Secrets Manager 순환 활성화 시 Secrets Manager가 순환 Lambda를 자동 생성하도록 구성 → B가 정답 【오답 체크】 (A) Lambda를 직접 새로 만들어 연결하는 것은 불필요한 수작업, Secrets Manager가 자동 생성 가능. (C) SAM 템플릿으로 Lambda를 수동 생성·VPC 구성하는 것은 관리 부담 증가. (D) createSecret/setSecret/testSecret 세 함수를 수동 생성·구성하는 것은 가장 큰 수작업. 【시험 포인트】 Secrets Manager + 지원 DB 자동 순환 → 순환 켜고 Secrets Manager가 Lambda 자동 생성. 최소 부담이면 수동 Lambda 작성 피함.

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — 조직 전체/OU에 걸쳐 액션을 일괄 제한, 대규모 계정에 확장성 높음 ▸ s3:DeleteBucket 차단 — 모든 계정에서 버킷 삭제를 방지하는 조직 가드레일 ▸ 확장성 — 계정 수백 개에도 SCP 하나로 통일 적용 【정답 포인트】 ▸ "조직 전체에서 S3 버킷 삭제 금지" + "가장 확장성 있는" → 조직/OU에 SCP로 s3:DeleteBucket Deny → D가 정답 【오답 체크】 (A) Permissions boundary는 개별 IAM 주체마다 부착·관리해야 해 대규모에서 확장성 낮음. (B) 버킷 정책은 버킷마다 개별 설정해야 해 수백 계정·다수 버킷에 비효율. (C) Tag policy는 태그 표준화용이며 삭제 방지 기능이 아님. 【시험 포인트】 조직 전반 액션 금지 + 확장성 → SCP. 개별 버킷/주체 단위(버킷 정책·permissions boundary)는 대규모에 부적합.

해설

【핵심 용어】 ▸ Gateway VPC endpoint (S3) — 라우트 테이블에 prefix list 라우트를 추가해야 트래픽이 엔드포인트로 향함 ▸ 라우트 테이블 연결 — 게이트웨이 엔드포인트를 서브넷 라우트 테이블에 연결해야 S3 트래픽이 엔드포인트 경유 ▸ NAT vs Gateway endpoint 우선순위 — 엔드포인트 prefix list 라우트가 더 구체적이라 우선 적용 【정답 포인트】 ▸ Lambda가 S3에 NAT로 나가는 이유 = 게이트웨이 엔드포인트가 해당 서브넷 라우트 테이블에 미연결 ▸ 게이트웨이 VPC 엔드포인트를 Lambda 서브넷의 라우트 테이블에 연결하면 S3 트래픽이 엔드포인트 경유 → B가 정답 【오답 체크】 (A) NAT 라우트를 제거하면 같은 서브넷의 다른 리소스 인터넷 접근이 끊김, 부작용 큼. (C) 게이트웨이 엔드포인트 정책은 접근 허용 범위일 뿐 트래픽 경로를 라우팅하지 않음. (D) 보안 그룹은 S3 게이트웨이 엔드포인트 경로 선택과 무관. 【시험 포인트】 게이트웨이 VPC 엔드포인트가 동작하려면 → 대상 서브넷의 라우트 테이블에 엔드포인트 연결(prefix list 라우트 추가). 이 라우트가 NAT보다 우선.