정답 · 해설

해설

【핵심 용어】 ▸ MACsec — Media Access Control Security (계층 2 암호화) ▸ CAK/CKN — MACsec 인증서 및 키 관리 ▸ LAG (Link Aggregation Group) — 다중 포트 번들링 【정답 포인트】 ▸ (A) 새 LAG 생성 — 기존 LAG는 MACsec 미지원이므로 신규 필요 ▸ (B) CAK/CKN 설정 — MACsec 키 관리의 필수 단계 ▸ (E) 새 LAG에 MACsec 암호화 활성화 — 계층 2 보안 적용 【오답 체크】 (C) IKE — 계층 3 IPsec 프로토콜, MACsec(계층 2)과 무관 (D) 기존 LAG에 MACsec — 기존 장비 미지원 (F) 개별 연결 설정 — LAG 레벨에서 통합 관리 【시험 포인트】 MACsec = 신규 LAG + 키 설정 + 암호화 모드 활성화 (3단계 프로세스).

해설

【핵심 용어】 ▸ AWS Config — 리소스 규정 준수 추적 및 자동화 ▸ CloudFormation StackSets — 다중 계정 배포 ▸ Systems Manager Automation — 자동 재정의 조치 【정답 포인트】 ▸ AWS Config 규칙 = 지속적 규정 준수 모니터링 ▸ StackSets = 다중 계정 중앙화 배포 (최소 오버헤드) ▸ Automation remediation = NAT 게이트웨이 자동 종료 ▸ Config 이력 = 규정 준수 추적 및 감사 로그 【오답 체크】 (A) EC2 + cron — 서버 관리 오버헤드, 확장성 제한 (B) Lambda + SAM — 개별 계정 배포, 복잡한 관리 (C) GuardDuty + EventBridge — GuardDuty는 보안 위협 탐지용, NAT 이벤트 미지원 【시험 포인트】 AWS Config + StackSets + Automation = 규정 준수 + 다중 계정 + 자동화 + 감사의 완벽한 조합.

해설

【핵심 용어】 ▸ Latency Routing Policy — 클라이언트의 지연 시간 기반 라우팅 ▸ Region Association — 각 레코드를 리전에 연결 【정답 포인트】 ▸ 지연 시간 라우팅 = Route 53이 클라이언트 → 리전 지연 자동 측정 ▸ 최적 응답 시간 = 가장 낮은 지연 시간을 가진 리전으로 자동 라우팅 ▸ 글로벌 게임 트래픽 분산에 최적 【오답 체크】 (A) 가중치 라우팅 — 수동 계산 필요, 동적 지연 반영 안 됨 (C) 다중값 응답 — 클라이언트가 지연 시간 계산, 비효율적 (D) 지리적 위치 라우팅 — 물리적 위치 기반, 지연 시간 미최적화 【시험 포인트】 Latency Routing = 실시간 지연 시간 기반 트래픽 최적화 (게임/낮은 지연성 애플리케이션 필수).

해설

【핵심 용어】 ▸ Phase 2 Rekey — IPsec 라이프타임 갱신 시 매개변수 재협상 ▸ Customer Gateway Native Logs — 온프레미스 장비의 원본 로그 【정답 포인트】 ▸ 문제: AWS 제공 매개변수 ≠ 고객 장비 지원 매개변수 ▸ 해결책: 고객 게이트웨이 로그 확인 → 실제 지원 알고리즘 파악 ▸ 조치: VPN 터널 옵션을 고객 장비 지원 범위로 제한 ▸ AWS는 보안 우선, 고객 장비가 제약 요소 【오답 체크】 (A) VPG 로그 — AWS 측 로그로는 고객 장비 제약 파악 불가 (C) CloudWatch VPG — 프로비저닝되지 않은 로그, AWS는 CloudWatch 미사용 (D) CloudWatch CGW — 온프레미스 장비 로그는 CloudWatch에 없음 【시험 포인트】 IPsec 협상 실패 = 고객 장비 제약 확인 → 네이티브 로그 읽기 → 상호 호환 매개변수로 맞추기.

해설

【핵심 용어】 ▸ Dynamic BGP — 경로 자동 학습 및 장애 조치 ▸ ECMP — 여러 경로 간 동시 로드밸런싱 ▸ VPN 확장성 — 다중 터널로 대역폭 증가 【정답 포인트】 ▸ 다중 VPN 연결 = 병렬 처리량 (N × 연결당 처리량) ▸ BGP 동적 = 경로 수렴 시간 감소, 장애 자동 우회 ▸ ECMP = 여러 터널 간 트래픽 균등 분산 ▸ Transit Gateway 기본 지원 【오답 체크】 (B) 정적 라우팅 — BGP 동적 학습 불가, 수동 관리 부담 (C) 단일 연결 + 가속 — 처리량 한계 미해결 (D) 소프트웨어 VPN — 성능 불안정, 확장성 제한 【시험 포인트】 VPN 확장 = 다중 연결 + BGP 동적 + ECMP (3요소 필수).

해설

【핵심 용어】 ▸ DNSQueries CloudWatch Metric — Route 53 쿼리 수 추적 ▸ AWS/Route 53 Namespace — Route 53 관리 메트릭 【정답 포인트】 ▸ CloudWatch 직접 쿼리 = 가장 간단하고 빠른 방법 ▸ DNSQueries 지표 = 호스팅 영역별 쿼리 집계 ▸ TTL 변경 영향도 즉시 확인 가능 【오답 체크】 (A) CloudTrail — 데이터 이벤트 아님, 관리 이벤트만 추적 (C) Route 53 Resolver — VPC 엔드포인트 쿼리용, 공개 호스팅 영역 미지원 (D) 호스팅 영역 로깅 — 미지원 기능, CloudWatch 직접 메트릭 사용 【시험 포인트】 Route 53 쿼리 모니터링 = CloudWatch DNSQueries 지표 (즉시 조회 가능).

해설

【핵심 용어】 ▸ Route 53 Resolver Outbound Endpoint — VPC 아웃바운드 DNS 쿼리 라우팅 ▸ Forwarding Rule — 특정 도메인의 DNS 쿼리를 외부 DNS 서버로 전달 ▸ System Rule — AWS 서비스 도메인 예외 처리 【정답 포인트】 ▸ (D) Outbound Endpoint = VPC에서 나가는 DNS 쿼리 가로채기 ▸ (F) 전체 도메인("." = 루트) 포워딩 = 모든 공개 쿼리를 온프레미스 DNS로 ▸ (E) amazonaws.com 시스템 규칙 = AWS 서비스 쿼리는 로컬 처리 (예외) 【오답 체크】 (A) 시스템 규칙 A — amazonaws.com 예외처리 안 됨 (B) DHCP 옵션 세트 — VPC 전체 DNS 변경, 세분화 불가 (C) Inbound Endpoint — 온프레미스 → VPC 방향, 요구사항 반대 방향 【시험 포인트】 DNS 트래픽 제어 = Outbound Endpoint + Forwarding Rule + System Rule (세 가지 조합).

해설

【핵심 용어】 ▸ Route 53 Resolver — 다중 계정 DNS 통합 ▸ AWS RAM (Resource Access Manager) — 규칙 공유 ▸ Inbound/Outbound Endpoint — 양방향 DNS 포워딩 【정답 포인트】 ▸ (A) 중앙 프라이빗 호스팅 영역 = 전체 클라우드 도메인 관리 ▸ (C) Resolver 엔드포인트 = 다중 계정 접근, 온프레미스 연동 ▸ (F) AWS RAM 공유 = 규칙 중앙화, 계정별 자동 적용 ▸ (E) 네트워크 연결 확인 = 엔드포인트 도달 가능 보증 【오답 체크】 (B) Directory Service — AWS 네이티브 아님, 복잡도 높음 (D) Directory Service 네트워크 — 불필요 【시험 포인트】 다중 계정 DNS = Private Hosted Zone + Resolver Endpoint + RAM 공유 (3단계).

해설

【핵심 용어】 ▸ Public Hosted Zone — 퍼블릭 DNS 레코드 관리 ▸ TTL Propagation — DNS 레코드 전파 시간 ▸ Zone Transfer — 도메인 소유권 이전 【정답 포인트】 ▸ (1) Route 53 공개 호스팅 영역에 레코드 복사 ▸ (2) 기존 등록기관에서 네임서버를 Route 53으로 변경 ▸ (3) DNS 전파 완료 확인 후 도메인 전송 ▸ 순서 중요: 레코드 → NS 변경 → 도메인 전송 ▸ 다운타임 제거 【오답 체크】 (A) 프라이빗 호스팅 영역 — 공개 쿼리 불가 (B) 프라이빗 호스팅 영역 + 도메인 전송 먼저 — 전파 대기 중 장애 위험 (C) 레코드 복사 전에 도메인 전송 — 레코드 부재 상태 발생 【시험 포인트】 DNS 마이그레이션 = 레코드 복사 → NS 변경 + 전파 확인 → 도메인 전송 (3단계 순서 필수).

해설

【핵심 용어】 ▸ Transit Gateway Route Table — 트래픽 전파 규칙 제어 ▸ Route Table Association — 연결(attachment)을 라우트 테이블에 연결 ▸ Route Propagation — 경로 자동 학습 【정답 포인트】 ▸ (A) 프로덕션 VPC들을 기존 라우트 테이블과 연결 + 전파 ▸ (C) Direct Connect를 기존 라우트 테이블과 연결 + 전파 = 온프레미스 ↔ 프로덕션 연결 ▸ (E) 개발 VPC용 분리된 라우트 테이블 생성 + 개발만 연결 + Direct Connect와 개발만 전파 ▸ 결과: 개발 ↔ 온프레미스 O, 개발 ↔ 프로덕션 X 【오답 체크】 (B) 모든 연결 함께 — 개발 VPC가 프로덕션과 연결됨 (D) 보안 그룹 — 라우트 테이블 수준이 아님, 상위 레벨에서 해결 필요 (F) 새로운 TGW — 온프레미스 연결 분리, 복잡도 증가 【시험 포인트】 개발 격리 = 별도 라우트 테이블 + 선택적 전파 (라우팅 제어의 핵심).

해설

【핵심 용어】 ▸ Dual-Stack VIF — IPv4 및 IPv6 동시 지원 ▸ BFD (Bidirectional Forwarding Detection) — 빠른 장애 감지 ▸ BGP 피어링 분리 — IPv4/IPv6 독립 라우팅 【정답 포인트】 ▸ (A) 단일 VIF + 듀얼 피어링 = AWS 지원, 간단 ▸ (B) 두 개 VIF + 분리 피어링 = 완벽한 독립성, 권장 ▸ 두 연결 + BFD = 고가용성 + 빠른 수렴 【오답 체크】 (C) IPv6 라우트를 IPv4 피어링에서 — 혼합 불가 (D) 모든 라우트 모든 피어링 — 중복/비효율 (E) BGP hello 타이머 감소 — 권장되지 않음, 안정성 저하 【시험 포인트】 듀얼 스택 Direct Connect = (단일 VIF + 듀얼 피어링) OR (두 개 VIF + 분리 피어링) + BFD.

해설

【핵심 용어】 ▸ Split-Tunnel — VPN 경유 트래픽과 로컬 ISP 트래픽 구분 ▸ Client VPN Route Table — VPN 쪽에 가는 트래픽 선택 ▸ GeoIP Blocking — 인터넷 IP 기반 위치 추적 【정답 포인트】 ▸ 문제: 모든 트래픽 VPN 경유 → 공개 IP가 VPN 엔드포인트 위치 ▸ (B) Split-tunnel 활성화 = 로컬 인터넷 트래픽은 로컬 ISP 경유 ▸ (C) 특정 라우트 추가 = 오직 AWS/온프레미스만 VPN 사용 ▸ (F) 0.0.0.0/0 제거 = 기본 라우트 제거로 split-tunnel 강제 【오답 체크】 (A) Site-to-Site VPN 전환 — 원격 사용자 솔루션 아님 (D) 보안 그룹 수정 — 문제 해결 안 됨 (E) 엔드포인트 재생성 — 서비스 중단 과다 【시험 포인트】 Client VPN 위치 추적 = Split-tunnel + 라우트 선택 + 기본 경로 제거 (3단계).

해설

【핵심 용어】 ▸ Route 53 Resolver Outbound Endpoint — VPC DNS 쿼리 외부 포워딩 ▸ Conditional Forwarding Rule — 특정 도메인만 외부 DNS로 라우팅 【정답 포인트】 ▸ Route 53 Resolver = AWS 네이티브, 관리 최소화 ▸ 아웃바운드 엔드포인트 = VPC → 온프레미스 DNS 경로 ▸ 규칙 1개 = 모든 VPC에 자동 적용, 확장성 우수 ▸ EC2 필요 없음 = 관리 오버헤드 제거 【오답 체크】 (B) 인바운드 엔드포인트 — 온프레미스 → VPC 방향, 요구사항 반대 (C) 단일 EC2 — 단일 실패점, 고가용성 미확보 (D) VPC별 EC2 — 다중 인스턴스 관리 부담, 비용 증가 【시험 포인트】 DNS 포워딩 최소화 = Route 53 Resolver + Conditional Rule (AWS 네이티브 솔루션).

해설

【핵심 용어】 ▸ VPN Acceleration — AWS Global Accelerator 활용, 인터넷 최적화 ▸ Transit Gateway — VPC 및 온프레미스 중앙 연결 ▸ Time-to-Deploy — 가장 빠른 구현 【정답 포인트】 ▸ 가장 빠른 구현 = VPN 사용 (Direct Connect는 프로비저닝 기간 필요) ▸ 가속 활성화 = 공개 인터넷 성능 최적화 ▸ Transit Gateway = 향후 확장 가능 (다중 VPC 지원) ▸ 데이터 암호화 = IPsec VPN 자체 지원 【오답 체크】 (A) Virtual Private Gateway — 단일 VPC만, 확장성 제한 (C) Direct Connect — 구현 시간 과다 (설치 기간) (D) 가속 비활성화 — 지연 시간 미최적화 【시험 포인트】 빠른 구현 + 지연 시간 최소화 + 암호화 = VPN Acceleration + Transit Gateway의 조합.

해설

【핵심 용어】 ▸ MACsec — 링크 레벨 암호화 ▸ must_encrypt — 의무화 모드 【정답 포인트】 ▸ 온프레미스 라우터 설정 (A) — 양쪽 끝점 필요 ▸ must_encrypt 모드 (D) — 요구사항에서 "항상" 암호화 【오답 체크】 (B/C) should_encrypt는 선택적 (E) should_encrypt 부분 암호화만 【시험 포인트】 ▸ MACsec 양쪽 설정 필수 ▸ 암호화 모드 선택 = 요구사항 수준

해설

【핵심 용어】 ▸ CIDR 병합 — 21을 20으로 통합 ▸ 접두사 할당량 — 1개 슬롯만 남음 【정답 포인트】 ▸ CIDR 최적화 — 2개를 1개로 합치기 ▸ 10.0.32.0/20 범위 포함 가능 ▸ customer managed list 사용 【오답 체크】 (A) AWS 관리 목록은 수정 불가 (B) 2개 항목으로 할당량 초과 (C) AWS 관리 목록 아님 【시험 포인트】 ▸ IP 병합 이해 ▸ 할당량 관리

해설

【핵심 용어】 ▸ TGW 피어링 — 리전 간 직접연결 ▸ Network Manager — 완전 가시성 【정답 포인트】 ▸ VPN 아님 피어링 선택 ▸ Network Manager로 피어링도 모니터링 【오답 체크】 (A/B) VPN은 제한적 (C) Analyzer는 피어링 불가 【시험 포인트】 ▸ 피어링 vs VPN ▸ Network Manager 역할

해설

【핵심 용어】 ▸ Transit Gateway(TGW) — 멀티 리전/멀티 VPC 중앙 라우팅 허브 ▸ Virtual Private Gateway(VGW) — 단일 VPC 대상 VPN 엔드포인트, IPv6 제한 ▸ IPv6 듀얼 스택 — TGW 네이티브 지원, VGW 미지원 ▸ TGW 피어링 — 리전 간 게이트웨이 연결 【정답 포인트】 ▸ 다중 요구사항 분석 → 멀티 리전(us-east-1/2) + IPv6 지원 + 온프레미스 VPN ▸ TGW 선택 이유 → IPv6 네이티브 지원, 중앙식 라우팅으로 확장성 극대화 ▸ 아키텍처 → us-east-1 TGW(기존 VGW 교체) + us-east-2 TGW + TGW 피어링 연결 ▸ 일관성 → 각 TGW에서 IPv4/IPv6 Site-to-Site VPN 설정 【오답 체크】 (A) VGW us-east-1 배포만 → IPv6 미지원 오류, us-east-2 VPC 간 연결 메커니즘 부재 (C) VGW us-east-2만 → 기존 VPC와 신규 VPC 간 게이트웨이 피어링 불가, VGW는 VGW와 직접 피어링 미지원 (D) 단일 TGW us-east-1 → us-east-2 VPC를 원격 리전에서 TGW에 연결할 방법 없음(TGW는 단일 리전) 【시험 포인트】 ▸ IPv6 조건 출제 → TGW 우선 검토 지표 ▸ 멀티 리전 패턴 → "각 리전 TGW" + "피어링" 표준 구조 암기 ▸ VGW 한계 인식 → 네트워킹 기반 설계 실패점 파악 ▸ 마이그레이션 설계 → 기존 인프라(VGW) 교체 시나리오 중요

해설

【핵심 용어】 ▸ Route 53 Resolver 규칙 — 도메인별 DNS 쿼리 처리 방식 지정, forwarding rule / system rule 존재 ▸ Forwarding rule "." (루트) — 모든 도메인 쿼리를 지정 대상(온프레미스 resolver)으로 전달, 아웃바운드 엔드포인트 통해 나감 ▸ Private hosted zone 우선순위 — 더 구체적인(연결된 PHZ) 도메인은 PHZ가 우선 해석, 나머지는 forwarding rule 적용 【정답 포인트】 ▸ "aws.example.internal은 PHZ, 나머지 전부는 온프레미스로 포워딩" → "."(모든 도메인)에 대한 forwarding rule을 아웃바운드 엔드포인트로 설정 ▸ PHZ에 연결된 aws.example.internal 쿼리는 PHZ가 더 구체적이므로 자동 우선 해석, 그 외는 "." 규칙으로 온프레미스 전달 【오답 체크】 (A) forwarding rule 대상은 IP인데 "system rule이 Resolver를 타겟"이라는 구성이 부정확, "*" 와일드카드도 부적절. (B) aws.example.internal은 PHZ가 처리하므로 별도 forwarding rule 불필요, "." system rule 구성도 잘못됨. (C) "*"는 Resolver 규칙의 올바른 도메인 표기가 아님("."이 루트/전체 표기). 【시험 포인트】 "특정 도메인은 PHZ, 나머지는 온프레미스" → "."(루트) forwarding rule + PHZ 자동 우선.

해설

【핵심 용어】 ▸ VPN ECMP — 다중 VPN 터널을 equal-cost multi-path로 묶어 대역폭 집계(터널당 ~1.25Gbps 한계 극복) ▸ Jumbo MTU on VPN — Site-to-Site VPN은 점보 프레임 미지원(최대 MTU 제한), 활성화 불가 ▸ 최신 인스턴스 타입 + 점보 프레임 — 네트워크 성능 향상, EC2 측 처리량 개선 【정답 포인트】 ▸ "8K로 파일 3배 커지고 업로드 10배 느림" → (A) 오피스별 두 번째 VPN 터널 + ECMP로 대역폭 확장 ▸ (D) EC2를 최신 인스턴스 타입으로 업그레이드하고 OS에서 점보 프레임 활성화해 처리량 향상 【오답 체크】 (B) transit gateway VPN 터널은 Jumbo MTU를 지원하지 않아 활성화 불가. (C) VPN 터널에 "acceleration 활성화"라는 옵션은 존재하지 않음(가속은 별도 개념). (E) IGMP는 멀티캐스트 그룹 관리 프로토콜로 업로드 대역폭과 무관. 【시험 포인트】 "VPN 대역폭 증대" → 다중 터널 + ECMP. 인스턴스/네트워크 성능은 최신 타입.