정답 · 해설

해설

【핵심 용어】 ▸ Direct Connect Gateway — 여러 VIF를 관리하는 중앙 게이트웨이 ▸ Private VIF Migration — VIF 재할당 (게이트웨이 재사용) ▸ BGP Failover — 백업 경로 활성화 【정답 포인트】 ▸ 기존 DX Gateway 재사용 → 최소 다운타임 ▸ 새 VIF를 기존 DX Gateway에 연결 → 라우팅 자동 업데이트 ▸ BGP 백업 경로 설정 → 전환 중 무중단 ▸ 유지보수 기간에만 BGP 종료로 전환 【오답 체크】 ▸ (A) 새 DX Gateway 생성 = 재설정 필요 (다운타임 증가) ▸ (C) VIF 직접 마이그레이션은 AWS 지원 불가 ▸ (D) VIF 삭제 후 재생성은 중단 시간 최대화 【시험 포인트】 DX 마이그레이션 최소화 전략: (1) 기존 DX Gateway 유지 (2) 새 VIF 추가 (3) BGP 백업 활성화 (4) 기존 BGP 종료. 기존 인프라 최대한 재사용.

해설

【핵심 용어】 ▸ VPC Peering — 2-8개 VPC 같은 리전/다른 리전 연결 ▸ Site-to-Site VPN — 온프레미스 ↔ AWS 보안 연결 ▸ Operational Cost — 마이그레이션 기간만 필요 【정답 포인트】 ▸ B(VPC 피어링) — 8개 VPC 연결: 완전 메시 아키텍처 (각 VPC ↔ 다른 VPC) ▸ E(Site-to-Site VPN) — 2개 데이터센터 × 각 8 VPC = VPN 다중화 (고가용성) ▸ 주말 마이그레이션 기간 + 비용 최소화 = 마이그레이션 후 폐기 예상 【오답 체크】 ▸ (A) Transit Gateway는 단일 실패점, 피어링이 더 격리된 구조 ▸ (C) Direct Connect는 장기 비용 높음 (마이그레이션만 필요) ▸ (D) TGW VPN은 각 데이터센터 1개만 → 고가용성 부족 【시험 포인트】 단기 마이그레이션 프로젝트: VPC 피어링(무료/저비용) + VPN(다중화). 장기 운영 아키텍처가 아니므로 Direct Connect 불필요.

해설

【핵심 용어】 ▸ Private REST API — API Gateway의 프라이빗 엔드포인트 (VPC 내부만 접근) ▸ Interface Endpoint — VPC 엔드포인트로 AWS 서비스 프라이빗 접근 ▸ Private DNS Names — VPC 내 프라이빗 DNS 해석 ▸ Public DNS Names — 인터넷에서 해석 가능한 DNS 【정답 포인트】 ▸ Private DNS Names 활성화 + 엔드포인트의 퍼블릭 DNS = Private Routing ▸ 온프레미스 클라이언트는 Direct Connect로 VPC에 액세스 ▸ VPC 엔드포인트의 퍼블릭 DNS는 VPC 내부에서는 프라이빗으로 해석 【오답 체크】 ▸ (A) 프라이빗 DNS 이름은 VPC 내부만 작동 ▸ (B) Route 53 별칭은 추가 인프라 필요 ▸ (C) 엔드포인트 ↔ 프라이빗 API 연결은 자동 (명시적 연결 불가) 【시험 포인트】 Private REST API + Interface Endpoint + Private DNS enabled = 온프레미스에서 Direct Connect로 VPC 접근 후 엔드포인트의 퍼블릭 DNS로 프라이빗 라우팅. 추가 인프라(Route 53, ALB 등) 불필요.

해설

【핵심 용어】 ▸ AWS Config Rule — 규정 준수 모니터링 (관리형 규칙 활용) ▸ no-unrestricted-route-to-igw — 0.0.0.0/0 또는 ::/0 경로 탐지 ▸ internet-gateway-authorized-vpc-only — 특정 VPC의 IGW만 허용 【정답 포인트】 ▸ Config Rule(no-unrestricted-route-to-igw) — 기본 경로 추가 감지 ▸ EventBridge + SNS — Config 이벤트를 이메일로 자동 변환 ▸ 최소 구현: Config 규칙 생성 + EventBridge 연결 (Lambda 불필요) 【오답 체크】 ▸ (A) Lambda 폴링은 지연성, 매분 실행은 비효율 ▸ (B) API 트리거는 CreateRoute만 감지 (기존 경로 변경 미감지) ▸ (C) internet-gateway-authorized-vpc-only는 특정 VPC 지정 필요 【시험 포인트】 Config 규칙은 지속적 준수 모니터링. no-unrestricted-route-to-igw는 제한 없는 IGW 경로 감지 규칙. EventBridge는 Config 변경 이벤트 자동 캡처 + SNS 알림.

해설

【핵심 용어】 ▸ IP Target Type — 포드의 IP를 직접 대상으로 (SNAT 제거) ▸ externalTrafficPolicy: Local — 로컬 포드만 선택 (원본 IP 보존) ▸ Source IP Preservation — 원본 클라이언트 IP 유지 【정답 포인트】 ▸ IP Target Type — VPC CNI 환경에서 포드 IP 직접 라우팅 ▸ externalTrafficPolicy: Local — SNAT 스킵, 원본 IP 그대로 포드에 전달 ▸ 조합: 원본 IP 유지 + 포드 직접 접근 = 완벽한 출처 추적 【오답 체크】 ▸ (B) (C) Instance Target Type은 노드 IP → 포드 SNAT (원본 IP 손실) ▸ (B) (D) Cluster 정책은 모든 노드의 포드 선택 가능 (NodePort 경로) 【시험 포인트】 EKS + NLB + 원본 IP 보존 = IP Target Type + externalTrafficPolicy: Local. IP Target은 포드 직접 라우팅이므로 노드 SNAT 우회.

해설

【핵심 용어】 ▸ MTU (Maximum Transmission Unit) — 패킷 최대 크기 ▸ Transit Gateway MTU — 최대 8500바이트 지원 ▸ Jumbo Frames — 9000+ 바이트 (Transit Gateway 미지원) 【정답 포인트】 ▸ Transit Gateway 제한: 최대 8500바이트 MTU ▸ 모든 트래픽이 Transit Gateway를 통과 → 모든 경로에서 8500 제약 ▸ EC2 인스턴스 MTU = 8500바이트 설정이 최적 【오답 체크】 ▸ (A) Transit Gateway는 점보 프레임 미지원 (최대 8500) ▸ (B) VPC MTU는 변경 불가 (항상 1500) ▸ (C) 향상된 네트워킹 + 9001 MTU는 Transit Gateway에서 차단됨 【시험 포인트】 Transit Gateway 환경에서 MTU 설정은 TGW 제약인 8500바이트가 상한. 점보 프레임(9001)은 TGW 미지원이므로 불가능.

해설

【핵심 용어】 ▸ CloudWatch Internet Monitor — 인터넷 경로 건강 모니터링 ▸ EventBridge — 이벤트 기반 자동화 (소스-규칙-대상) ▸ Partner Integrations — EventBridge 파트너 이벤트 버스 【정답 포인트】 ▸ Internet Monitor는 EventBridge와 자동 통합 ▸ EventBridge 규칙에서 Internet Monitor 이벤트 감지 + 타사 API 호출 ▸ 최소 구현: EventBridge 규칙 1개만 생성 (Lambda 불필요) 【오답 체크】 ▸ (A) Internet Monitor는 직접 EventBridge로 전송 (수동 설정 필요 없음) ▸ (C) S3 + Lambda 경로는 불필요한 추가 구성 ▸ (D) Internet Monitor는 API 엔드포인트 지원 안 함 (EventBridge 경유) 【시험 포인트】 Internet Monitor → EventBridge (자동) → 파트너 API는 최소 구성. EventBridge는 Internet Monitor 이벤트를 자동 감지하므로 규칙만 생성하면 됨.

해설

【핵심 용어】 ▸ Global Accelerator — 글로벌 트래픽 최적화 (낮은 지연성) ▸ Alias Record — Route 53 특수 레코드 (ALB/ELB/GA 타겟) ▸ Regional Certificates — 각 ALB의 기존 인증서 유지 【정답 포인트】 ▸ C(GA Alias) — 새 도메인을 Global Accelerator로 라우팅 ▸ D(Standard GA + TCP) — TCP에서 TLS 종료는 ALB에서 처리 ▸ E(Regional Certs) — 각 ALB의 기존 인증서 유지 (변경 불필요) 【오답 체크】 ▸ (A) us-east-1만 인증서 생성 → 다른 리전 ALB 사용 불가 ▸ (B) Latency-based Routing은 Global Accelerator와 조합 시 이중 라우팅 ▸ (F) Custom Routing GA는 고정 IP 포트 매핑, 다중 ALB 대상 미지원 【시험 포인트】 Global Accelerator (표준) + Regional ALB Certs = 단일 도메인 + 지연성 최소화. GA는 TCP 수준에서 작동, ALB가 TLS 처리.

해설

【핵심 용어】 \n ▸ AWS Local Zone — 일반 리전의 연장선으로 단일 VPC 내 서브넷 추가 가능\n ▸ 비용 효율성 — 추가 게이트웨이나 어플라이언스 없이 단순 구조\n\n 【정답 포인트】 \n ▸ Local Zone은 기존 VPC의 연장으로 설계됨 → 새로운 VPC 불필요\n ▸ 같은 VPC 내 서브넷이므로 Transit Gateway, VPN, 어플라이언스 불필요\n ▸ CIDR 블록만 올바르게 구성하면 자동 라우팅 가능\n ▸ 최소 비용, 운영 복잡도 최소화\n\n 【오답 체크】 \n (A) Transit Gateway 사용 → 비용 증가, Local Zone 연결에 불필요\n (B) VPN 연결 → 높은 지연시간, Local Zone의 저지연 특성 활용 불가\n (C) 타사 어플라이언스 → 비용 및 운영 오버헤드, 필요 없는 복잡성\n\n 【시험 포인트】 \n ▸ Local Zone은 VPC 확장으로 이해 — 별도 네트워킹 구조 불필요\n ▸ 비용 최적화 → 단순한 솔루션이 정답

해설

【핵심 용어】 \n ▸ isolate-attachments — 같은 세그먼트 내 VPC 간 통신 차단\n ▸ 네트워크 정책 공유 — 세그먼트 간 트래픽 흐름 제어\n\n 【정답 포인트】 \n ▸ C: isolate-attachments=True → BU VPC 간 상호 통신 차단 (규정 준수)\n ▸ B: 검사 세그먼트 공유 → 모든 BU 트래픽이 인스펙션 VPC 통과 (인터넷 검사)\n ▸ 두 설정 조합으로 격리 및 검사 동시 달성\n\n 【오답 체크】 \n (A) 공유 서비스 세그먼트 → BU VPC 간 통신 허용 (규정 위배)\n (D) isolate-attachments=False → VPC 간 통신 허용 (규정 위배)\n (E) 정적 라우트 → 확장성 낮음, 향후 VPC마다 수동 설정 필요\n\n 【시험 포인트】 \n ▸ Cloud WAN 세그먼트 격리 메커니즘 이해\n ▸ isolate-attachments와 정책 공유의 조합 활용\n ▸ 운영 효율성 → 자동화된 정책 기반 솔루션

해설

【핵심 용어】 \n ▸ 듀얼 스택 NLB — IPv4와 IPv6 모두 처리\n ▸ IPv6 주소 — 인스턴스가 실제로 보유해야 함\n\n 【정답 포인트】 \n ▸ NLB에서 IPv6 쿼리를 수신하려면 백엔드 인스턴스가 IPv6 주소 필요\n ▸ 서브넷 수준에서 IPv6 CIDR 블록 할당 필수\n ▸ EC2 인스턴스가 IPv6 주소를 보유하지 않으면 응답 불가능\n\n 【오답 체크】 \n (B) NLB 서브넷 라우팅 → NLB가 수신하는 부분이므로 문제 아님\n (C) EC2 서브넷 라우팅 → 이미 구성되어 있음 (0.0.0.0/0 또는 로컬)\n (D) NLB 보안그룹 → 일반적으로 필요 없음, EC2 보안그룹만 필요\n\n 【시험 포인트】 \n ▸ IPv6 배포의 핵심은 주소 할당순서 → 서브넷 → 인스턴스\n ▸ 듀얼 스택의 필수 구성요소 이해

해설

【핵심 용어】 \n ▸ GWLB 엔드포인트 — 스포크 VPC에서 GWLB로 진입점\n ▸ 트래픽 흐름 — 출발지 → 엔드포인트 → GWLB → 어플라이언스 → 반환\n\n 【정답 포인트】 \n ▸ 스포크 VPC 라우팅은 GWLB 엔드포인트로 지향 (직접 GWLB가 아님)\n ▸ GWLB 엔드포인트가 GWLB와의 연결 담당\n ▸ 가상 어플라이언스 처리 후 반환 경로도 GWLB 엔드포인트 경유\n ▸ X-Forwarded-For 헤더는 일반적으로 GWLB에서 설정하지 않음 (L4 기반)\n\n 【오답 체크】 \n (B) (C) (D) X-Forwarded-For 헤더 설정 → GWLB는 L4 로드밸런서로 L7 헤더 처리 안 함\n (B) (C) (D) 라우팅 경로 불일치 → 엔드포인트와 GWLB의 역할 혼동\n\n 【시험 포인트】 \n ▸ GWLB 허브-스포크 아키텍처 트래픽 흐름\n ▸ 엔드포인트의 역할 = 진입/반환 경로

해설

【핵심 용어】 \n ▸ pkt-dstaddr — 패킷의 원본 목적지 IP (ENI 보조 IP 포함)\n ▸ dstaddr — 네트워크 인터페이스 수준의 목적지\n\n 【정답 포인트】 \n ▸ 보조 IP로의 트래픽은 주 IP로 자동 변환됨 (기본 설정)\n ▸ 원래 목적지를 추적하려면 pkt-dstaddr 필드 필요\n ▸ pkt-dstaddr는 패킷 수준의 원본 정보 보존\n\n 【오답 체크】 \n (B) dstaddr — ENI 주소만 기록, 보조 IP 구분 불가\n (C) pkt-srcaddr — 목적지가 아닌 출발지 기록\n (D) srcaddr — ENI의 출발지 IP만 기록, 목적지 추적 불가\n\n 【시험 포인트】 \n ▸ VPC Flow Logs 필드 구조 이해\n ▸ 패킷 수준(pkt-*) vs ENI 수준(*addr) 필드 구분\n ▸ 보조 IP 트래픽 추적 방법

해설

【핵심 용어】 \n ▸ 코어 네트워크 정책 — 세그먼트 간 라우팅 규칙\n ▸ 정적 라우트 — 명시적 경로 지정\n\n 【정답 포인트】 \n ▸ 기본 정책으로는 다른 세그먼트 간의 연결 불가\n ▸ 서로 다른 세그먼트 간(개발↔스테이징) 통신 필요\n ▸ 코어 네트워크 정책에서 명시적 정적 라우트 정의 필수\n ▸ 각 세그먼트가 원격 세그먼트의 CIDR로의 라우트 알아야 함\n\n 【오답 체크】 \n (A) VPC 라우팅 테이블 → 코어 네트워크 정책 확인 필요, 불충분\n (B) 세그먼트 필터 → 트래픽 허용이 아닌 고급 필터링 기능\n (C) isolate-attachments=False → VPC 격리 제거, 같은 세그먼트 내에만 영향\n\n 【시험 포인트】 \n ▸ Cloud WAN 정책 기반 라우팅\n ▸ 세그먼트 간 명시적 라우트 정의 필수\n ▸ 코어 네트워크 정책의 역할

해설

【핵심 용어】 \n ▸ Direct Connect VIF DOWN → L2/L3 계층 연결 문제\n ▸ Ping 실패 → IP 주소, VLAN, ARP 레벨 문제\n\n 【정답 포인트】 \n ▸ A: IP 주소와 마스크 → 기본 L3 설정 검증\n ▸ C: ARP 테이블 → L2 연결성 확인 (MAC 주소 해석)\n ▸ E: VLAN 태그 → VIF 설정의 핵심 (태그 불일치 = 서로 다른 VLAN)\n ▸ 세 항목 모두 ping 도달을 위한 필수 체크항목\n\n 【오답 체크】 \n (B) VLAN 트렁킹 비활성화 → Direct Connect는 보통 트렁킹 필요\n (D) 광학 신호 → 전기적 신호 수준, ping 문제와는 다름\n(F) TCP 179 (BGP) → VIF DOWN 상태에서는 L3 설정 전 이미 문제\n\n 【시험 포인트】 \n ▸ Direct Connect 트러블슈팅 계층별 접근\n ▸ VIF DOWN = L2/L3 설정 문제 (BGP 아님)\n ▸ ARP와 VLAN 태그의 중요성

해설

【핵심 용어】 \n ▸ ECMP — 여러 경로를 동시에 사용하여 부하 분산\n ▸ 액티브-패시브 → 액티브-액티브로 변환 필요\n ▸ BGP — 동적 라우팅으로 두 터널 자동 감지\n\n 【정답 포인트】 \n ▸ ECMP 활성화 → Transit Gateway와 고객 게이트웨이 모두 필요\n ▸ 정적 라우팅 → BGP 변경 → 두 터널을 같은 비용으로 자동 로드밸런싱\n ▸ BGP가 두 IPsec 터널을 동등 비용으로 전파\n ▸ 정적 라우트 제거 → 자동 라우팅으로 전환\n\n 【오답 체크】 \n (A) Transit Gateway Connect 미필요, 복잡성 증가\n (B) BGP 미적용 → 정적 라우트로는 ECMP 활성화 불가\n (D) 커뮤니티 문자열 → 표준 구성이 아님, 불필요\n\n 【시험 포인트】 \n ▸ VPN 대역폭 최대화 = ECMP + BGP\n ▸ 정적에서 동적 라우팅으로의 전환\n ▸ Transit Gateway VPN ECMP 구성 패턴

해설

【핵심 용어】 \n ▸ Transit Gateway 멀티캐스트 도메인 — VPC 간 멀티캐스트 라우팅\n ▸ IGMP — 멀티캐스트 그룹 멤버십 관리\n\n 【정답 포인트】 \n ▸ A: 수신 인스턴스를 멀티캐스트 그룹에 가입 → IGMP 그룹 설정\n ▸ D: 서브넷을 멀티캐스트 도메인 연결에 추가 → VPC가 멀티캐스트 참여\n ▸ 두 설정이 모두 필요: VPC 레벨 + 인스턴스 레벨\n\n 【오답 체크】 \n (B) IGMP Port 5102 → IGMP는 포트 미사용, 프로토콜만 필요\n (C) EC2 인스턴스 ID 추가 → 서브넷 단위로 추가해야 함 (ID 아님)\n (E) UDP 포트 5102, 소스 10.128.10.2 → 보안그룹에 필요 (별도)\n\n 【시험 포인트】 \n ▸ Transit Gateway 멀티캐스트 구성 계층\n ▸ ENI 그룹 멤버십 vs 서브넷 연결\n ▸ IGMP 프로토콜 역할 (포트 아님)

해설

【핵심 용어】 \n ▸ Direct Connect 게이트웨이 — 여러 리전 간 Direct Connect 중앙 집중화\n ▸ Transit Gateway 피어링 — 리전 간 VPC 연결\n\n 【정답 포인트】 \n ▸ 기존 Direct Connect 게이트웨이 재사용 → 비용 효율적\n ▸ 런던의 새로운 Direct Connect 연결을 같은 게이트웨이에 연결\n ▸ eu-west-2 Transit Gateway를 같은 게이트웨이에 연결\n ▸ Transit Gateway 피어링으로 리전 간 VPC 통신 완성\n ▸ 단일 Direct Connect 게이트웨이로 중앙화된 아키텍처\n\n 【오답 체크】 \n (A) VPN 연결 → 개인 연결 아님 (인터넷 기반)\n (C) 각 VPC마다 VPN → 확장성 낮음, 관리 복잡\n (D) 새로운 게이트웨이 생성 → 불필요한 비용, 이점 없음\n\n 【시험 포인트】 \n ▸ Direct Connect 게이트웨이의 중앙화 이점\n ▸ 여러 리전 설계에서의 운영 효율성\n ▸ Direct Connect + Transit Gateway 조합 아키텍처

해설

【핵심 용어】 \n ▸ 스티키 세션 — 같은 서버로 계속 라우팅\n ▸ IP 대상 유형 — 온프레미스 서버 등록 가능\n ▸ ALB — 응용 계층 기반 스티키\n\n 【정답 포인트】 \n ▸ HTTPS = 응용계층 → ALB 필요 (NLB는 L4)\n ▸ 애플리케이션 기반 스티키 → 쿠키 기반 세션 유지\n ▸ IP 대상 유형 → 온프레미스 서버 IP 직접 등록 가능\n ▸ ALB + IP 대상 + 애플리케이션 스티키 = 완벽한 조합\n\n 【오답 체크】 \n (A) NLB + 연결 드레이닝 → 스티키 미지원 (L4)\n (C) NLB 스티키 → 응용계층 정보 없음\n (D) 인스턴스 대상 유형 → 온프레미스 서버 등록 불가\n\n 【시험 포인트】 \n ▸ HTTPS 로드밸런싱은 ALB 선택\n ▸ 온프레미스 + 클라우드 혼합 = IP 대상 유형\n ▸ 스티키 세션 구현 방식

해설

【핵심 용어】 \n ▸ 복원력 — 장애 대응 능력\n ▸ 내결함성 — 장애 후에도 계속 동작\n ▸ 다양한 공급자 — 단일 지점 장애 방지\n\n 【정답 포인트】 \n ▸ 각 데이터 센터마다 2개 × 10 Gbps = 20 Gbps (10 Gbps 초과)\n ▸ 서로 다른 Direct Connect 위치 = 물리적 경로 분산\n ▸ 서로 다른 공급자 = 공급자 장애 회피\n ▸ 각 데이터 센터 자체 복원력 → 해당 지역 내 고가용성\n\n 【오답 체크】 \n (A) (B) 100/10 Gbps → 비용 높음, 단일 위치 집중화 위험\n (D) VPN 추가 → 보조 데이터 센터 복원력 부족 (인터넷 기반 VPN)\n\n 【시험 포인트】 \n ▸ 각 위치별 독립적 복원력 구성\n ▸ 대역폭 > 10 Gbps = 다중 경로\n ▸ 비용 vs 복원력 균형 (100 Gbps는 과도)\n ▸ 공급자 다양화의 중요성