정답 · 해설

해설

【핵심 용어】 ▸ BGP Graceful Shutdown — BGP CEASE(Graceful Shutdown 커뮤니티 포함) 메시지 ▸ BGP 수렴 속도 — Graceful Shutdown 사용 시 빠른 장애 복구 ▸ Hold Timer — BGP Keepalive 인터벌 기본값 180초(장애 감지 지연) 【정답 포인트】 ▸ BGP 수렴 속도 개선 → Graceful Shutdown 커뮤니티 활용(빠른 경로 변경) ▸ Hold Timer 단축 → 장애 감지 시간 감소(기본값 180초 → 예: 10초) ▸ BFD(Bidirectional Forwarding Detection) — 하위 계층에서 초 단위 감지 【오답 체크】 (A) BGP 애드버타이저 증가 — 경로 수 증가만. 수렴 속도 영향 X (B) 메트릭 조정 — 경로 선택만. 장애 감지 속도 개선 X (D) 다이나믹 라우팅 비활성화 — 역효과. BGP가 자동 경로 변경 수행 【시험 포인트】 ▸ BGP 빠른 수렴 → Graceful Shutdown + Hold Timer 단축 + BFD 조합 ▸ 함정: 메트릭 조정은 경로 "선택"만 영향. 장애 "감지"는 독립적

해설

【핵심 용어】 ▸ AWS Transit Gateway — VPC/온프레미스 중앙 라우터(hub-and-spoke) ▸ Transit Gateway Peering — 다른 리전/계정의 TGW와 연결 ▸ 경로 테이블 — TGW 내 라우팅 정책(attachment별 전파 제어) 【정답 포인트】 ▸ 다중 VPC/온프레미스 통합 → Transit Gateway 중앙화(hub-and-spoke) ▸ 리전 간 통신 → Transit Gateway 피어링 ▸ 경로 테이블로 세분화된 라우팅(예: 특정 VPC만 통신 격리) 【오답 체크】 (A) VPC 피어링만 — 메시 구조. 3개 이상 VPC는 관리 복잡(peer × peer 조합) (B) Direct Connect 게이트웨이만 — 온프레미스 연결만. VPC 간 미지원 (D) VPN 연결만 — 낮은 성능, 복잡한 관리(peer × peer 구성) 【시험 포인트】 ▸ 복잡한 네트워크 통합 → Transit Gateway(중앙화, 확장성, 격리) ▸ 함정: VPC 피어링은 소규모 2~3개 VPC. 많은 VPC는 TGW 필수

해설

【핵심 용어】 ▸ Flow Logs — VPC 네트워크 인터페이스(ENI)의 IP 트래픽 로깅 ▸ CloudWatch Logs/S3 — Flow Logs 저장소(CloudWatch는 실시간, S3는 비용 저렴) ▸ VPC Flow Logs vs ALB/NLB 접근 로그 — Flow Logs는 L3-L4, ALB/NLB는 L7 【정답 포인트】 ▸ 네트워크 트래픽 분석 → VPC Flow Logs(실시간 문제 분석) ▸ 비용 최적화 → S3 저장소(장기 보관) ▸ IAM 정책 추적 불가 — CloudTrail 별도 필요 【오답 체크】 (A) CloudTrail 로그만 — API 호출만 기록. 네트워크 트래픽 미지원 (B) ALB/NLB 접근 로그 — 애플리케이션 레이어. 보안 그룹 거부 트래픽 미기록 (D) Route 53 쿼리 로깅만 — DNS만. 모든 IP 트래픽 미기록 【시험 포인트】 ▸ 네트워크 진단 → VPC Flow Logs(L3-L4 투시) ▸ 함정: CloudTrail은 API만. Flow Logs는 "실제 네트워크 트래픽" 기록

해설

【핵심 용어】 ▸ Route 53 Health Check — 엔드포인트 상태 모니터링(HTTP, TCP, 계산된 상태 등) ▸ Failover 라우팅 정책 — 주(Primary) 리소스 장애 시 보조(Secondary)로 자동 전환 ▸ 리전별 라우팅 — 지역 기반 라우팅(레이턴시 고려 X) 【정답 포인트】 ▸ 가용성 보장 → Health Check + Failover 정책(자동 장애 전환) ▸ 글로벌 분산 → 다중 리전 엔드포인트 구성 ▸ DNS 기반 장애 조치(몇 초 수렴) 【오답 체크】 (A) 레이턴시 정책만 — 장애 감지 없음. 장애 시에도 라우팅 지속 (B) 간단한 라우팅 — 고급 기능 없음. 수동 DNS 변경 필요 (D) 가중 정책만 — 트래픽 분산만. 장애 대응 자동화 X 【시험 포인트】 ▸ 글로벌 고가용성 → Health Check + Failover 정책 조합 ▸ 함정: 레이턴시 정책은 성능만 최적화. 장애 자동 대응은 Failover 정책 필수

해설

【핵심 용어】 ▸ NAT Gateway — VPC 내 프라이빗 인스턴스의 아웃바운드 인터넷 접근(탄력적 IP 사용) ▸ NAT 인스턴스 — EC2 기반 NAT(더 이상 권장 안 함) ▸ 인터넷 게이트웨이 — VPC와 인터넷 간 양방향 게이트웨이 【정답 포인트】 ▸ 프라이빗 서브넷 아웃바운드 인터넷 → NAT Gateway(권장, 고가용성) ▸ AZ별 배포 → 각 AZ마다 NAT Gateway 1개(가용성 보장) ▸ 라우트 테이블 → 0.0.0.0/0 → NAT Gateway로 경로 설정 【오답 체크】 (A) NAT 인스턴스 — 자동 관리 X, 병목 가능성, 더 이상 권장 안 함 (B) 인터넷 게이트웨이만 — 프라이빗 인스턴스 공인 IP 필요(암묵적 라우팅 X) (D) VPC 엔드포인트 — S3/DynamoDB 등 특정 AWS 서비스만. 일반 인터넷 미지원 【시험 포인트】 ▸ 프라이빗 서브넷 인터넷 접근 → NAT Gateway(AZ별 배포) ▸ 함정: NAT 인스턴스는 구형 기술. NAT Gateway가 권장 표준

해설

【핵심 용어】 ▸ AWS Firewall Manager — Organizations 단위 WAF/Shield 중앙 정책 관리 ▸ AWS WAF — 웹 애플리케이션 방화벽(Layer 7, SQL Injection/XSS 차단) ▸ AWS Shield — DDoS 보호(기본 표준, 고급 옵션) 【정답 포인트】 ▸ 중앙화된 보안 정책 → Firewall Manager(여러 계정 + 리전) ▸ WAF 규칙 템플릿 → 조직 내 모든 ALB/CloudFront에 자동 배포 ▸ 규정 준수 감시 → AWS Config와 통합 【오답 체크】 (A) AWS WAF만 — 각 ALB마다 수동 설정. 중앙화 부재 (B) AWS Shield Advanced만 — DDoS만. WAF(웹 공격) 미지원 (D) GuardDuty만 — 위협 탐지만. 사전 차단(WAF) 기능 없음 【시험 포인트】 ▸ 조직 단위 보안 정책 중앙화 → Firewall Manager(WAF + Shield 통합) ▸ 함정: WAF 단독 설정은 수동 반복. Firewall Manager가 "중앙"화 키포인트

해설

【핵심 용어】 ▸ AWS AppSync — GraphQL API 관리 서비스(실시간 데이터 동기화) ▸ API Gateway — REST/WebSocket API(일반 웹 API) ▸ Cognito — 사용자 인증/권한 관리 【정답 포인트】 ▸ 실시간 협업 앱 → AppSync(GraphQL의 구독/mutation) ▸ 모바일/웹 클라이언트 — Cognito 사용자 풀로 인증 ▸ 데이터 변경 구독 → 실시간 업데이트(WebSocket 활용) 【오답 체크】 (A) API Gateway REST — 단방향 HTTP 요청/응답만. 서버 푸시(실시간) 미지원 (B) Lambda 폴링 — 클라이언트가 반복 호출. 네트워크 비효율 (D) SNS 브로드캐스트 — 메시지 전송만. 클라이언트 구독 메커니즘 약함 【시험 포인트】 ▸ 실시간 협업 앱 → AppSync(GraphQL) + WebSocket 구독 ▸ 함정: REST API는 단방향. 서버 푸시 필요하면 WebSocket/AppSync 필수

해설

【핵심 용어】 ▸ Amazon ElastiCache — Redis/Memcached 관리형 인메모리 캐시 ▸ CloudFront 캐시 — CDN 엣지 캐시(HTTP/HTTPS 콘텐츠) ▸ RDS Read Replica — 읽기 전용 DB 복제본(쓰기 부하 분산 X) 【정답 포인트】 ▸ 빈번한 읽기 쿼리 → ElastiCache(인메모리, 빠른 응답) ▸ 세션 저장소 → Redis/Memcached(TTL 지원) ▸ DB 쿼리 부하 감소 → 캐시 히트 시 RDS 미접근 【오답 체크】 (A) CloudFront만 — 정적 콘텐츠 전용. 동적 데이터 캐싱 약함(TTL 길어짐) (B) RDS Read Replica — 읽기 스케일링은 가능하나, 캐싱 아님. 쿼리 응답 시간 개선 X (D) S3만 — 정적 파일 저장소. 세션/동적 쿼리 캐싱 부적합 【시험 포인트】 ▸ 빈번한 데이터 읽기 → ElastiCache 인메모리 캐시(밀리초 응답) ▸ 함정: RDS Read Replica는 "복제"이지 "캐싱" 아님. 응답 속도는 크게 향상 X

해설

【핵심 용어】 ▸ AWS Glue — ETL(추출, 변환, 로드) 서비스, 메타데이터 카탈로그 ▸ Data Pipeline — 데이터 소스 → 변환 → 저장(S3/DW 등) ▸ Lake Formation — 데이터 레이크 중앙 관리(접근 제어, 메타데이터) 【정답 포인트】 ▸ 대규모 데이터 통합 → AWS Glue(자동 스키마 감지, ETL 작업) ▸ 데이터 카탈로그 → Glue 메타스토어(쿼리 가능한 데이터 구조 정의) ▸ 데이터 레이크 구성 → Lake Formation(권한 관리, 규정 준수) 【오답 체크】 (A) Kinesis 스트리밍 — 실시간 데이터만. 배치 처리 불가 (B) Lambda 함수 — 소규모 변환만. 대규모 ETL 비효율(시간 제한 15분) (D) Athena만 — 쿼리 엔진만. 데이터 변환/정제 기능 약함 【시험 포인트】 ▸ 대규모 데이터 통합 및 카탈로깅 → AWS Glue + Lake Formation ▸ 함정: Kinesis는 "스트리밍". Glue는 "배치 ETL". 사용 사례 구분 필수

해설

【핵심 용어】 ▸ AWS WAF — 웹 애플리케이션 방화벽으로 SQL 인젝션, XSS 등 공격 차단 ▸ NLB vs ALB — NLB는 Layer 4 로드밸런서로 WAF 미지원, ALB는 Layer 7으로 WAF 지원 【정답 포인트】 ▸ A(WAF 웹 ACL 생성) — SQL 인젝션 규칙 포함하여 악의적 요청 차단 ▸ C(NLB → ALB 변경) — WAF를 연결하려면 ALB 필요 (NLB는 WAF 비지원) ▸ E(ALB와 WAF 연결) — ALB가 WAF 지원하므로 ACL 연결 가능 【오답 체크】 ▸ (B) CloudFront는 이미 온프레미스에서 VPN 사용 중이므로 필요 없음 ▸ (D) NLB는 WAF를 지원하지 않음 (Layer 4 로드밸런서) ▸ (F) CloudFront는 이 요구사항에 부적절 【시험 포인트】 AWS WAF 구현은 ALB/CloudFront/API Gateway와만 연결 가능. NLB는 지원하지 않으므로 ALB로 교체 필요. SQL 인젝션 방어는 AWS Managed Rules의 AWSManagedRulesSQLiRuleSet 사용.

해설

【핵심 용어】 ▸ Direct Connect Gateway — 여러 VGW/TGW를 단일 DX 연결에 연결 ▸ Transit VIF — Transit Gateway와 Direct Connect를 직접 연결하는 새로운 VIF 타입 ▸ Private VIF — VGW 연결용 (이제 transit VIF로 대체) 【정답 포인트】 ▸ Transit VIF + Direct Connect Gateway + Transit Gateway 조합만이 대규모 확장 지원 ▸ Transit Gateway 간 피어링과 온프레미스 연결을 모두 처리 가능 ▸ 50개 계정, 수천 VPC 규모에서 VGW 방식은 확장성 부족 【오답 체크】 ▸ (A) (B) Private VIF는 VGW 기반으로 50개 계정 규모에 미흡 ▸ (D) Site-to-Site VPN은 대역폭 제한 (2.5Gbps) 및 운영 복잡도 높음 【시험 포인트】 Direct Connect Gateway는 Transit Gateway attach를 지원. Transit VIF는 AWS의 최신 권장 아키텍처로 TGW ↔ On-Prem 직접 연결 가능.

해설

【핵심 용어】 ▸ Local Preference — BGP 경로 선택 메커니즘 (높을수록 우선) ▸ BGP Community — 정책 기반 라우팅 제어 ▸ AS_PATH Prepend — 경로 길이로 우선순위 조정 【정답 포인트】 ▸ 양방향 트래픽 제어 필요 (On-Prem → AWS, AWS → On-Prem) ▸ 로컬 선호도를 1차 경로 선택(첫 데이터센터 높음), 2차 경로 선택에도 적용 ▸ 양 방향에서 일관된 정책(BGP Community + Local Preference) 【오답 체크】 ▸ (A) AS_PATH Prepend는 단방향만 제어, 양방향 미흡 ▸ (C) Direct Connect Gateway는 선호도 설정 불가, 양방향 제어 불가 ▸ (D) Focal Region Community는 특정 지역만 적용, 양방향 미흡 【시험 포인트】 양방향 트래픽 흐름 제어는 BGP Community (로컬 선호도) 조합. Direct Connect Gateway는 경로 정책 미지원으로 라우터 측 Local Preference 설정 필수.

해설

【핵심 용어】 ▸ NAT Gateway — 프라이빗 서브넷 아웃바운드 인터넷 트래픽 처리 (비용 발생) ▸ VPC Flow Logs — 네트워크 트래픽 상세 분석 ▸ VPC Endpoint — AWS 서비스 비용 절감 (NAT 우회) 【정답 포인트】 ▸ B(Flow Logs 분석) — NAT 게이트웨이 비용 원인 파악 (어떤 트래픽인지 식별) ▸ E(VPC Endpoint 확인) — S3/DynamoDB는 엔드포인트로 나감 (NAT 우회) → 비용 절감 ▸ 라이선스 호스트명만 NAT 통과, 나머지 AWS 서비스는 엔드포인트 활용 【오답 체크】 ▸ (A) Traffic Mirroring은 비용 원인 진단이 아닌 모니터링만 함 ▸ (C) Cost and Usage Report는 이미 비용 유형 파악했으므로 추가 정보 없음 ▸ (D) 보안 그룹 검증만으로는 문제 해결 불가 【시험 포인트】 NAT Gateway 비용 최적화는 2단계: (1) Flow Logs로 원인 분석 (2) VPC Endpoint로 불필요한 NAT 통과 제거. 특히 AWS 서비스(S3, DynamoDB)는 반드시 엔드포인트 사용.

해설

【핵심 용어】 ▸ VPC CIDR — 변경 불가능 (생성 후 확장만 가능) ▸ Subnet CIDR — 감소는 가능하지만 확장은 새 서브넷 생성 ▸ CloudFormation Stack Update — 기존 리소스 수정 시 다운타임 유발 【정답 포인트】 ▸ 기존 10.10.1.0/24 서브넷을 10.10.1.0/22로 직접 변경 불가 (기존 리소스 중단 위험) ▸ 새로운 서브넷 10.10.2.0/24 추가 = 운영 오버헤드 최소화 ▸ VPC 10.10.0.0/16은 변경 불가 (VPC CIDR 블록은 변경 금지) 【오답 체크】 ▸ (A) 기존 서브넷 CIDR 변경 시 인스턴스 중단 발생 ▸ (B) VPC CIDR는 변경 불가 (AWS 정책) ▸ (C) 스택 복사는 새 환경 생성이므로 오버헤드 매우 높음 【시험 포인트】 VPC 확장 시나리오: 기존 리소스 중단 최소화 = 새 서브넷 추가. CloudFormation에서 새 Subnet 리소스 추가는 무중단 변경.

해설

【핵심 용어】 ▸ Amazon-provided IPv6 CIDR — /56 (AWS 자동 할당, 변경 불가) ▸ Egress-only Internet Gateway — IPv6 아웃바운드 트래픽 (NAT 불필요) ▸ AWS RAM — VPC 또는 서브넷 공유 (조직 간) 【정답 포인트】 ▸ B(Amazon IPv6) — 사용자 지정 IPv6보다 AWS 관리형 IPv6 권장 ▸ C(Subnet 공유) — VPC 공유 아니라 서브넷만 공유 (각 팀 독립 VPC/라우팅 가능) ▸ E(IGW + Egress-only + NAT) — 이중 스택: IPv4(IGW+NAT), IPv6(Egress-only) 【오답 체크】 ▸ (A) 사용자 지정 IPv6 2001:db8:c5a:6000::/56은 라우팅 불가 (예약 주소) ▸ (D) VPC 공유는 라우팅 복잡성 증가, 각 팀의 독립성 감소 ▸ (F) NAT Instance는 NAT Gateway보다 운영 복잡도 높음 【시험 포인트】 이중 스택 (IPv4+IPv6) 설계: Amazon-provided IPv6 + Egress-only IGW 조합. 멀티계정 환경에서는 VPC 아닌 서브넷 공유로 보안 격리 유지.

해설

【핵심 용어】 ▸ Gateway Load Balancer (GWLB) — L3/L4 검사 트래픽 처리 (포트 6081) ▸ GWLB VPC Endpoint — 방화벽 검사 경로 추가 ▸ Edge Association — IGW와 라우팅 경로 제어 【정답 포인트】 ▸ A(별도 VPC) — 방화벽 어플라이언스는 분리된 VPC에 배포 (보안) ▸ C(포트 6081) — GWLB는 포트 6081(GENEVE) + 상태 검사 포트 ▸ F(Edge Association) — 인터넷 트래픽 경로: IGW → GWLB VPC Endpoint → 방화벽 → GWLB Endpoint 【오답 체크】 ▸ (B) 포트 443은 HTTPS, GWLB는 포트 6081 사용 ▸ (D) 방화벽을 같은 VPC에 배포하면 트래픽 루핑 위험 ▸ (E) Edge Association 미지원 (라우팅 불완전) 【시험 포인트】 GWLB 검사 경로: IGW (외부) → Edge Association 경로 테이블 → GWLB VPC Endpoint → 방화벽 → GWLB Endpoint → 웹 서버. 방화벽 VPC는 분리 필수.

해설

【핵심 용어】 ▸ VPC Traffic Mirroring — L3/L4 트래픽 복제 (원본 트래픽 영향 없음) ▸ Traffic Mirror Source — EC2 인스턴스 (모니터링 대상) ▸ Traffic Mirror Target — NLB (수신 대상) 【정답 포인트】 ▸ B(EC2 인스턴스 처리 능력) — 미러링은 추가 CPU/메모리 사용 → 인스턴스 과부하 시 일부 미러링 손실 ▸ D(우선순위 조정) — 미러링 트래픽은 원본 트래픽보다 낮은 우선순위 → 혼잡 시 드롭 ▸ 무작위 손실 = 혼잡/리소스 한계 상황에서의 드롭 【오답 체크】 ▸ (A) 보안 그룹은 미러링 세션에 영향 없음 (미러링 트래픽은 네트워크 계층) ▸ (C) IAM은 세션 생성 단계에만 영향 (생성 후 운영에 영향 없음) ▸ (E) NLB 워밍업은 처음부터 일관된 패턴, 무작위 아님 【시험 포인트】 Traffic Mirroring 손실은 2가지 원인: (1) 소스 인스턴스 리소스 부족 (2) 미러 트래픽 우선순위 낮음 (네트워크 정체 시 드롭). 해결: EC2 인스턴스 타입 업그레이드 또는 높은 처리량 NLB.

해설

【핵심 용어】 ▸ PrivateLink — VPC 간/서비스 간 프라이빗 연결 (IP 겹침 무시) ▸ Interface Endpoint — PrivateLink 끝점 ▸ IP Address Overlap — NAT로는 해결 불가 (양방향 통신 복잡) 【정답 포인트】 ▸ IP 겹침 환경에서 PrivateLink는 IP 주소 무관 (DNS 기반) ▸ Interface Endpoint의 DNS 이름으로 통신 (프라이빗, 보안) ▸ VPC 피어링/VPN은 겹치는 IP 때문에 불가능 【오답 체크】 ▸ (A) (B) (D) NAT 사용도 양방향 매핑 복잡, IP 겹침 완전 해결 불가 ▸ (A) VPC 피어링은 IP 겹침 불허 ▸ (B) (D) NAT + Transit Gateway는 관리 오버헤드 높음 【시험 포인트】 PrivateLink는 IP 겹침 문제의 유일한 솔루션. DNS 이름 기반 통신으로 IP 주소와 무관하게 작동. Marketplace 파트너 서비스는 항상 PrivateLink 활용.

해설

【핵심 용어】 ▸ AWS Cloud WAN — 멀티리전 네트워크 중앙 관리 (Transit Gateway 대체) ▸ Core Network Policy — 세그먼트별 트래픽 제어 ▸ Segment Isolation — 세그먼트 간 트래픽 차단 【정답 포인트】 ▸ Cloud WAN 세그먼트 = BU별 논리적 격리 ▸ 각 BU는 자체 세그먼트에 VPC 연결 → BU 내부만 통신 ▸ 새 BU 추가 시 새 세그먼트 추가만으로 자동 격리 【오답 체크】 ▸ (A) 세그먼트 작업으로 경로 거부는 복잡, 자동화 부족 ▸ (B) Transit Gateway는 모든 리전 피어링 필요 → 확장 복잡도 높음 ▸ (C) isolate-attachments는 모든 세그먼트 간 차단 → BU 내 통신도 불가 【시험 포인트】 Cloud WAN은 세그먼트 기반 아키텍처로 새 BU 확장 시 자동 격리 제공. Transit Gateway는 피어링 수동 관리 필요. 운영 효율성 측면에서 Cloud WAN이 우수.

해설

【핵심 용어】 ▸ VPN Acceleration — AWS Global Accelerator로 VPN 트래픽 가속 (2.5Gbps 달성) ▸ ECMP — 동일 비용 경로로 로드밸런싱 (다중 흐름 필요) ▸ BGP AS_PATH — 경로 선택 (동일 = ECMP, 다름 = 선호도) 【정답 포인트】 ▸ B(가속화 VPN) — VPN 기본 속도는 1.25Gbps, 가속화로 2.5Gbps 달성 ▸ C(동일 AS_PATH) — ECMP 활성화로 다중 VPN 연결 로드밸런싱 ▸ F(다중 흐름) — ECMP는 흐름 기반 해시, 여러 흐름 필요 【오답 체크】 ▸ (A) 기존 VPN 가속화는 신규 생성 불가 ▸ (D) 다른 AS_PATH는 ECMP 불활성화 (1개 경로만 사용) ▸ (E) AZ 확인은 대역폭과 무관 【시험 포인트】 VPN 대역폭 향상 = 가속화 + ECMP + 다중 흐름 조합. 기본 VPN(1.25Gbps) < 가속화 VPN(2.5Gbps). ECMP는 AS_PATH 동일 + 동일 메트릭 필요.