정답 · 해설

해설

【핵심 용어】 ▸ 네임서버(NS) 레코드 — 도메인 권한 위임 ▸ 호스팅 존 — DNS 레코드 관리 영역 ▸ 별도 계정 — 독립적 호스팅 존 운영 【정답 포인트】 ▸ A(하위 호스팅 존 레코드) — test.example.com 호스트 정보 ▸ B(상위 NS 레코드) — example.com 존에서 test.example.com을 2번째 계정 호스팅 존으로 위임 ▸ 결과: example.com 쿼리→상위 NS 지시→test.example.com 쿼리→하위 호스팅 존 【오답 체크】 (C) 반대 방향(하위에 상위 NS) = 순환 참조 (D) 별칭 레코드 = 다른 계정 호스팅 존 미지원 (E) SOA = NS로 충분, 추가 불필요 【시험 포인트】 NS 레코드 위임 = 다중 계정 도메인 관리의 핵심. 상위→하위 방향 위임.

해설

【핵심 용어】 ▸ UDP — 비연결형, 신뢰성 낮음, 속도 우선 ▸ Global Accelerator — 엣지 기반 라우팅, 패킷 손실 감소 ▸ 지역별 배포 — 지연 시간 감소 【정답 포인트】 ▸ A(Global Accelerator) — AWS 엣지→백본→리전(공인 인터넷 우회, 신뢰성↑) ▸ C(지역별 배포+지연 시간) — 남아시아 센서→ap-south-1(가까움) ▸ 조합: 장거리 손실(GA) + 로컬 배포(지연) = 완벽 【오답 체크】 (B) CloudFront = HTTP/HTTPS(UDP 미지원) (D) 페일오버 = 리전 교체(손실 감지 느림) (E) ENA = 드라이버 성능(패킷 손실 근본해결 아님) 【시험 포인트】 UDP 손실 → Global Accelerator + 지역별 배포. 거리 + 신뢰성 동시 해결.

해설

【핵심 용어】 ▸ VPC Traffic Mirroring — 실시간 트래픽 복제 ▸ 콘텐츠 검사 — 패킷 분석 ▸ 미러 필터 — 트래픽 선택 【정답 포인트】 ▸ VPC Traffic Mirroring = 실시간 트래픽 복제(로그 아님) ▸ NLB 미러 대상 = 어플라이언스로 자동 분산 ▸ ENI 소스 = 모든 애플리케이션 트래픽 캡처 ▸ 실제 패킷 → 검사 → 통과/차단 【오답 체크】 (A) VPC Flow Logs = 메타데이터만(실제 패킷 없음), 사후 분석만 (C) Kinesis Firehose = 로그/메시지(실시간 패킷 스트림 아님) (D) Flow Logs + CloudWatch = 역시 메타데이터, 실시간 검사 불가 【시험 포인트】 실시간 콘텐츠 검사 = VPC Traffic Mirroring 필수. Flow Logs는 감시/분석용.

해설

【핵심 용어】 ▸ BGP Community Tag — AWS 라우트 우선순위 제어 ▸ 7224:7100 — 주 링크(높은 우선순위) ▸ 7224:7300 — 보조 링크(낮은 우선순위) ▸ Local Preference — 로컬 라우팅 선택(높을수록 우선) 【정답 포인트】 ▸ us-east-1 = 7224:7300(주) + LP 200(높음) ▸ af-south-1 = 7224:7100(보조) + LP 50(낮음) ▸ 결과: us-east-1 선호, af-south-1은 장애 시만 사용 【오답 체크】 (A) af-south-1이 높은 커뮤니티(주)로 설정 = 역순 (C) LP 값만 역순 = 커뮤니티 태그 기본값 무시 (D) 모든 값이 잘못됨 【시험 포인트】 BGP 커뮤니티 태그 암기: 7100(주), 7300(보조). LP는 높을수록 우선.

해설

【핵심 용어】 ▸ CDK 파이프라인 — 자동화된 다중 계정/리전 배포 ▸ 컨텍스트 메서드 — 환경 변수 동적 로드 ▸ 최소 관리 오버헤드 — 자동화 최대화 【정답 포인트】 ▸ B(환경 변수+컨텍스트) — 런타임 변수 자동 적용 ▸ C(CDK 파이프라인) — 여러 리전/환경 자동 배포 ▸ 조합: 중앙 파이프라인으로 모든 배포 관리 【오답 체크】 (A) CloudFormation 매개변수 = 수동 입력 필요 (D) 스크립트 배포 = 엔지니어가 실행(오버헤드) (E) 로컬 CDK 툴킷 = 수동 배포, 비효율 【시험 포인트】 CDK 자동화 = 파이프라인 (C) + 환경 변수 (B) . 최소 오버헤드 = 중앙 집중식 파이프라인.

해설

【핵심 용어】 ▸ BFD(Bidirectional Forwarding Detection) — 빠른 장애 감지(초 단위) ▸ BGP Holddown Timer — 느린 감지(분 단위) ▸ 양방향 — 온프레미스와 AWS 모두 필요 【정답 포인트】 ▸ BFD = 100ms 단위 빠른 감지 ▸ 온프레미스 라우터에서 구성 = AWS 측 연결 다운 신속 감지 ▸ 양방향 감지로 빠른 BGP 트리거 【오답 체크】 (A) BGP Holddown = 여전히 분 단위(여전히 느림) (B) CloudWatch = 응답 지연(비동기) (C) AWS 측만 = 온프레미스 문제 감지 안 됨 【시험 포인트】 빠른 장애 조치 = BFD(온프레미스 필수). BGP는 느리므로 BFD로 선행 감지.

해설

【핵심 용어】 ▸ Direct Connect Gateway — 다중 VIF 집계 ▸ Transit Gateway — 리전 간 VPC 연결 ▸ TGW Peering — 리전 간 TGW 연결 ▸ Transit VIF — TGW용 VIF(대역폭 확장) 【정답 포인트】 ▸ DX Gateway + 각 리전 TGW 분리 = 리전별 격리 ▸ TGW Peering = 리전 간 장애 조치 ▸ Transit VIF = 대역폭 효율(Private보다 우수) ▸ 각 리전 TGW가 로컬 VPC 관리 【오답 체크】 (A) 프라이빗 VIF + ECMP = 리전 간 피어링 불가 (B) 단일 TGW = 리전 간 장애 조치 불가(TGW는 단일 리전) (D) Private VIF + LAG = Transit VIF의 확장성 부족 【시험 포인트】 다중 리전 + 장애 조치 = TGW Peering 필수. Transit VIF는 리전 간 최적.

해설

【핵심 용어】 ▸ VPC Traffic Mirroring — 실제 패킷 캡처(페이로드 포함) ▸ VPC Flow Logs — 메타데이터만(IP, 포트, 바이트) ▸ 페이로드 8바이트 — 패킷 내용 필요 【정답 포인트】 ▸ Traffic Mirror = 실제 패킷 복제(페이로드 포함) ▸ EC2 소스 = NAT 게이트웨이 통과 전 트래픽 ▸ CloudWatch Logs = 수집, 분석 가능 【오답 체크】 (B) OpenSearch = 구조화된 데이터용(패킷 처리 복잡) (C) (D) Flow Logs = 메타데이터만(페이로드 없음) 【시험 포인트】 페이로드 분석 = Traffic Mirror 필수. Flow Logs는 통계용만.

해설

【핵심 용어】 ▸ VPC Peering — 직접 1:1 VPC 연결(높은 처리량) ▸ Transit Gateway — 다중 VPC 집계(오버헤드) ▸ VPN — 암호화 오버헤드(느림) 【정답 포인트】 ▸ VPC Peering = 레이어 2 직접 연결(낮은 지연, 높은 대역폭) ▸ 3개 VPC = A-B, B-C, A-C 피어링 3개 ▸ 정적 라우팅 = 단순, 안정 【오답 체크】 (A) TGW = 중복화, VPC 피어링보다 지연 높음 (C) VPN = 암호화 오버헤드로 처리량 제한 (D) Site-to-Site VPN = 역시 암호화, 처리량 낮음 【시험 포인트】 최고 처리량 = VPC Peering. TGW는 관리 편이지만 성능은 떨어짐.

해설

【핵심 용어】 ▸ Network Firewall — 중앙화된 검사(송/수신 + 동-서) ▸ HOME_NET — 내부 네트워크(VPC + 온프레미스) ▸ TGW 라우트 테이블 분리 — 트래픽 경로 제어 【정답 포인트】 ▸ B(중앙 검사 VPC) — 아키텍처 변경 최소(기존 VPC 수정 없음) ▸ C(HOME_NET) — 내부 네트워크 정의 ▸ F(분리된 TGW RT) — 애플리케이션→검사 VPC→목적지 라우팅 【오답 체크】 (A) 각 VPC = 수백 개 배포(아키텍처 변경 최대) (D) EXTERNAL_NET = 외부(VPC는 내부) (E) 단일 RT = 트래픽 흐름 제어 불가 【시험 포인트】 최소 변경 = 중앙화 + 검사 VPC 경로 제어. 기존 애플리케이션 VPC는 수정 금지.

해설

【핵심 용어】 ▸ AWS Network Manager — 라우트 분석(경로 검증) ▸ VPC 플로우 로그 — 트래픽 메타데이터(패킷 손실 확인) ▸ 최소 오버헤드 — 효율적 진단 【정답 포인트】 ▸ A(Network Manager 라우트 분석) — EC2→도메인 컨트롤러 경로 자동 검증(빠름) ▸ C(VPC Flow Logs) — 두 VPC 간 패킷 손실/거부 확인 ▸ 조합: 경로 이상 + 트래픽 거부 동시 파악 【오답 체크】 (B) 포트 미러링 = 수동 설정(시간 소요) (D) Ping = ICMP만(도메인 포트 미테스트) (E) 경로 전파 관련 없음(라우트 테이블 이미 수정) 【시험 포인트】 빠른 진단 = Network Manager 라우트 분석 + Flow Logs. 경로 + 트래픽 동시 검증.

해설

【핵심 용어】 ▸ CloudFront 필드 수준 암호화 — POST 데이터 암호화 ▸ 공개 키 — 클라이언트에서 암호화(CloudFront) ▸ us-east-1 ACM — CloudFront 전용 리전 【정답 포인트】 ▸ B(ACM + ALB) — ALB는 us-west-2 ACM에서, CloudFront 인증서는 us-east-1 필수 ▸ E(공개 키 + POST) — 민감한 POST 데이터를 클라이언트 단계에서 암호화 ▸ 프로필 먼저, 구성에 포함 = 순서 중요 【오답 체크】 (A) CloudFront 인증서를 us-west-2에 업로드 = 지역 오류 (C) 프라이빗 키 = 암호화 아님(복호화용, 역할 잘못) (D) GET + 구성 먼저 = 요청 방식 오류(POST만 암호화 필요) 【시험 포인트】 CloudFront ACM = 항상 us-east-1. 필드 암호화 = 공개 키 + POST + 프로필 순서.

해설

【핵심 용어】 ▸ VPC Reachability Analyzer — 단일 VPC 내 리소스 간 연결성 검증 ▸ CloudTrail — 네트워크 구성 변경 감지 및 로깅 ▸ EventBridge — 정책 변경 이벤트 캡처 【정답 포인트】 ▸ 단일 VPC 내 연결 검증 → Reachability Analyzer (Route Analyzer 아님) ▸ 네트워크 정책 변경(보안 그룹, ACL, 라우팅 테이블) → CloudTrail 로깅 ▸ EventBridge 규칙이 CloudTrail 이벤트를 감지 → Lambda로 자동 검증 트리거 【오답 체크】 (A) CloudWatch는 네트워크 정책 변경을 직접 로깅하지 않음. CloudTrail이 필수. (C) (D) Transit Gateway Network Manager Route Analyzer는 다중 VPC/계정 간 경로 검증용. 단일 VPC는 Reachability Analyzer 사용. 【시험 포인트】 단일 VPC 내 연결 검증 → Reachability Analyzer 다중 VPC 또는 Transit Gateway 경로 → Route Analyzer 네트워크 정책 변경 감지 → CloudTrail (CloudWatch 아님)

해설

【핵심 용어】 ▸ AWS WAF 로깅 — CloudFront에서 감지한 공격 기록 ▸ Kinesis Data Firehose — 실시간 데이터 전달 및 S3 저장 ▸ Athena — S3의 WAF 로그 쿼리 분석 【정답 포인트】 ▸ WAF 공격 분석 → WAF 로그 필수 (CloudTrail, VPC Flow Logs 아님) ▸ WAF 로그는 Kinesis Data Firehose로 S3에 전달 ▸ S3 저장된 WAF 로그를 Athena로 SQL 쿼리 분석 가능 【오답 체크】 (A) VPC Flow Logs는 네트워크 흐름만 기록. WAF 공격 탐지 정보 없음. (B) CloudTrail은 API 호출 기록. WAF 탐지 로그 아님. (D) ALB 액세스 로그는 요청/응답만. WAF 공격 탐지 정보 없음. 【시험 포인트】 WAF 탐지 분석 → WAF 로깅 활성화 필수 WAF 로그 저장소 → Kinesis Data Firehose (또는 CloudWatch Logs) Athena 분석 → S3 기반 로그 필수

해설

【핵심 용어】 ▸ Route 53 쿼리 로깅 — DNS 쿼리 기록 (도메인 조회만) ▸ Kinesis Data Firehose — 실시간 데이터 푸시 전달 ▸ 다중 지역 → 비용 최적화 솔루션 필수 【정답 포인트】 ▸ DNS 쿼리 분석 → Route 53 쿼리 로깅 (가장 효율적) ▸ 푸시 방식 필요 → Kinesis Data Firehose 사용 ▸ 다중 지역 환경 → 중앙 수집 지점으로 비용 절감 ▸ Route 53 쿼리 로깅은 자동으로 모든 DNS 요청 기록 【오답 체크】 (A) VPC Flow Logs는 DNS 쿼리 정보 미포함. 불필요한 데이터 수집. (B) CloudWatch 에이전트 설치 필요 (각 인스턴스). 관리 오버헤드 증가. (C) Traffic Mirroring은 전체 트래픽 복사. 비용 높음. DNS만 필요한 경우 낭비. 【시험 포인트】 DNS 쿼리만 분석 → Route 53 쿼리 로깅 최적 다중 VPC/지역 → 중앙화된 로깅 솔루션 (비용 효율) 푸시 vs 폴링 → 실시간 분석 필요 시 Firehose (푸시)

해설

【핵심 용어】 ▸ Cluster Placement Group — 단일 AZ 내 저지연, 고처리량 배치 ▸ EFA (Elastic Fabric Adapter) — HPC용 고속 네트워크 인터페이스 ▸ 10Gbps 흐름, 100Gbps 집계 처리량 — 클러스터 배치 필수 【정답 포인트】 ▸ HPC 워크로드 최적화 → Cluster Placement Group (단일 서브넷) ▸ 저지연, 고처리량 → EFA 드라이버 필수 ▸ 클러스터 배치는 단일 AZ 내 배치 (다중 AZ 지원 안 함) 【오답 체크】 (B) Spread 배치는 인스턴스 분산 배치. HPC 저지연 불가. ENA만으로 100Gbps 미달. (C) 다중 VPC + Transit Gateway = 높은 지연 시간. HPC 부적합. (D) 다중 AZ = 지연 시간 증가. Cluster 배치는 단일 AZ만 지원. 【시험 포인트】 HPC (저지연, 고처리량) → Cluster Placement Group + EFA Cluster Placement Group → 단일 서브넷, 단일 AZ ENA만으로 부족 → EFA 필수 (10Gbps+ 요구) Spread Placement → 장애 분산. HPC 부적합.

해설

【핵심 용어】 ▸ VPC Flow Logs 커스텀 필드 — vpc-id, subnet-id, tcp-flags 등 ▸ S3 저장 → CloudWatch Logs보다 저비용 (장기 보관) ▸ 12개월 보관, 90일 후 가끔 액세스 → S3 저비용 옵션 【정답 포인트】 ▸ 기본 필드는 vpc-id, subnet-id, tcp-flags 미포함 → 커스텀 필드 필수 ▸ 장기 저비용 저장 → S3 (CloudWatch Logs는 비싼 장기 저장소) ▸ S3는 Athena로 쿼리 가능 (로그 분석 용도) ▸ CloudWatch Logs는 실시간 모니터링 용도. 장기 보관 비용 높음. 【오답 체크】 (A) 기본 필드는 vpc-id, subnet-id만 포함. tcp-flags 없음. (B) Traffic Mirroring은 전체 트래픽 복사. 비용 매우 높음. (D) CloudWatch Logs는 장기 보관 비용 높음 (월별 로그 데이터 비용). 【시험 포인트】 장기 저비용 저장 → S3 (특히 90일 후 가끔 액세스) 커스텀 필드 → VPC Flow Logs 커스텀 포맷 CloudWatch Logs → 실시간 모니터링, 단기 저장용 VPC Flow Logs 기본 필드 한계 → 커스텀 필드 구성 필수

해설

【핵심 용어】 ▸ Transit Gateway Peering — 다중 지역 TGW 간 연결 ▸ Direct Connect 최소화 — 기존 연결 재사용 ▸ 정적 경로 — TGW 라우팅 테이블 구성 【정답 포인트】 ▸ eu-west-2의 기존 TGW 활용 → Direct Connect 변경 최소화 ▸ eu-central-1에 새 TGW 생성 → eu-west-2 TGW와 피어링 ▸ 피어링은 Direct Connect 추가 구성 불필요 ▸ 양쪽 TGW 라우팅 테이블에 피어링 경로 추가 【오답 체크】 (A) (D) 가상 프라이빗 게이트웨이는 단일 VPC용. 다중 VPC 연결에 부적합. (C) VPN 사용 시 Direct Connect 변경 필요. 피어링보다 설정 복잡. 【시험 포인트】 Direct Connect 기존 연결 유지 → Transit Gateway Peering 최적 다중 지역 연결 → TGW Peering (VPN 피할 것) VPN vs Peering → Peering이 더 빠르고 간단 (TGW 간)

해설

【핵심 용어】 ▸ BGP 경로 선택 — AS_PATH 길이가 짧을수록 우선 ▸ 기본 경로 — 5Gbps 사용 (정상 시) ▸ 장애 조치 — 5Gbps 실패 시 2Gbps로 전환 【정답 포인트】 ▸ 5Gbps를 우선 사용 → AS_PATH 길이 짧음 ▸ 2Gbps는 백업 → AS_PATH 길이 길게 (더 큰 값) ▸ 2Gbps 라우터에서 아웃바운드 정책으로 더 긴 AS_PATH 광고 ▸ AWS는 더 짧은 AS_PATH 경로 선호 → 5Gbps 선택 ▸ 5Gbps 실패 시 AS_PATH 경로만 가능 → 자동 장애 조치 【오답 체크】 (B) 긴 프리픽스는 목적지별로 다름. AS_PATH 제어 불가. (C) 덜 구체적인 경로는 전역 정책. 세밀한 제어 어려움. (D) 5Gbps에서 긴 AS_PATH 광고 → 우선 경로가 덜 선호됨. 역효과. 【시험 포인트】 BGP 경로 선택 순서: AS_PATH 길이 < Metric 값 2Gbps 백업용 → 더 긴 AS_PATH 광고 5Gbps 우선 → 더 짧은 AS_PATH 자동 iBGP 세션 = 로컬 라우터 간 동기화

해설

【핵심 용어】 ▸ DNSSEC KSK (Key-Signing Key) — 영역 서명 키 서명용 ▸ DNSSEC ZSK (Zone-Signing Key) → KMS 커스텀 키 필요 안 함 ▸ DS (Delegation Signer) — 상위 영역에만 추가 (신뢰 체인) ▸ CloudWatch 경보 — DNSSEC 오류 감지 【정답 포인트】 ▸ (A) KSK 생성 필수 — KMS 기반 (고객 관리 키) ▸ (D) DS 레코드는 상위 영역에 추가 (하위 도메인 아님) ▸ (E) CloudWatch로 DNSSEC 오류 모니터링 ▸ (B) ZSK는 자동 생성됨 (KMS 커스텀 키 불필요) ▸ (C) 하위 도메인에 DS 추가는 잘못된 설정 ▸ (F) CloudTrail은 API 호출 기록. DNSSEC 오류 모니터링 불가 【오답 체크】 (B) ZSK 자동 생성. KMS 설정 불필요. 정책 요구 아님. (C) DS 레코드는 상위 영역에만. 하위 도메인 추가 오류. (F) CloudTrail은 DNSSEC 오류 감지 못함. CloudWatch 사용. 【시험 포인트】 DNSSEC 구현 = KSK (필수) + ZSK (자동) 신뢰 체인 = 상위 영역 DS 레코드만 DNSSEC 모니터링 = CloudWatch (CloudTrail 아님) Route 53 DNSSEC 경고 = CloudWatch 알람