정답 · 해설

해설

【핵심 용어】 ▸ Site-to-Site VPN — 임시 연결용 빠른 구성 ▸ Resolver Outbound Endpoint — AWS→온프레미스 DNS 쿼리 전달 ▸ Direct Connect — 영구적 회선 (이 요구사항엔 오버스펙) 【정답 포인트】 ▸ VPN으로 충분 (B 오답): 3개월 임시이므로 Direct Connect 불필요 ▸ 아웃바운드 엔드포인트만 필요: AWS→온프레미스 DNS 해석만 필요 ▸ 최소 구성: VPN + Outbound Endpoint로 가장 간단한 해결 【오답 체크】 (B) Direct Connect는 고비용이며 3개월 임시 요구사항에 부적합 (C) Client VPN은 클라이언트 기반이며 서버(EC2) DNS 해석에 미흡 (D) 공개 VIF는 온프레미스 프라이빗 도메인 해석 불가 【시험 포인트】 단기 마이그레이션 DNS 요구는 VPN + Resolver Outbound 최소 조합. 아웃바운드만 필요한 이유는 EC2가 AWS에서 온프레미스로 쿼리를 던지는 일방향 요구사항.

해설

【핵심 용어】 ▸ AWS Config Rules — 구성 규정준수 자동 감지 ▸ Systems Manager Automation — 복구 작업 자동 실행 ▸ GuardDuty — 보안 위협 감지 (구성 감시 아님) 【정답 포인트】 ▸ Config 규칙: 보안 그룹 상태 감시 표준 도구 ▸ Systems Manager Runbook: 자동 복구 표준 패턴 ▸ 두 서비스의 자동 연동: Config 위반 감지 시 Runbook 자동 실행 【오답 체크】 (A) GuardDuty는 보안 위협 탐지용, 구성 상태 감시 미지원 (B) OpsWorks for Chef는 보안 그룹 복구 미지원 (C) GuardDuty + OpsWorks 조합은 부적절한 서비스 짝짓기 【시험 포인트】 구성 규정준수 + 자동 복구는 Config Rules + Systems Manager Automation 표준 패턴. GuardDuty는 보안 위협(malware, 비정상 동작)용이지 구성 감시가 아님.

해설

【핵심 용어】 ▸ Gateway Load Balancer — 네트워크 어플라이언스용 로드 밸런서 ▸ Dual ENI — 프라이빗(수신) + 퍼블릭(발신) 구성 ▸ Appliance NAT — 방화벽 자체 NAT 활용 【정답 포인트】 ▸ GWLB 필수 (C, D 오답): NLB는 어플라이언스 처리 불최적 ▸ 2개 ENI 설계: 인입(프라이빗) + 아웃바운드(퍼블릭) 분리 ▸ 방화벽 NAT 활용: 별도 NAT Gateway 비용 절감 (B vs A 비용) ▸ 비용 최소화: 방화벽 내장 NAT 활용 【오답 체크】 (A) NAT Gateway 추가 비용 발생 (C) NLB는 L4 로드 밸런싱만 가능, 어플라이언스 특화 부족 (D) NLB + 방화벽 NAT는 아키텍처 효율 떨어짐 【시험 포인트】 방화벽 어플라이언스 + 로드 밸런싱은 GWLB 필수. 인바운드(수신) + 아웃바운드(발신) 분리를 위해 Dual ENI 패턴을 사용하고, 방화벽 자체 NAT로 비용 최소화.

해설

【핵심 용어】 ▸ Resolver Outbound Endpoint — AWS VPC→온프레미스 DNS 쿼리 전달 ▸ Resolver Rules — DNS 도메인별 포워딩 규칙 ▸ Resolver 규칙 공유 — RAM으로 여러 VPC에 전파 【정답 포인트】 ▸ 아웃바운드 엔드포인트 필수: AWS→온프레미스 DNS 해석 ▸ 규칙 공유로 중앙화: 각 VPC가 온프레미스 도메인 해석 가능 ▸ DHCP 변경 불필요: Resolver 규칙은 DNS 쿼리를 자동 가로채고 전달 ▸ Private Hosted Zone: VPC 로컬 도메인은 Route 53이 기본 처리 【오답 체크】 (A) 인바운드 엔드포인트는 온프레미스→AWS 해석용 (반대 방향) (C) DHCP 변경은 불필요 (Resolver 규칙이 투명하게 처리) (D) 규칙 공유 없이는 각 VPC가 온프레미스 도메인 해석 불가 【시험 포인트】 멀티 VPC + 온프레미스 DNS 통합은 Resolver Outbound + Rules Association 패턴. DHCP 변경은 과거 방식이며 Resolver 규칙 공유만으로 충분.

해설

【핵심 용어】 ▸ VPC Flow Logs — 전체 네트워크 트래픽 기록 ▸ Amazon Athena — 로그 데이터 SQL 쿼리 ▸ Non-intrusive Monitoring — 가동 중단 없이 분석 【정답 포인트】 ▸ Flow Logs + Athena: 트래픽 분석으로 포트 사용 직접 확인 ▸ 무중단 검증: 실행 중인 트래픽만 조사, 시스템 변경 없음 ▸ 정확한 포트 감시: 임시 포트와 구분 가능 ▸ 이력 추적: S3 보관으로 포트 사용 패턴 분석 【오답 체크】 (A) Inspector는 취약점 검사용, 포트 청취 상태 감시 미흡 (B) GuardDuty는 보안 위협 감지용, 프로토콜 마이그레이션 검증 부적합 (D) 보안 그룹 변경은 즉시 가동 중단 위험 및 문제 식별 미흡 【시험 포인트】 프로토콜 마이그레이션 검증은 VPC Flow Logs + Athena 조합. 무중단이면서도 정확한 트래픽 패턴 분석 가능.

해설

【핵심 용어】 ▸ Transit Gateway Route Table — VPC 간 트래픽 경로 제어 ▸ Association — 어태치먼트와 경로 테이블 연결 ▸ Propagation — 경로 자동 전파 【정답 포인트】 ▸ C: 1개 AppVPC RT로 모든 앱 VPC 격리 + 공유 서비스/온프레미스 통신 - AppVPC들은 단일 RT에 묶여 서로 격리 (RT 간 경로 없음) - Shared SVC + VPN이 전파되어 양방향 통신 가능 ▸ E: 1개 Shared+OnPrem RT로 모든 앱 VPC와 통신 - VPN과 Shared SVC가 동일 RT로 단순화 - 모든 AppVPC가 이들과 통신 가능 【오답 체크】 (A) OnPrem만의 RT는 AppVPC-OnPrem 통신만 가능, Shared SVC 통신 불가 (B) 각 AppVPC마다 RT 필요 (수백 개RT = 비효율) (D) AppVPC들이 Shared SVC와만 통신, OnPrem 미지원 【시험 포인트】 TGW 경로 테이블 최소화는 격리(AppVPC 간)와 연결(Shared/OnPrem)의 균형. C는 AppVPC 단일화, E는 Shared/OnPrem 단일화로 각각 다른 방식의 최적화.

해설

【핵심 용어】 ▸ Route 53 Resolver Rule — DNS 도메인별 포워딩 ▸ Domain Matching — 특정 도메인 쿼리만 선택적 전달 ▸ VPC-wide Solution — 단일 인스턴스 아님 【정답 포인트】 ▸ Resolver Rule 필수: 모든 VPC 리소스에 적용 (확장성) ▸ 선택적 포워딩: example.internal만 온프레미스로 전달 ▸ 투명성: DHCP나 호스트 파일 변경 없이 중앙식 관리 ▸ VPC 전체 적용: 다른 리소스도 자동으로 혜택 【오답 체크】 (A) DHCP 옵션은 VPC 전체 DNS를 변경하여 AWS 리소스(RDS 시크릿) 조회 실패 위험 (C) 호스트 파일은 단일 인스턴스만 해결, 다른 EC2 미지원 (D) /etc/resolv.conf 수정은 AWS 리소스 DNS 해석 불가 【시험 포인트】 하이브리드 DNS 선택적 포워딩은 Route 53 Resolver Rule 표준. 특정 도메인만 온프레미스로 전달하고 나머지는 AWS VPC 기본 DNS 유지.

해설

【핵심 용어】 ▸ Managed Prefix List — AWS 리소스에서 직접 참조 가능한 IP 목록 ▸ AWS RAM — 계정 간 리소스 공유 ▸ Security Group Reference — SG에서 Prefix List 직접 사용 【정답 포인트】 ▸ Prefix List 사용: AWS 네이티브 기능, 자동 동기화 ▸ RAM 공유: 한 곳에서 업데이트 시 모든 계정에 반영 ▸ 중앙화 관리: 각 계정에서 별도 Lambda 배포 불필요 ▸ 운영 효율: Prefix List 변경만으로 SG 자동 업데이트 【오답 체크】 (A) DynamoDB + Lambda는 각 계정마다 배포 및 트리거 필요 (복잡) (B) EventBridge + Lambda는 변경 감지 이벤트 필요 (지연 가능성) (D) S3 + Lambda는 poll 기반이며 비용 및 운영 오버헤드 증가 【시험 포인트】 멀티 계정 중앙화 IP 관리는 Managed Prefix List + RAM 표준 패턴. Prefix List를 SG에서 직접 참조하면 수동 업데이트 불필요.

해설

【핵심 용어】 ▸ Direct Connect — 온프레미스 사용자 트래픽 증가 ▸ VPN — 원격 직원용 저비용 솔루션 ▸ 대역폭 분산 — VPN으로 원격 트래픽 분리 【정답 포인트】 ▸ 비용 효율: VPN 추가는 Direct Connect 신규 구매보다 저렴 ▸ 부하 분산: 원격 직원을 VPN으로 분리하여 Direct Connect 여유 생성 ▸ 20% 필요 증가: 추가 Direct Connect (1 Gbps) 비용 > VPN 비용 ▸ 트래픽 분리: 온사이트(Direct Connect) vs 원격(VPN) 【오답 체크】 (A) 새 Direct Connect는 비용이 높고 원격 직원 분산 미지원 (C) Workspaces는 선택지가 아니며 인프라 근본 해결 불가 (D) 2 Gbps 호스팅 연결로 교체는 과도한 비용 + Client VPN 혼재 【시험 포인트】 제한된 예산에서 원격 + 온프레미스 복합 네트워크 문제는 VPN으로 원격 트래픽 분산. Direct Connect는 온프레미스(지속적) 용도로 유지.

해설

【핵심 용어】 ▸ Network Manager Route Analyzer — Transit Gateway 경로 검증 ▸ VPC Flow Logs — 패킷 레벨 트래픽 분석 ▸ 리전 간 연결 진단 — 계층적 접근 【정답 포인트】 ▸ Route Analyzer 필수: TGW 경로 테이블의 정확성 확인 (리전 간) ▸ Flow Logs 필수: 보안 그룹/NACL 검증 (마지막 홉) ▸ 2단계 검증: 경로 정확성 + 보안 정책 ▸ VPC 경로 테이블도 확인: 엔드포인트 EC2 도달성 【오답 체크】 (A) Route Analyzer가 VPC 경로 테이블 직접 분석 불가 (B) Firewall Manager는 정책 관리용, 실시간 트래픽 분석 미지원 (D) Reachability Analyzer는 VPC Endpoint용, TGW 경로 분석 불가 【시험 포인트】 리전 간 Transit Gateway 연결 문제 진단은 Route Analyzer (경로 검증) + Flow Logs (패킷 검증) 2단계. Reachability Analyzer는 같은 리전 검증용.

해설

【핵심 용어】 ▸ Direct Connect Hosted Connection — APN 파트너 제공 회선 ▸ Private VIF — VPC 접속용 가상 인터페이스 ▸ Site-to-Site VPN — 전송 암호화 ▸ Public VIF — 퍼블릭 AWS 서비스 접속 【정답 포인트】 ▸ A (Hosted Connection): APN 파트너를 통한 Direct Connect 회선 (전용 대역폭) ▸ C (Site-to-Site VPN): IPsec 암호화 터널 (전송 암호화) ▸ F (Public VIF): 직접 연결 시 퍼블릭 AWS 서비스 접근 가능 【조합 로직】 - A: 전용 회선 물리 레이어 - C: IPsec 암호화 - F: VPC 데이터센터 간 통신 시 퍼블릭 VIF 경로 【오답 체크】 (B) 호스팅 공개 VIF는 APN 파트너의 공개 AWS 서비스용 (VPC 미지원) (D) Client VPN은 클라이언트 기반이며 서버 간 통신 미지원 (E) 프라이빗 VIF만으로는 암호화 불가 (VPN 추가 필요) 【시험 포인트】 전용 대역폭 + 암호화는 Direct Connect + Site-to-Site VPN 조합 (DC의 물리 전용성 + VPN의 암호화 결합).

해설

【핵심 용어】 ▸ Enhanced Networking — SR-IOV로 높은 처리량 + 낮은 지연 ▸ Instance Size — EC2 네트워크 성능 스케일 ▸ Network Performance — 데이터센터 간 처리량 【정답 포인트】 ▸ A (Enhanced Networking): 네트워크 인터페이스 성능 향상 (중요) ▸ C (Instance Size 증가): 더 큰 인스턴스는 더 높은 네트워크 성능 제공 ▸ 이 두 요소가 전체 성능 개선에 결정적 【오답 체크】 (B) Transit Gateway는 라우팅 최적화이지 인스턴스 성능 개선 아님 (D) 배치 그룹은 같은 가용성 영역 내 지연 감소이지 온프레미스 성능 미지원 (E) 여러 ENI는 부하 분산만 제공, 단일 어플라이언스 성능 미개선 【시험 포인트】 보안 어플라이언스(NVA) 성능은 Enhanced Networking + 인스턴스 크기가 핵심. 배치 그룹은 VPC 내부 지연용이며 온프레미스 연결과는 무관.

해설

【핵심 용어】 ▸ CIDR 블록 — VPC IP 주소 범위 ▸ 보조 CIDR — 기존 블록과 비겹치는 추가 범위 ▸ CIDR 겹침 — 같은 주소 공간 충돌 금지 【정답 포인트】 ▸ 172.16.0.0/16은 172.16.0.0 ~ 172.16.255.255 ▸ 추가 블록은 기존과 겹치지 않아야 함 ▸ 172.17.0.0/16은 172.17.0.0 ~ 172.17.255.255 (별개) ▸ /16 크기로 충분한 주소 공간 제공 【오답 체크】 (A) 172.17.0.0/29는 너무 작음 (8개 주소만) (B) 10.0.0.0/16은 RFC 1918 프라이빗이지만 온프레미스와 겹칠 가능성 (D) 192.168.0.0/16도 프라이빗 범위이지만 온프레미스 기본값과 충돌 가능 【시험 포인트】 VPC 보조 CIDR은 기존 블록과 완전히 분리된 범위여야 하고, /16 크기는 대규모 확장에 충분. 같은 네트워크 대역(172)에서 다른 옥텟으로 선택.

해설

【핵심 용어】 ▸ VPC Traffic Mirroring — 프로덕션 미지원 패킷 복제 ▸ 모니터링 계정 분리 — 프로덕션 직접 접근 금지 ▸ UDP 필터 — 특정 포트 트래픽만 캡처 【정답 포인트】 ▸ C (Traffic Mirroring): 프로덕션 트래픽 무중단 복제 ▸ 모니터링 계정 대상: 프로덕션 접근 원칙 준수 ▸ 패킷 검사: tcpdump 등으로 분석 (프로덕션 아님) ▸ UDP 포트 50000만 선택적 캡처 【오답 체크】 (A) Flow Logs는 메타데이터만 (요청/응답 페이로드 미포함) (B) 프로덕션 계정 내 모니터링 EC2 = 직접 접근 위반 (D) 프로덕션 EC2에 로그인 = 직접 접근 금지 위반 【시험 포인트】 프로덕션 패킷 분석 + 접근 금지는 VPC Traffic Mirroring + 별도 모니터링 계정이 표준. 미러링은 원본 트래픽에 영향 없음.

해설

【핵심 용어】 ▸ Asymmetric Routing — 인입/송출 경로 불일치 문제 ▸ BGP ECMP — 양쪽 터널 능동 사용 ▸ VTI Configuration — 터널 인터페이스 설정 【정답 포인트】 ▸ C (VTI Asymmetric Routing): 고객 게이트웨이에서 비대칭 라우팅 허용 ▸ BGP ECMP 유지: 양쪽 터널 사용 (대역폭 보전) ▸ 라우팅 역방향 문제 해결: VTI가 터널 간 교차 처리 가능 ▸ 능동-능동 모드 지속: 로드 밸런싱 유지 【오답 체크】 (A) AS PATH prepending은 선호 터널을 지정하지만 ECMP 목표와 충돌 (B) 기본 터널 지정은 ECMP 비활성화 (대역폭 감소) (D) 정적 라우팅은 ECMP 미사용 (대역폭 낭비) 【시험 포인트】 비대칭 라우팅 (인 다른 터널, 아웃 다른 터널)은 고객 게이트웨이 VTI 설정으로 해결. BGP ECMP 유지하며 터널 간 교차 라우팅 허용.

해설

【핵심 용어】 ▸ IdleTimeoutCount — NAT 게이트웨이가 유휴 연결을 종료한 횟수 ▸ TCP keepalive — 연결 유지를 위한 정기적인 신호 전송 【정답 포인트】 ▸ 6분 비활성 → NAT 게이트웨이의 기본 유휴 타임아웃(300초) 문제 ▸ IdleTimeoutCount 지표로 유휴 연결 종료 확인 ▸ 애플리케이션 레벨 keepalive 설정으로 연결 유지 【오답 체크】 (B) ErrorPortAllocation — 포트 할당 고갈 문제, 6분 타이밍과 무관 (C) PacketsDropCount — 패킷 손실 지표, 타임아웃과 다른 증상 (D) UDP keepalive — TCP 연결 문제이며 UDP는 비상태 프로토콜 【시험 포인트】 NAT 게이트웨이 타임아웃 = 300초(5분), 인액티비티 모니터링과 TCP keepalive 설정이 핵심 해결책입니다.

해설

【핵심 용어】 ▸ AWS PrivateLink — VPC 간 비노출 프라이빗 연결 ▸ Transit Gateway — 다중 VPC/온프레미스 연결의 중앙 허브 【정답 포인트】 ▸ AWS 고객: PrivateLink로 직접 접근 (NAT 규칙 복잡성 제거) ▸ 온프레미스: 타사 어플라이언스로 IPsec VPN 종료 ▸ 확장성 + 보안 + 관리 용이 【오답 체크】 (A) Transit Gateway — 온프레미스 고객에만 적합, AWS VPC 고객은 직접 접근 불가 (C) VPC Peering — 일대일 관계, 다중 고객 관리 복잡 (D) 모든 연결을 VPN으로 — PrivateLink의 장점 미활용 【시험 포인트】 PrivateLink = 수평적 확장, VPN 없이 프라이빗 서비스 노출. Transit Gateway = 수직적 중앙화 아키텍처.

해설

【핵심 용어】 ▸ Gateway Load Balancer (GLB) — Layer 3/4 트래픽 검사를 위한 엔드포인트 서비스 ▸ Gateway Route Table — 트래픽을 GLB 엔드포인트로 리다이렉트하는 라우팅 【정답 포인트】 ▸ 인터넷 게이트웨이 → 애플리케이션 서브넷: gateway route table으로 GLB 엔드포인트 경유 ▸ 애플리케이션 서브넷의 각 EC2: 인터넷 응답도 GLB 거쳐서 반환 ▸ Appliance VPC는 별도 관리, 애플리케이션 VPC와 분리 【오답 체크】 (A) Transit Gateway — 독립 VPC 방화벽 검사에 부적합 (B) 단방향 라우팅 — 응답 트래픽이 GLB를 우회 (D) GLB를 애플리케이션 VPC로 이동 — 분리 구조 위배 【시험 포인트】 Gateway route table + GLB endpoint = 양방향 트래픽 인터셉션 (인바운드/아웃바운드 모두).

해설

【핵심 용어】 ▸ Dead Peer Detection (DPD) Restart — 비응답 피어 감지 시 IKE 자동 재시작 ▸ DPD timeout action — 피어 응답 없을 때 취할 행동 【정답 포인트】 ▸ DPD Restart = IKE 다운 감지 시 자동 재협상 시도 ▸ 온프레미스 → VPC 트래픽 시작이 키: 응답 확인으로 IKE 복구 트리거 ▸ 단방향 트래픽 문제 시 응답 방향 강제 필요 【오답 체크】 (A) Clear — 연결 종료만 함, 재시작 없음 (C) None — DPD 비활성화, 재협상 불가 (D) Cancel — 존재하지 않는 옵션 【시험 포인트】 DPD Restart + 양방향 트래픽 흐름 = VPN 세션 자동 복구의 핵심 메커니즘.

해설

【핵심 용어】 ▸ Transit Gateway Peering — 리전 간 TGW 연결 ▸ ECMP (Equal-Cost Multipath) — 다중 경로 로드밸런싱 ▸ Transit VIF — Direct Connect 상의 전이 라우팅 【정답 포인트】 ▸ 4개 1Gbps 연결 = 2Gbps 이상 대역폭 보장 (ECMP로 로드밸런싱) ▸ TGW Peering = 3개 리전 간 메시 연결 ▸ Inspection VPC = 중앙 방화벽 집중관리 ▸ Direct Connect 게이트웨이 = 온프레미스 통합 【오답 체크】 (A) IPsec VPN — 2Gbps 대역폭 미만, 확장성 제한 (B) VPC별 10Gbps — 비용 과다, 비효율적 아키텍처 (C) 2개 1Gbps 연결 — 대역폭 부족 【시험 포인트】 멀티리전 + 고가용성 + 2Gbps+ = Transit Gateway Peering + Direct Connect + ECMP의 조합.