정답 · 해설

해설

【핵심 용어】 ▸ Interface VPC Endpoint — ENI 기반 AWS 서비스 연결. VPC 내부에서만 접근 가능 ▸ Security Group — Stateful 방화벽. 인바운드와 아웃바운드 통제 【정답 포인트】 ▸ 인바운드 규칙 1 제거 → 0.0.0.0/0은 불필요. VPC 내부 리소스만 액세스 필요 ▸ 인바운드 규칙 2 유지 → VPC CIDR에서만 443 포트 허용으로 충분 ▸ 아웃바운드 규칙 1 제거 → 모든 트래픽 허용은 과도. Stateful이므로 응답 자동 허용 ▸ 아웃바운드 규칙 필요 없음 → Interface VPC Endpoint는 VPC 내부이므로 아웃바운드 규칙 불필요 【오답 체크】 (A) 아웃바운드 규칙 2가 주어지지 않음 (C) 인바운드 규칙 2도 불필요한가? 아니, VPC CIDR만 필요 (D) 아웃바운드 규칙 1만으로는 부족. 인바운드 규칙 1도 제거 필요 【시험 포인트】

해설

【핵심 용어】 ▸ Prefix List — VPC CIDR 범위들을 그룹화하여 관리 ▸ Customer-managed Prefix List — 사용자가 직접 관리하는 접두사 목록 ▸ Route Propagation — Transit Gateway가 라우트 자동 전파 【정답 포인트】 ▸ 운영 효율성 최고 → Prefix List 생성 후 추가 라우트 테이블마다 재사용 ▸ 확장성 → 새 VPC 추가 시 Prefix List에만 추가하면 모든 라우트 테이블이 자동 적용 ▸ 중앙 집중식 관리 → Prefix List가 단일 지점에서 VPC CIDR 관리 【오답 체크】 (B) Route Propagation도 작동하지만, VPC 라우트 테이블에서 각각 활성화해야 함. 초기 구성 비용 높음 (C) 0.0.0.0/0은 모든 트래픽을 Transit Gateway로 보냄. NAT Gateway 등의 로컬 라우팅 불가능 (D) Association은 전파와 다른 개념. 경로 제한 증가 【시험 포인트】

해설

【핵심 용어】 ▸ Site-to-Site VPN — AWS와 온프레미스 간의 암호화 연결 ▸ IPv6 Support — VPN 터널이 IPv6 트래픽 지원 필요 ▸ Transit Gateway — 중앙 라우팅 【정답 포인트】 ▸ 기존 VPN IPv6 미지원 → IPv4 기반 VPN은 IPv6 트래픽 통과 불가 ▸ 새 VPN 연결 생성 → IPv6 지원 VPN을 별도로 생성 ▸ 최소 오버헤드 → 기존 IPv4 VPN 유지하면서 IPv6 전용 VPN 추가 ▸ 병렬 운영 → IPv4와 IPv6 동시 지원 【오답 체크】 (B) 자체 관리 EC2는 복잡성 증가. AWS 관리형이 나음 (C) 기존 VPN은 IPv6 업그레이드 불가능. 프로토콜 수준의 제약 (D) Public IP 변경만으로는 VPN IPv6 지원 안 됨 【시험 포인트】

해설

【핵심 용어】 ▸ Resource Access Manager(RAM) — 계정 간 AWS 리소스 공유 ▸ Transit Gateway Sharing — RAM을 통한 TGW 공유 ▸ Least Operational Overhead — 최소한의 변경 【정답 포인트】 ▸ TGW-A 재사용 → 이미 구성된 TGW-A를 Account B와 공유하여 활용 ▸ Account A 중심 구조 → TGW-A의 리소스 공유만으로 충분 ▸ 최소 변경 → Account A의 라우팅은 유지. Account B만 TGW-A 연결 추가 ▸ 가장 간단한 마이그레이션 → TGW-B만 제거 【오답 체크】 (B) 자동 복제 기능 없음. TGW 설정은 수동 구성 필요 (C) 새 TGW 생성으로 운영 오버헤드 증가. Account A의 라우팅도 변경 필요 (D) 별도 Account C 생성은 불필요한 복잡성. Account A 중심이 더 간단 【시험 포인트】

해설

【핵심 용어】 ▸ Certificate-based VPN — 인증서를 사용한 VPN 인증 (PSK 대체) ▸ Private Certificate — ACM Private CA에서 발급한 프라이빗 인증서 ▸ Customer Gateway — 온프레미스 VPN 엔드포인트 【정답 포인트】 ▸ 프라이빗 인증서 생성 → AWS Certificate Manager(ACM)의 Private CA를 사용하여 프라이빗 인증서 발급 (B) ▸ 동적 IP 주소 지원 → Customer Gateway 생성 시 IP 주소를 지정하지 않으면 동적 IP 변경 시에도 작동 (E) ▸ 인증서 기반 → PSK 대신 인증서 사용으로 더 강력한 인증 【오답 체크】 (A) 공개 인증서는 인터넷 기반 HTTPS용. VPN에는 프라이빗 인증서 필요 (C) 인증서 기반이므로 PSK 불필요 (D) 동적 IP이므로 IP를 지정할 수 없음. 지정하면 변경 시 작동 안 함 【시험 포인트】

해설

【핵심 용어】 ▸ AWS Config Rule — AWS 리소스의 준수 상태를 모니터링 ▸ Auto Remediation — 자동 수정 기능. 규칙 위반 시 자동 조치 ▸ AWS Organizations — 여러 계정의 중앙 관리 【정답 포인트】 ▸ AWS Config 규칙 생성 → VPC Flow Logs 설정 상태 자동 모니터링 ▸ 자동 수정 기능 → VPC 생성 시 Flow Logs가 자동 설정됨 ▸ 조직 적용 → 모든 계정과 리전에 일괄 적용 ▸ 최소 관리 노력 → 일단 설정되면 지속적 관리 불필요 【오답 체크】 (A) IAM은 사전 예방이지만, 모든 사용자의 권한 관리 복잡 (C) Transit Gateway만 설정. VPC 개별 설정 필요 (D) CloudTrail + Lambda는 복잡하고 관리 오버헤드 높음 【시험 포인트】

해설

【핵심 용어】 ▸ VPC Traffic Mirror — 프로덕션 트래픽을 방해하지 않고 네트워크 트래픽을 복사하여 분석 ▸ Flow Logs — 기본 5-튜플 정보만 캡처 (TCP payload 미포함) ▸ Traffic Mirror — TCP 페이로드의 처음 8바이트까지 캡처 가능 【정답 포인트】 ▸ TCP 세그먼트 첫 8바이트 요구 → Traffic Mirror만 이를 지원 ▸ NAT 게이트웨이 미러링 → Traffic Mirror는 NAT 게이트웨이 미러를 지원 (EC2 미러 불가) ▸ S3 저장 → 대규모 데이터 저장에 적합 【오답 체크】 (A) EC2를 미러 소스로 설정 불가 - Flow Logs는 인스턴스 레벨 메타데이터 기록 (C) VPC Flow Logs는 TCP payload를 캡처하지 않음 - IP/포트/프로토콜만 기록 (D) Flow Logs에서 사용자 정의 형식도 payload 데이터 불포함 【시험 포인트】 Traffic Mirror는 패킷 페이로드 캡처가 필요할 때 선택 → NAT 게이트웨이 미러링 지원 → S3에 저장하여 Athena로 분석

해설

【핵심 용어】 ▸ Origin Failover — CloudFront의 자동 장애 조치 메커니즘 ▸ Connection Timeout — 오리진 연결 제한 시간 ▸ Connection Attempts — 실패 시 재시도 횟수 【정답 포인트】 ▸ Timeout 5초 + Attempts 2회 = 최대 10초 → 15초 요구사항 충족 ▸ CloudFront 기본 기능으로 자동 장애 조치 지원 ▸ 추가 코드/함수 없이 관리 오버헤드 최소 【오답 체크】 (A) Lambda@Edge 함수는 운영 오버헤드 증가, 10초 폴링으로는 15초 요구사항 충족 어려움 (B) NLB 도입으로 아키텍처 복잡도 증가 (D) Lambda@Edge 모니터링도 추가 관리 필요, 10초 감지 → 15초 초과 가능 【시험 포인트】 CloudFront 자체 장애 조치 기능 활용 → Timeout × Attempts로 시간 계산 → 추가 인프라 불필요

해설

【핵심 용어】 ▸ Global Accelerator Attachment — 엔드포인트 리소스를 가속기에 연결 ▸ Cross-Account Attachment — 다른 계정의 리소스를 공유 가능하게 함 ▸ Resource Sharing — 크로스 계정 리소스 공유 메커니즘 【정답 포인트】 ▸ Account-B의 ALB가 이미 존재 → NLB 추가 구축 불필요 ▸ Global Accelerator는 Account-A(네트워킹)에서 관리 ▸ Cross-account attachment로 간단한 공유 구성 ▸ RAM 공유보다 Global Accelerator 전용 attachment 메커니즘이 더 직관적 【오답 체크】 (A) ALB가 있는 Account-B에서 생성하면 Account-A 팀이 관리하기 복잡 (B) 불필요한 NLB 추가로 오버헤드 증가 (D) RAM 공유는 Global Accelerator 자체 공유 기능보다 관리 복잡 【시험 포인트】 Global Accelerator 크로스 계정 첨부 기능 활용 → Account-B에서 Account-A로 공유 → Account-A에서 단일 관리

해설

【핵심 용어】 ▸ Direct Connect SiteLink — 온프레미스 사이트 간 통신을 AWS를 거쳐 라우팅 ▸ Transit VIF — Transit Gateway 연결용 가상 인터페이스 ▸ Private VIF — VPC 연결용 가상 인터페이스 【정답 포인트】 ▸ 기존 Direct Connect gateway 재사용 → 관리 단순화 ▸ SiteLink로 유럽 온프레미스 ↔ 미국 온프레미스 직접 연결 ▸ 새 리전 VPC 불필요 (3년간 AWS 미사용) ▸ Transit VIF로 기존 transit gateway와 직접 연동 【오답 체크】 (B) 새 리전에 gateway/TGW 구축 불필요 → 비용/복잡도 증가 (C) Private VIF는 VPC 연결용 → 온프레미스 ↔ 온프레미스 통신에 부적합 (D) us-east-1 VPC 신규 구축으로 오버헤드 증가 【시험 포인트】 Direct Connect SiteLink는 온프레미스 사이트 간 AWS 경유 통신 → 기존 gateway에 VIF 추가 → 최소 오버헤드

해설

【핵심 용어】 ▸ Direct Connect Gateway — 여러 VPC/Region 연결을 중앙화 ▸ Transit VIF — Transit Gateway로의 Virtual Interface ▸ Security Isolation — 계정 간 인프라 분리 【정답 포인트】 ▸ 기존 10 Gbps 연결 하나로 충분 (두 계정 모두 한 리전에서) ▸ 별도 DX Gateway로 계정 간 보안 분리 ▸ 새 연결 비용 불필요 (확장 계획 없음) ▸ 기존 10 Gbps 대역폭으로 7개 TGW 모두 수용 가능 【오답 체크】 (A) 단일 DX Gateway는 계정 간 분리 부족 → 보안 요구사항 미충족 (C) 불필요한 추가 10 Gbps 연결 비용 증가 (D) (C) 와 동일한 추가 비용 문제 【시험 포인트】 Direct Connect Gateway 별도 생성으로 계정 분리 → 기존 연결 활용 → 비용 최소화

해설

【핵심 용어】 ▸ Network Manager — 글로벌 네트워크 가시성 및 모니터링 ▸ Infrastructure Performance — 리전 간 지연 시간 메트릭 수집 ▸ 30일 메트릭 저장 — CloudWatch 메트릭 보존 기능 【정답 포인트】 ▸ Network Manager Infrastructure Performance는 리전 간 지연 시간 측정 전문 ▸ CloudWatch에 메트릭 발행 → 30일 이상 보존 가능 ▸ 히스토리 데이터 조회 가능 (최소 30일) ▸ 다중 리전 확장에 필요한 지연 시간 메트릭 수집 【오답 체크】 (A) Network Access Analyzer는 연결성 검증용 → 지연 시간 메트릭 미제공 (C) Reachability Analyzer는 경로 분석만 → 지연 시간 메트릭 미제공 (D) VPC Flow Logs는 트래픽 로깅 → 지연 시간 메트릭 직접 포함 안 함 【시험 포인트】 Network Manager Infrastructure Performance로 리전 간 지연 시간 수집 → CloudWatch 저장 → 30일 이상 히스토리 유지

해설

【핵심 용어】 ▸ Local Preference BGP Community Tag — AWS Direct Connect에서 지원하는 커뮤니티 태그 ▸ 7224:9300 — 높은 로컬 선호도 (preferred primary path) ▸ 7224:9100 — 낮은 로컬 선호도 (backup path) 【정답 포인트】 ▸ AWS Direct Connect는 특정 커뮤니티 태그만 인식 (7224:93xx, 7224:91xx) ▸ 7224:9300 > 7224:9100 → 액티브-패시브 설정 ▸ 데이터 센터에서 태그 적용 시 VPC로의 인바운드 영향 ▸ Direct Connect Gateway를 통한 리전 간 라우팅 제어 【오답 체크】 (A) 로컬 선호도는 온프레미스에서만 작동 → VPC의 인바운드 제어 불가 (B) AS path prepending은 비효율적 → Direct Connect는 커뮤니티 태그 선호 (C) 잘못된 커뮤니티 태그값 (7224:73xx, 7224:71xx) → AWS에서 인식 안 함 【시험 포인트】 Direct Connect 특정 커뮤니티 태그 사용 (7224:93xx) → 데이터 센터에서 설정 → VPC 인바운드 경로 제어

해설

【핵심 용어】 ▸ Redundancy — 단일 실패점 제거 ▸ TunnelState Alarm — VPN 터널 상태 모니터링 (0=down, 1=up) ▸ ISP 다중화 — 인터넷 연결 중복성 【정답 포인트】 ▸ 두 번째 customer gateway + ISP로 완전한 중복성 확보 ▸ 첫 ISP/gateway 실패 시 자동 장애 조치 ▸ TunnelState < 1 (0 감지) → 하나 이상 터널 다운 감지 → SNS 알림 ▸ 1주일 내 구현 가능 (비용 효율적) 【오답 체크】 (A) 라우터 교체만으로 ISP 이중화 불가 → 같은 ISP 실패점 (C) Direct Connect는 VPN 대체 불가 (다른 서비스) → 오버헤드 증가 (D) 같은 ISP 사용 → ISP 자체 실패 시 여전히 전체 다운 【시험 포인트】 고가용성 VPN 구성 = 두 개의 customer gateway + 두 개의 ISP + CloudWatch TunnelState 알람

해설

【핵심 용어】 ▸ AWS WAF IP Set — 동적으로 업데이트 가능한 IP 주소 목록 ▸ Network Firewall Stateless Rule — 즉시 적용되는 필터링 규칙 ▸ Scalability — 대규모 IP 목록 처리 능력 【정답 포인트】 (A) WAF IP Set은 스케일에 최적화됨 → 수천 개 IP 관리 가능 (E) Network Firewall stateless rule도 즉시 패킷 필터링 → 스케일 가능 ▸ 두 솔루션 모두 서버리스와 연동 가능 ▸ 1-2시간 TTL로 자동 차단 해제 구현 ▸ ALB 또는 NACL 수정은 스케일링에 부적합 【오답 체크】 (B) NACL 수정은 보통 느림 → 규칙 개수 제한 (초당 요청 수 제한) → 확장 어려움 (C) Security group 수정도 느림 → 규칙 개수 제한 → 확장 불가 (D) 리디렉션만으로 실제 차단 불가 → 추가 검증 로직 필요 【시험 포인트】 WAF IP Set + Network Firewall Stateless Rule = 스케일 가능한 IP 차단 → 서버리스와 자동화 가능

해설

【핵심 용어】 ▸ Routing — 패킷이 올바른 경로로 이동하는지 확인 ▸ Network ACL — 서브넷 레벨 방화벽 (stateless) ▸ Security Group — 인스턴스 레벨 방화벽 (stateful) ▸ BGP Community Tags — 라우팅 정책 제어 (선택사항) 【정답 포인트】 (A) 양방향 경로 확인 → 온프레미스 → VPC 라우팅 필수 (D) NACL 인/아웃바운드 SSH (포트 22) 허용 확인 → 필수 (E) EC2 security group 인바운드 SSH 허용 확인 → 필수 ▸ BGP 세션이 이미 up인 상태 → 라우팅 기본 설정은 정상 ▸ 실제 SSH 연결 실패 → 경로/필터 문제 【오답 체크】 (B) BGP 커뮤니티 태그는 선택사항 → 기본 connectivity에는 불필요 (C) (B) 와 동일 → 커뮤니티 태그 미지원해도 기본 경로 작동 (F) SSH는 상태추적이므로 아웃바운드 명시적 허용 불필요 → stateful 특성 【시험 포인트】 Direct Connect 연결 문제 해결 = 라우팅 확인 → NACL 확인 → Security Group SSH 인바운드 확인

해설

【핵심 용어】 ▸ MTU 9000바이트 — Jumbo Frames 지원 필수 ▸ Site-to-Site VPN — MTU 최대 1500바이트 (IPSec 오버헤드) ▸ Direct Connect — MTU 1500-9000바이트 지원 ▸ 고가용성 — 이중화 경로 필요 【정답 포인트】 ▸ VPN은 MTU 9000 미지원 → Direct Connect 필수 ▸ 다중 사이트 배포 = 2개 위치에서 2개 연결 = 고가용성 ▸ 비중복 배포 = 1개 위치 다운 시에도 다른 위치 활성 ▸ 비용 효율 = 중복 배포보다 저렴 (4개 연결 vs 2개) 【오답 체크】 (A) VPN MTU 제한 (1500바이트) → 9000바이트 요구사항 미충족 (B) VPN MTU 제한 동일 → 요구사항 미충족 (D) 중복 배포는 비용 2배 → 비용 비효율적 (2개 위치 이중화 불필요) 【시험 포인트】 MTU 9000바이트 = Direct Connect 필수 → 비중복 다중 사이트 = 비용 최소 고가용성

해설

【핵심 용어】 ▸ Endpoint Policy — VPC endpoint 수준의 액세스 제어 ▸ Least Privilege — 최소 권한 원칙 ▸ Centralized Control — 중앙에서 권한 관리 ▸ 최소 운영 오버헤드 — 추가 VPC/Endpoint 불필요 【정답 포인트】 ▸ Endpoint Policy로 account별 접근 제어 → IAM처럼 작동 ▸ 각 endpoint마다 고유 policy → 팀별 권한 분리 ▸ 기존 공유 서비스 VPC 구조 유지 → 아키텍처 영향 최소 ▸ 정책 기반이므로 확장 쉬움 (새 팀 추가 시 정책만 수정) 【오답 체크】 (A) 각 팀마다 별도 VPC 생성 → 비용/관리 오버헤드 증가 (B) Security group은 IP 기반 제어만 가능 → 계정 레벨 통제 불가 (C) 중복된 endpoint 생성 → 비용/관리 복잡도 증가 【시험 포인트】 Endpoint Policy = 계정별 접근 제어 최적화 → 기존 구조 유지 → 최소 오버헤드

해설

【핵심 용어】 ▸ EventBridge — AWS 서비스의 이벤트 기반 아키텍처 ▸ IaC 도구 — Terraform, CloudFormation 등 ▸ Direct Connect Events — 연결 상태 변경 이벤트 제공 ▸ 최소 비용 — 이벤트 기반 모델 (폴링 불필요) 【정답 포인트】 ▸ EventBridge는 Direct Connect 이벤트를 네이티브 지원 ▸ Lambda는 IaC 도구로 쉽게 구성 가능 ▸ 이벤트 발생 시에만 Lambda 실행 → 하루 1회 = 최소 비용 ▸ 최소 지연 시간 (폴링 기반이 아닌 푸시 이벤트) 【오답 체크】 (B) CloudWatch 예약 이벤트는 매분 실행 → 1,440회/일 불필요 실행 → 비용 증가 (C) EC2 인스턴스 폴링 → 서버리스 아키텍처 위배 → 비용 증가 (D) DynamoDB + Streams는 불필요한 중간 계층 → 복잡도 증가, 비용 증가 【시험 포인트】 EventBridge 이벤트 기반 아키텍처 = 이벤트 발생 시에만 처리 = 비용 최소화 + IaC 호환

해설

【핵심 용어】 ▸ Cross-Zone Load Balancing — AZ 간 트래픽 분배 활성/비활성화 ▸ AZ 격리 — ALB 레벨에서 가용 영역별로 독립적으로 트래픽 처리 ▸ 50:50 분할 — 각 AZ가 독립적으로 자신의 대상에 트래픽 분배 【정답 포인트】 ▸ ALB 레벨에서 cross-zone 비활성화 ▸ 각 AZ는 자신의 대상에만 트래픽 전송 (6+4=10개 대상 무시) ▸ AZ1: 4개 대상에 동등 분배 = 각 25% ▸ AZ2: 6개 대상에 동등 분배 = 각 16.67% ▸ 전체 트래픽: AZ1 50%, AZ2 50% ▸ AZ 간 트래픽 불가 【오답 체크】 (A) Target group 레벨 설정 불가 (ALB는 이 옵션 미지원) (C/D) 개별 대상 레벨 설정 불가 → AZ 격리는 ALB 수준 결정 【시험 포인트】 Cross-Zone Load Balancing 비활성화는 ALB 레벨 설정 → 각 AZ 독립 분배 → 50:50 분할 달성