정답 · 해설

해설

【핵심 용어】 ▸ AWS Global Accelerator — 애니캐스트 IP + AWS 백본으로 first-byte 지연·지터 최소화, TCP/UDP 지원 ▸ Traffic dial — 엔드포인트 그룹(리전)별 트래픽 비율 조절, 점진적 롤아웃에 사용 ▸ NLB 등록 — Global Accelerator 엔드포인트 그룹에 리전별 NLB 등록 【정답 포인트】 ▸ "UDP+TCP 지원" + "리전별 트래픽 비율 제어" + "first-byte 지연·지터 최소" → Global Accelerator + 리스너(포트) + 리전별 엔드포인트 그룹 + traffic dial ▸ AWS 글로벌 백본으로 지연·지터 감소, traffic dial로 신규 리전 롤아웃 트래픽 제어 【오답 체크】 (A),(D) CloudFront는 HTTP(S) 캐싱 중심이라 UDP 미지원, Route 53 라우팅은 지터 최소화·정밀 트래픽 비율 제어에 Global Accelerator보다 부적합. (C) S3 Transfer Acceleration은 S3 업로드 가속 전용, 애플리케이션 트래픽 라우팅과 무관. 【시험 포인트】 "TCP+UDP + 지연·지터 최소 + 리전 트래픽 제어" → Global Accelerator + traffic dial.

해설

【핵심 용어】 ▸ ALB 리스너 규칙 — path-pattern, source-ip 등 조건으로 대상 그룹 라우팅, 우선순위 기반 평가 ▸ source-ip 조건 — 클라이언트 원본 IP 기준 접근 제한(온프레미스 IP만 관리 앱 접근) ▸ 대상 그룹 stickiness — stateful 관리 앱 세션 고정에 필요 【정답 포인트】 ▸ (A) HTTPS 리스너에 규칙 삽입: /management path-pattern + 온프레미스 source-ip 조건 일치 시 관리 앱 대상 그룹으로 포워딩, 관리 앱 대상 그룹 stickiness 활성화(stateful) ▸ (E) 기본은 모든 요청을 웹 앱 대상 그룹으로 포워딩하고 웹 앱 대상 그룹은 stateless라 stickiness 비활성화 【오답 체크】 (B) 기본 규칙 수정 + "일치하지 않으면 관리 앱으로"는 로직 반대, 위험. (C) source-ip 대신 X-Forwarded-For 헤더 검사는 ALB source-ip 조건보다 위조 취약·부적합. (D) 기본 규칙에 조건 매칭 후 웹 앱으로 보내는 구성은 관리 앱 라우팅을 못 함. 【시험 포인트】 "동일 URL/path 분기 + 출발지 IP 제한" → 리스너 규칙(path-pattern + source-ip) 삽입.

해설

【핵심 용어】 ▸ 점보 프레임(jumbo frames) — MTU 9001, VPC 내부·DX에선 지원되나 인터넷/일부 경로에선 미지원 ▸ Don't Fragment (DF) 플래그 — 패킷 분할 금지, MTU 초과 시 ICMP "Fragmentation Needed" 필요(Path MTU Discovery) ▸ ICMP 차단 — DF 패킷의 PMTUD가 ICMP에 의존, 차단 시 대형 패킷 블랙홀 【정답 포인트】 ▸ "작은 UI(1024B)는 항상 접근되나 대형 파일(>1024MB) 전송 실패" → 대형 패킷 MTU 문제 ▸ (C) 공용 인터넷 경로는 점보 프레임 미지원 → DF 세트 대형 패킷이 통과 못 함 ▸ (D) SG가 ICMP를 차단하면 PMTUD 실패로 DF 패킷이 조용히 드롭됨 【오답 체크】 (A) DX는 점보 프레임(대형 MTU) 지원 가능해 대형 파일 전송 실패 원인으로 부적합. (B) Site-to-Site VPN 경로는 소형 UI/대형 파일 구분 증상과 직접 연결 약함(핵심은 인터넷 MTU+ICMP). (E) OS가 점보 프레임 미지원이면 UI 등 모든 통신에 영향, "대형 파일만 실패" 증상과 불일치. 【시험 포인트】 "소형 OK/대형 실패 + DF + 점보 프레임" → 경로 MTU 불일치 + ICMP(PMTUD) 차단.

해설

【핵심 용어】 ▸ Gateway Load Balancer (GWLB) + 엔드포인트 — 방화벽 어플라이언스로 트래픽 투명 인스펙션, GWLB 엔드포인트(GWLBe)를 통해 트래픽 유입 ▸ GWLBe via PrivateLink — GWLB를 다른 계정/VPC에서 서비스로 공유, principal allow list로 접근 허용 ▸ 기본 라우트(default route) → GWLBe — 검사할 트래픽을 GWLB 엔드포인트로 보냄 【정답 포인트】 ▸ 방화벽이 있는 VPC B에 GWLB 생성 + 엔드포인트 서비스로 노출, WorkSpaces 계정 ARN을 principal allow list에 추가 ▸ WorkSpaces 계정(VPC A)에 VPC 엔드포인트(GWLBe) 생성 후 VPC A 라우트 테이블의 기본 라우트를 GWLB 엔드포인트로 지정 → 트래픽이 검사 경로 통과 【오답 체크】 (A) GWLB를 VPC A에 생성하면 별도 계정의 방화벽 어플라이언스(VPC B) 구성과 불일치. (C) 기본 라우트가 아니라 "WorkSpaces 서브넷을 VPC 엔드포인트로" 지정하는 표현이 부정확해 인스펙션 경로 성립 안 함. (D) principal allow list에 방화벽 계정 ARN이 아니라 트래픽 소스인 WorkSpaces 계정 ARN을 넣어야 함. 【시험 포인트】 "크로스 계정 방화벽 인스펙션" → GWLB(어플라이언스 VPC) + GWLBe(소스 VPC) + default route를 GWLBe로.

해설

【핵심 용어】 ▸ Network ACL — 서브넷 경계 stateless 필터, 인바운드·아웃바운드 규칙을 모두 명시해야 함 ▸ Stateless 특성 — 응답 트래픽도 반대 방향 규칙이 있어야 통과(SG는 stateful) ▸ VPN 데이터 전송 실패 — 인바운드는 되나 응답(아웃바운드) 규칙 누락 시 통신 불가 【정답 포인트】 ▸ "인스턴스 시작은 되나 온프레미스에서 데이터 전송 불가", flow log로 반환 트래픽 차단 확인 → NACL이 stateless라 아웃바운드 응답 규칙 필요 ▸ (C) VPC 서브넷 NACL에 아웃바운드 규칙 추가: 서브넷 범위 → 온프레미스 범위 허용 【오답 체크】 (A) SG는 stateful이라 인바운드 허용 시 응답 자동 허용, 이 시나리오(반환 차단)의 핵심은 NACL. (B) 인바운드 규칙만 추가하면 stateless NACL 특성상 반환(아웃바운드) 트래픽은 여전히 차단. (D) SG 아웃바운드는 기본 전체 허용, stateful이라 별도 추가 불필요하며 flow log가 가리키는 NACL 문제 미해결. 【시험 포인트】 "NACL은 stateless" → 인바운드/아웃바운드 규칙을 양방향 모두 명시해야 함.

해설

【핵심 용어】 ▸ Virtual private gateway + Site-to-Site VPN — VPC와 온프레미스 사설 연결 ▸ 기본 라우트(0.0.0.0/0) → VGW — 인터넷 포함 모든 트래픽을 온프레미스 방화벽 경유(중앙 이그레스) ▸ 사설 서브넷만 구성 — 인터넷 게이트웨이/NAT 없이 인터넷 노출 차단 【정답 포인트】 ▸ "인터넷 노출 금지 + 모든 인터넷 트래픽은 온프레미스 방화벽 경유 + 서드파티 웹 접근" → (B) 사설 서브넷만 있는 VPC, VGW+S2S VPN, 기본 라우트를 VGW로 지정 ▸ 인터넷 향 트래픽이 VPN 통해 온프레미스 방화벽을 거쳐 나가므로 서드파티 웹 접근도 그 경로로 처리 【오답 체크】 (A) NAT gateway + IGW를 두면 AWS에서 직접 인터넷 이그레스가 생겨 "모든 인터넷은 온프레미스 방화벽 경유" 요구 위반. (C) 퍼블릭 서브넷 + IGW 기본 라우트는 인터넷 직접 노출, 보안 요구 위반. (D) IGW 기본 라우트를 둔 구성 역시 온프레미스 중앙 이그레스 요구 위반. 【시험 포인트】 "인터넷 노출 금지 + 온프레미스 방화벽 통한 이그레스" → 사설 서브넷 + 기본 라우트를 VGW로.

해설

【핵심 용어】 ▸ Route 53 Latency-based routing — 응답 시간 최저 리전으로 라우팅 ▸ Alias + Evaluate Target Health — ALB alias 레코드에 대상 상태 평가 활성화 시 비정상 리전은 자동 제외 → 다음 최저 지연 리전으로 페일오버 ▸ 리전별 A(alias) 레코드 — 각 ALB에 latency 정책 레코드 생성 【정답 포인트】 ▸ "최저 응답 시간 리전 라우팅 + 불가 시 차선 리전 페일오버" → (D) 각 ALB에 latency 기반 alias 레코드 생성 + Evaluate Target Health = Yes ▸ 대상 상태 평가로 비정상 리전을 자동 제외해 별도 헬스 체크 없이 페일오버 【오답 체크】 (A),(B) geolocation 정책은 지리 위치 기반이라 "최저 응답 시간" 요구 불충족. (C) 단일 alias를 한 ALB에만 두는 구성은 리전별 latency 라우팅·페일오버 구조 성립 안 함. 【시험 포인트】 "최저 지연 + 자동 페일오버" → latency 라우팅 + alias + Evaluate Target Health.

해설

【핵심 용어】 ▸ AWS Network Firewall — 관리형 상태 기반(stateful) IPS/IDS, 침입 방지 제공 ▸ 분산(distributed) 배포 모델 — 각 VPC마다 방화벽 배치, 재아키텍처 없이 VPC별 인스펙션 ▸ 중앙(centralized) 모델 — 인스펙션 VPC + TGW 필요, 재아키텍처 수반 【정답 포인트】 ▸ "재아키텍처 없이 침입 방지 + VPC 5개(피어링, 2년간 증설 없음) + 비암호화 트래픽" → (C) 각 VPC에 Network Firewall 분산 배포 ▸ VPC 수 적고 고정이라 VPC별 분산 배포가 재아키텍처 불필요, 침입 방지·비암호화 트래픽 검사 충족 【오답 체크】 (A) SG/NACL은 stateful IPS 침입 방지 기능이 아님(단순 필터). (B) 중앙 집중 모델은 인스펙션 VPC + TGW 구성 등 재아키텍처 필요, 요구 위반. (D) AWS Shield는 DDoS 방어용, 침입 방지(IPS)와 무관. 【시험 포인트】 "재아키텍처 없이 IPS + 소수 VPC" → Network Firewall 분산 배포.

해설

【핵심 용어】 ▸ Site-to-Site VPN 터널 한계 — 단일 터널 최대 ~1.25Gbps ▸ Transit Gateway + ECMP — TGW에 다중 VPN 연결 후 ECMP로 대역폭 집계(VGW는 VPN ECMP 미지원) ▸ VGW vs TGW — VGW 종단 VPN은 ECMP 대역폭 집계 불가, TGW 필요 【정답 포인트】 ▸ "VPN이 1.25Gbps로 캡" → 단일 터널 한계 → (D) TGW 생성, VPC를 TGW에 연결, 다중 S2S VPN을 TGW에 종단하고 ECMP로 동시 사용해 대역폭 확장 【오답 체크】 (A) VPN 터널 대역폭은 쿼터 증가로 올릴 수 없는 고정 한계. (B) 더 강력한 CGW로도 터널당 물리 한계는 못 넘음. (C) VGW 종단 VPN은 ECMP를 지원하지 않아 대역폭 집계 불가(TGW여야 함). 【시험 포인트】 "VPN 1.25Gbps 한계 극복" → TGW + 다중 VPN + ECMP. VGW로는 ECMP 불가.

해설

【핵심 용어】 ▸ Transit Gateway Network Manager Route Analyzer — TGW 라우트 테이블 기반으로 경로 도달성을 분석해 누락/오구성 식별 ▸ 최소 운영 오버헤드 — 패킷 캡처·telemetry 없이 라우트 경로 분석 ▸ 라우트 누락 진단 — Route Analyzer가 소스/대상 간 경로 존재 여부 검증 【정답 포인트】 ▸ "TGW 라우트 테이블에서 라우트 제거로 통신 불가" + "최소 오버헤드로 오구성 식별" → (A) TGW Network Manager Route Analyzer로 경로 분석 【오답 체크】 (B) IP 모니터링 runbook + CloudWatch telemetry는 설정·분석 오버헤드 큼. (C) VPC flow logs는 흐름 기록일 뿐 TGW 라우트 누락 원인 진단에 부적합. (D) Traffic Mirroring 패킷 캡처는 과도한 오버헤드, 라우트 오구성 식별에 부적합. 【시험 포인트】 "TGW 라우트 오구성 진단 최소 오버헤드" → Network Manager Route Analyzer.

해설

【핵심 용어】 ▸ Transit Gateway Connect — GRE 기반 어태치먼트로 SD-WAN 가상 허브와 TGW 네이티브 통합, BGP 지원 ▸ SD-WAN 네이티브 통합 — VPN 오버레이 다수 대신 Connect로 확장성·라우트 한계·비용 개선 ▸ 확장성/라우트 한계 해소 — TGW로 VPC 집약 + Connect로 SD-WAN 연동 【정답 포인트】 ▸ "VPC 다수 연결 확장성·라우트 한계·비용 문제" + "최소 오버헤드" → (B) TGW로 VPC 어태치 + TGW Connect 어태치먼트로 SD-WAN 어플라이언스 네이티브 통합 【오답 체크】 (A) TGW↔SD-WAN을 S2S VPN으로 연결하면 기존 VPN 확장·비용 문제를 답습. (C) VPC 피어링은 메시 복잡도·확장성 문제 유발, TGW 이점 상쇄. (D) VPC 피어링 기반 구성은 확장성 한계로 요구 미충족. 【시험 포인트】 "SD-WAN + TGW 확장 통합" → Transit Gateway Connect 네이티브 통합.

해설

【핵심 용어】 ▸ Customer-managed prefix list — IP CIDR 목록을 관리형 리소스로 관리, 버전 관리 지원 ▸ AWS Resource Access Manager (RAM) — 조직/계정 간 리소스(프리픽스 리스트) 공유 ▸ 버전 관리 + 조직 공유 — 프리픽스 리스트는 버전 이력 보유, RAM으로 조직에 공유 【정답 포인트】 ▸ "온프레미스 IPv4 목록 버전 관리 + 조직 내 계정에 공유" → (A) 고객 관리형 프리픽스 리스트 생성 후 RAM 리소스 공유로 조직에 공유 ▸ 프리픽스 리스트가 버전 관리 제공, RAM이 조직 전체 배포 담당 【오답 체크】 (B) Firewall Manager는 프리픽스 리스트 공유 도구가 아님(방화벽/정책 관리용). (C) 보안 그룹은 버전 관리 기능이 없고 RAM으로 조직 공유 부적합. (D) DynamoDB + 크로스 계정 Lambda로 SG 조작은 과도한 커스텀 개발·운영 오버헤드. 【시험 포인트】 "버전 관리되는 IP 목록 조직 공유" → 고객 관리형 프리픽스 리스트 + RAM.

해설

【핵심 용어】 ▸ GWLB cross-zone load balancing — AZ 경계 넘어 다른 AZ의 healthy 인스펙션 인스턴스로 분산, 단일 AZ 장애 시 세션 유지 ▸ 인스펙션 인스턴스 이중화 — AZ당 1대뿐이면 유지보수 시 해당 AZ 세션 끊김 ▸ AZ당 추가 인스턴스 — 유지보수 중에도 인스펙션 지속 【정답 포인트】 ▸ "유지보수 중 세션 타임아웃·신규 세션 불가" → 인스펙션 이중화 부족 + AZ 격리 ▸ (B) 각 AZ에 인스펙션 인스턴스 1대 추가로 유지보수 중에도 가용 유지 ▸ (C) GWLB cross-zone 부하 분산 활성화로 한 AZ 인스턴스 다운 시 다른 AZ로 분산 【오답 체크】 (A) 인스펙션 없는 AZ에 배치하는 것은 현재 사용 AZ의 이중화 부족 문제와 무관. (D) Auto Scaling(CPU 기반)은 유지보수 중 가용성 보장이 아니라 부하 대응, 근본 이중화·cross-zone 아님. (E) 리전 전체 AZ에 GWLB 부착은 불필요하며 세션 지속 문제 직접 해결 아님. 【시험 포인트】 "인스펙션 유지보수 중 세션 끊김" → AZ당 인스턴스 추가 + GWLB cross-zone LB.

해설

【핵심 용어】 ▸ CloudFront — 엣지 로케이션에서 캐싱하여 지연 시간 감소 ▸ SSL/TLS — 전송 중 암호화 ▸ 정적 콘텐츠 — 이미지, 파일 최적화 【정답 포인트】 ▸ 정적 콘텐츠 → CloudFront 캐싱 최적 ▸ 전 지역 사용자 → CloudFront 엣지 로케이션 분산 ▸ 암호화 → HTTPS + HTTP→HTTPS 리디렉션 ▸ Route 53 별칭 → CloudFront 배포로 직접 라우팅 【오답 체크】 (A) Global Accelerator는 비용이 높고 동적 콘텐츠용(UDP, 게임 등) (B) Route 53에서 ALB로 직접 라우팅하면 캐싱 이점 상실 (D) 두 리전 배포는 불필요(정적 콘텐츠), 비용 증가 【시험 포인트】 정적 콘텐츠 + 다중 지역 사용자 → CloudFront 선택. Global Accelerator는 게임/IoT/실시간 애플리케이션용. 지연 시간 + 비용 최소화는 CDN(CloudFront)이 답.

해설

【핵심 용어】 ▸ 프라이빗 호스팅 존 — VPC 내부 DNS ▸ Route 53 Resolver 인바운드 엔드포인트 — 온프레미스→AWS DNS 해석 ▸ 조건부 포워더 — DNS 쿼리 선택적 전달 【정답 포인트】 ▸ A(별칭 레코드) — Route 53에서 ALB로 매핑 ▸ C(인바운드 엔드포인트) — 온프레미스에서 VPC DNS 접근 ▸ 조합: Route 53 레코드 + Resolver 인바운드로 완전 해결 【오답 체크】 (B) CNAME은 프라이빗 호스팅 존의 루트에 사용 불가 (D) 아웃바운드는 AWS→온프레미스(반대 방향) (E) 172.31.0.2 직접 포워딩은 보안, 확장성 부족 【시험 포인트】 VPN + 프라이빗 DNS = Resolver 인바운드. 온프레미스에서 AWS 프라이빗 도메인 해석은 인바운드 엔드포인트 필수.

해설

【핵심 용어】 ▸ Cloud WAN 코어 네트워크 — 엣지 기반 연결 ▸ 세그먼트 — 환경별 격리(개발, 프로덕션, 공유) ▸ 규칙 번호 — 낮을수록 우선 순위 높음 【정답 포인트】 ▸ 규칙 100(높은 우선순위): Production AND us-east-1만 수락 요구 ▸ 규칙 200: 다른 모든 태그는 자동 매핑 ▸ AND 논리 — 두 조건 모두 만족할 때만 수락 ▸ OR은 부정확(다른 리전 프로덕션도 수락 요구) 【오답 체크】 (A) OR 논리 = us-east-1의 모든 환경이 수락 요구 (C) 규칙 200이 우선(낮은 번호) → 수락 요구 규칙 무시 (D) 규칙 번호 역순 + OR = 조건 불일치 【시험 포인트】 규칙 번호 우선순위 이해 필수. us-east-1의 Production만 → AND 조건 필수.

해설

【핵심 용어】 ▸ Direct Connect — 전용 네트워크 연결 ▸ 복원력 — 회선/라우터 장애 대응 ▸ 4Gbps 요구량 — 충분한 대역폭 필요 【정답 포인트】 ▸ 4개 10Gbps = 40Gbps 총 대역폭(4Gbps 요구 여유) ▸ 2개 로케이션 분산 = 위치 다양성 ▸ 2개 라우터 = 라우터 장애 보호 ▸ 결과: 1개 회선 손실 → 다른 회선 이용, 1개 라우터 다운 → 다른 라우터 이용 【오답 체크】 (B) 2개 10Gbps만 = 20Gbps(여유 부족), 한 회선 손실 시 10Gbps만 남음 (C) 4Gbps = 1개 회선으로 충분(복원력 약함) (D) 2Gbps 총 < 4Gbps 요구 불가 【시험 포인트】 복원력(회선+라우터) + 대역폭 → 다중 대용량 연결. N+1 이상의 여유 설계 필수.

해설

【핵심 용어】 ▸ ALB — 레이어 7(애플리케이션), 스티키 세션 지원 ▸ NLB — 레이어 4(전송), 극초고속, IP 타입 미지원 온프레미스 ▸ 세션 친화성 — 같은 클라이언트→동일 서버 【정답 포인트】 ▸ HTTPS(애플리케이션) → ALB 필수 ▸ IP 타입 → 온프레미스 IP 등록 가능 ▸ 스티키 세션 → 동일 서버 보장 ▸ ALB + IP 타입 + 애플리케이션 세션 친화성 = 조건 완벽 【오답 체크】 (A) NLB + ip + 연결 드레이닝 = 세션 친화성 없음 (C) NLB + instance = 온프레미스 서버 등록 불가(IP만 가능) (D) ALB + instance = 온프레미스 서버 등록 불가 【시험 포인트】 ALB(HTTPS) + IP 대상 타입 = 온프레미스 서버 포함. Instance 타입은 VPC 인스턴스만.

해설

【핵심 용어】 ▸ 동적 IP — 변하는 공인 IP(IP 사전 지정 불가) ▸ IKEv2 — 최신, 모바일 친화적 ▸ 프라이빗 CA — 자체 관리 인증서 【정답 포인트】 ▸ B(IKEv2) — 동적 환경에서 안정적 ▸ C(프라이빗 CA) — 조직 내부 인증서 관리 ▸ F(IP 미지정) — 동적 IP는 사후 등록, AWS에서 연결 시작 가능 【오답 체크】 (A) IKEv1 — 구형, 덜 유연 (D) 공인 CA — 온프레미스 프라이빗 VPN에 부적절 (E) 동적 IP를 정적으로 지정 = 모순, 변경되면 실패 【시험 포인트】 동적 IP + AWS 측 시작 = IKEv2 + IP 미지정 + 프라이빗 CA. 온프레미스에서 AWS로 초기화 가능.

해설

【핵심 용어】 ▸ Client VPN — 원격 사용자 VPN 클라이언트 ▸ VPC 피어링 — VPC 간 연결 ▸ 라우팅 — Client VPN 엔드포인트 경로 설정 【정답 포인트】 ▸ B(VPC 피어링) — VPC A↔VPC B 연결(암호화) ▸ D(Client VPN 단일) — 1개 엔드포인트로 관리(오버헤드 최소) ▸ E(라우트 추가) — VPC B로의 트래픽 경로 설정 ▸ 결과: 원격→VPC A→(피어링)→VPC B 모두 접근 【오답 체크】 (A) Site-to-Site VPN = 조직→AWS(원격 사용자용 아님) (C) 2개 엔드포인트 = 관리 복잡도 증가 (F) VPC A 경로는 불필요(같은 엔드포인트 VPC) 【시험 포인트】 최소 오버헤드 = Client VPN 1개 + 피어링. VPC A가 허브 역할.