정답 · 해설

해설

【핵심 용어】 ▸ AWS WAF — 웹 애플리케이션 방화벽 (L7 필터링) ▸ NLB — Layer 4 로드 밸런싱 (TCP/UDP) ▸ ALB — Layer 7 로드 밸런싱 (HTTP/HTTPS) ▸ WAF 지원 — ALB/CloudFront/API Gateway/AppSync만 지원 【정답 포인트】 ▸ AWS WAF는 NLB와 직접 연동 불가 ▸ ALB는 WAF 네이티브 지원 ▸ ALB는 HTTP/HTTPS 기반 (회사 웹사이트 TLS 리스너) ▸ ALB로 교체 = WAF 통합 가능 【오답 체크】 (A) Elastic IP는 WAF와 무관 → Elastic IP 자체는 보안 필터링 불가 (C) NLB는 WAF 미지원 → AWS 공식 문서에서 미지원 서비스 (D) EC2 직접 연결 불가 → WAF는 로드 밸런서/CloudFront만 대응 【시험 포인트】 AWS WAF는 ALB/CloudFront/API Gateway만 지원 → NLB는 미지원 → ALB로 변경 필요

해설

【핵심 용어】 ▸ DS Record — 부모 도메인에 저장되는 위임 서명자 ▸ KSK — Key Signing Key (DNSSEC 검증에 필수) ▸ RRSIG — Resource Record Signature (각 레코드의 서명) ▸ TTL — 캐시 만료 시간 (DNS 일관성 유지) 【정답 포인트】 ▸ DS 레코드 삭제가 첫 단계 (부모에서의 신뢰 체인 끊기) ▸ DS TTL 경과 → 캐시된 DS 정보 만료 ▸ DNSSEC 서명 비활성화 → 새로운 서명 생성 중단 ▸ KSK 비활성화 → 기존 서명 검증 불가 ▸ 순서 중요 = DNS 중단 방지 【오답 체크】 (A) KSK 비활성화 전에 DNSSEC 비활성화 → 중간 상태에서 검증 실패 가능 (B) DS 레코드 삭제 없음 → 부모 도메인의 영역이 여전히 검증 시도 → SERVFAIL (D) DS 레코드 삭제 후 TTL 대기하기 전에 KSK 비활성화 → 캐시 일관성 문제 【시험 포인트】 DNSSEC 비활성화 순서: DS 레코드 삭제 → TTL 대기 → DNSSEC 비활성화 → KSK 비활성화 (중단 방지)

해설

【핵심 용어】 ▸ VPC Endpoint — Lambda가 VPC 내 리소스에 접근하기 위한 설정 ▸ vpc_config — Lambda 함수의 VPC 연결 설정 (security group + subnet) ▸ Private Subnet ALB — VPC 내부 리소스이므로 Lambda도 VPC 내에서 접근 필수 【정답 포인트】 ▸ Lambda 기본 = VPC 외부 배포 (인터넷 접근만 가능) ▸ 프라이빗 ALB 접근 = VPC 내부 네트워크 필요 ▸ vpc_config 추가 = Lambda를 VPC 서브넷에 배포 ▸ Security group ID = VPC 네트워크 인터페이스 필요 ▸ Private Subnet ID = ALB와 같은 VPC 내 배포 【오답 체크】 (A) PrivateLink는 서비스 공개용 → 회사 내부 ALB는 불필요 (B) Lambda는 target group 대상 될 수 없음 (ALB 타겟은 EC2/IP/Lambda만 가능하지만 이 경우는 역방향) (C) Security group만으로 충분 안 함 → vpc_config의 subnet이 필요 【시험 포인트】 Lambda에서 VPC 프라이빗 리소스 접근 = vpc_config 필수 (security group + private subnet)

해설

【핵심 용어】 ▸ Route 53 Resolver Outbound Endpoint — VPC 내부 DNS 쿼리를 온프레미스로 포워딩 ▸ Inbound Endpoint — 온프레미스에서 VPC 리소스의 DNS 쿼리 허용 ▸ Dual-Stack — IPv4/IPv6 모두 지원 ▸ Centralized DNS — 공유 서비스 VPC에서 중앙 관리 【정답 포인트】 ▸ 애플리케이션 VPC → 온프레미스 DNS 리졸버 = 아웃바운드 흐름 ▸ Outbound endpoint가 필요 (인바운드 X) ▸ Dual-stack 서브넷 = IPv4/IPv6 쿼리 모두 지원 ▸ 공유 서비스 VPC 중앙화 = 관리 단순화 ▸ RAM으로 리졸버 규칙 공유 = 각 계정에서 사용 가능 【오답 체크】 (B) 인바운드 엔드포인트 = 온프레미스 → VPC 쿼리 (반대 방향) (C) 각 VPC마다 배포 = 중앙화 미달성, 오버헤드 증가 (D) IPv4만 = IPv6 지원 못함, 인바운드 = 방향 틀림 【시험 포인트】 VPC → 온프레미스 DNS 쿼리 = Outbound Endpoint (공유 VPC) + Dual-Stack + RAM 공유

해설

【핵심 용어】 ▸ Network Manager — AWS 네트워크 리소스 중앙 관리 (Transit Gateway 모니터링) ▸ EventBridge — AWS 서비스 이벤트 기반 트리거 ▸ Lambda — 크로스 계정 IAM 역할 가정 (STS AssumeRole) ▸ Auto-tagging — 자동 태그 적용 【정답 포인트】 ▸ Network Manager = Transit Gateway 첨부 파일 이벤트 감지 전문 ▸ EventBridge 규칙 = 이벤트 기반 트리거 (새 첨부 파일) ▸ Lambda = 서버리스, 크로스 계정 역할 가정 가능 ▸ IAM 역할 가정 = 요청자 계정의 VPC 태그 읽기 권한 ▸ 확장 가능 = 새로운 첨부 파일 자동 감지 【오답 체크】 (A) Access Analyzer는 정책 분석용 → 이벤트 기반 모니터링 부적합 (B) SCP는 정책 제어용 → 이벤트 트리거 기능 없음 (C) IPAM은 IP 주소 관리용 → Transit Gateway 첨부 파일 이벤트 미지원 【시험 포인트】 Network Manager + EventBridge + Lambda = Transit Gateway 첨부 파일 자동 태그 지정

해설

【핵심 용어】 ▸ ALB Listener — 포트와 프로토콜 기반 수신 대기 ▸ Host Header Rule — 호스트명 기반 라우팅 규칙 ▸ Target Group — 실제 백엔드 인스턴스 그룹 【정답 포인트】 ALB 리소스 할당의 핵심은 공유 vs 애플리케이션별 구분입니다. ▸ A (공통 스택의 리스너) — 모든 애플리케이션이 공유하는 HTTPS 포트 수신. 한 번만 설정하면 여러 애플리케이션에서 재사용 가능 ▸ D (애플리케이션별 호스트 헤더 규칙) — 각 애플리케이션의 DNS 이름별로 다른 대상 그룹으로 라우팅. 애플리케이션별 스택에서 관리 ▸ F (애플리케이션별 대상 그룹) — 각 애플리케이션의 Fargate 작업 그룹. 애플리케이션별로 독립적으로 관리되어야 함 【오답 체크】 (B) 리스너를 애플리케이션별로 만들면 같은 포트에서 중복 발생 (C) 호스트 헤더 규칙을 공통 스택에 고정하면 새 애플리케이션 추가 시 공통 스택을 매번 수정해야 함 (E) 대상 그룹을 공통 스택에 두면 애플리케이션별 독립성 상실 【시험 포인트】 AWS CDK에서 공유 인프라(VPC, ALB)는 공통 스택, 애플리케이션별 가변 부분(라우팅 규칙, 대상 그룹)은 애플리케이션별 스택으로 분리하는 패턴. 확장성과 재사용성을 동시에 달성합니다.

해설

【핵심 용어】 ▸ Transit Gateway — 여러 VPC와 온프레미스를 중앙에서 연결하는 라우터 ▸ AWS RAM — 조직 간 리소스 공유 메커니즘 ▸ Direct Connect Gateway — Direct Connect와 VPC 간 연결 ▸ Dynamic Routing — BGP를 통한 자동 경로 학습 【정답 포인트】 100개 이상의 VPC 추가 확장성을 고려할 때 Transit Gateway가 최적입니다. ▸ 새 네트워킹 계정에 중앙 Transit Gateway 배치 — 모든 애플리케이션 계정이 공유 ▸ AWS RAM으로 조직 ID 기반 공유 — 계정 추가 시 자동 액세스, 수동 설정 불필요 ▸ 프라이빗 IP VPN으로 온프레미스 연결 — Direct Connect 게이트웨이 없이도 가능 ▸ 동적 라우팅(BGP) — 새 VPC 추가 시 라우팅 자동 업데이트 【오답 체크】 (A) VPC당 하드웨어 VPN 필요 — 100개 VPC는 관리 불가 (B) EC2 기반 VPN — 고가용성, 확장성 한계, 운영 부담 높음 (D) Direct Connect 게이트웨이 + 퍼블릭 VIF — 확장성 부족, VIF 수 제한 【시험 포인트】 대규모 멀티 VPC 환경에서는 Transit Gateway + AWS RAM 조합이 표준. 계정 수가 증가해도 중앙 관리로 단순화되는 패턴을 이해하는 것이 중요합니다.

해설

【핵심 용어】 ▸ Route 53 DNS Firewall — DNS 레벨에서 도메인 기반 필터링 ▸ Allowlist (화이트리스트) — 허용할 도메인만 지정하는 보안 모델 ▸ Outbound Protection — 아웃바운드 악성 연결 차단 【정답 포인트】 EC2의 손상된 애플리케이션이 악의적 웹사이트로 DNS 쿼리하는 것을 막아야 합니다. ▸ DNS Firewall은 DNS 쿼리 단계에서 차단 — 악의적 도메인 해석 자체를 막음 ▸ 애플리케이션이 필요한 도메인만 허용 목록으로 지정 — 제로 트러스트 접근 ▸ VPC 전체에 적용 — 어떤 EC2든 보호, 애플리케이션 수정 불필요 ▸ 운영 오버헤드 최소 — 일단 설정 후 자동으로 작동, 수동 관리 없음 【오답 체크】 (A) EC2 기반 방화벽 — 고가용성, HA 구성 필요, 운영 복잡 (B) (C) WAF는 HTTP/S 레이어 — DNS는 차단 불가, ALB도 도움 안 됨 WAF는 요청 기반이므로 DNS 쿼리 단계에서 차단 불가능 【시험 포인트】 손상된 애플리케이션의 악성 통신 차단은 DNS Firewall이 가장 효율적. "allowlist 도메인만 허용" 모델이 운영 부담을 최소화하면서 보안을 극대화합니다.

해설

【핵심 용어】 ▸ Route 53 Resolver Rule — DNS 쿼리를 아웃바운드 엔드포인트로 포워딩하는 규칙 ▸ AWS RAM — AWS Organizations 조직 간 리소스 공유 ▸ Hybrid DNS Resolution — 온프레미스와 AWS 간 DNS 통합 【정답 포인트】 Resolver 규칙을 AWS RAM으로 공유하는 것이 가장 비용 효율적입니다. ▸ 기존 계정에 아웃바운드 엔드포인트가 이미 있음 — 재사용하면 비용 절감 ▸ Resolver 규칙만 공유 — 규칙에 이미 아웃바운드 엔드포인트 참조 포함 ▸ 새 계정 VPC에서 규칙 연결 — 온프레미스 접근 가능 ▸ Transit Gateway 이미 연결됨 — 추가 네트워킹 설정 불필요 【오답 체크】 (A) 새 VIF + 아웃바운드 엔드포인트 생성 — VIF와 엔드포인트 중복 비용 (C) 아웃바운드 엔드포인트 공유 + 새 규칙 — 엔드포인트는 공유 가능하지만, 규칙 공유가 더 효율적 (D) 별도 VPN 생성 — Transit Gateway 이미 있는데 중복, 비용 증가 【시험 포인트】 Resolver 규칙 공유는 규칙 자체만 복제 (경량), 엔드포인트를 계정별로 만드는 것보다 훨씬 효율적. AWS Organizations 내에서 공유된 규칙은 기존 엔드포인트를 참조하므로 추가 비용 없음.

해설

【핵심 용어】 ▸ CIDR Overlap — IP 주소 범위 충돌 ▸ Private NAT Gateway — VPC 내부에서 아웃바운드 IP 변환 ▸ Transit Gateway Route Table — 라우팅 광고 제어 【정답 포인트】 VPC-Z의 CIDR을 변경하는 방식(A + C 조합)이 해결책입니다. ▸ A) VPC-Z에 겹치지 않는 CIDR 추가 — 새 IP 범위로 리소스 배치 가능 ▸ C) 프라이빗 NAT Gateway로 트래픽 변환 — 새 CIDR 블록으로 출발 ▸ Transit Gateway에 새 CIDR만 광고 — VPC-A는 겹치지 않는 IP에서 오는 트래픽만 봄 ▸ VPC-Z → VPC-A 통신 가능, VPC-A → VPC-Z도 응답 가능 【오답 체크】 (B) VPC-A 수정 — A와 Z의 겹침 해결 안 됨, 다른 VPC들도 A와 연결되어 있어 복잡 (D) VPC-A에서만 NAT — VPC-Z의 원본 IP로 트래픽 시작, 겹침 문제 지속 (E) VPC Peering — Transit Gateway 기존 구조와 맞지 않음, 모든 VPC 통신 불가 【시험 포인트】 IPv4 겹침은 한쪽 VPC를 "새 주소로 이전"하고, NAT로 변환하는 방식이 표준. 새 CIDR 추가 후 프라이빗 NAT로 광고되는 출발지를 제어하는 패턴.

해설

【핵심 용어】 ▸ Direct Connect Gateway — 온프레미스와 AWS 간 중앙 연결점 ▸ Hosted VIF — 파트너가 호스팅할 수 있는 가상 인터페이스 ▸ VIF Isolation — 격리된 네트워크 경로 ▸ SiteLink — 온프레미스 간 직접 통신 (AWS 우회) 【정답 포인트】 파트너와의 격리된 네트워크를 위해 별도 Direct Connect 게이트웨이가 필수입니다. ▸ A) 새 DX 게이트웨이 + 호스팅된 VIF — 파트너는 자신의 AWS 계정이 없을 가능성, 회사 계정의 호스팅 VIF로 연결 — Data Center 2와 파트너 DC 간 분리된 경로 ▸ D) 프라이빗 VIF + SiteLink — 프라이빗 VIF는 데이터 센터 간 직접 연결 (AWS 우회) — SiteLink 활성화로 Data Center 2 ↔ 파트너 DC 직통 가능 — 기존 회사 네트워크와 격리 【오답 체크】 (B) Transit VIF — 온프레미스 간 통신용 아님, AWS 간 연결 (C) 기존 DX 게이트웨이 — 회사의 다른 데이터 센터와 통신 경로 노출, 격리 안 됨 (E) 퍼블릭 VIF — 인터넷 기반, Direct Connect SiteLink와 맞지 않음 【시험 포인트】 온프레미스 간 격리는 "별도 DX 게이트웨이" 또는 "프라이빗 VIF + SiteLink"로 달성. 파트너 격리를 위해서는 회사 네트워크와 완전히 독립된 경로 필요.

해설

【핵심 용어】 ▸ ACM 퍼블릭 인증서 — 공개 도메인용 무료 SSL/TLS, ALB에 직접 연결해 TLS 종료 ▸ ALB + ACM 통합 — ALB 리스너에 퍼블릭 인증서 배포, EC2는 별도 인증서 불필요 ▸ Route 53 alias → ALB — A(alias) 레코드로 도메인을 ALB에 매핑 【정답 포인트】 ▸ "ACM 인증서로 공개 웹 앱 보호 + ALB + Route 53" → (A) ACM 퍼블릭 인증서 요청, ALB에 적용, Route 53 A 레코드를 ALB alias로 지정 【오답 체크】 (B) 프라이빗 인증서는 공개 웹사이트에 부적합(내부 PKI용), alias 대신 도메인명 지정도 어색. (C) 프라이빗 인증서 2개 + EC2 인증서 구성은 불필요하게 복잡, 공개 앱에 부적합. (D) 백엔드 EC2에 별도 인증서 배포는 요구에 없고 불필요. 【시험 포인트】 "공개 웹 앱 SSL + ALB + Route 53" → ACM 퍼블릭 인증서 + ALB + alias 레코드.

해설

【핵심 용어】 ▸ Direct Connect Private VIF + BGP — 온프레미스↔VPC 사설 연결, BGP로 라우트 광고 ▸ VIF 최대 광고 프리픽스 한계 — 사설 VIF는 BGP로 광고 가능한 라우트 수 상한(기본 100개) 존재, 초과 시 BGP 세션 다운 ▸ 라우트 필터/집계(aggregation) — 광고 프리픽스 수를 한도 내로 줄임 【정답 포인트】 ▸ "새 서브넷 추가 후 BGP down, L2는 정상" → 광고 프리픽스가 VIF 한계 초과로 BGP 세션 실패 ▸ (A) 회사 라우터에서 라우트 필터/집계로 광고 라우트 수를 줄여 한도 내로 유지 【오답 체크】 (B) BGP 커뮤니티 태깅("7224…")은 라우트 선호도 제어용, 프리픽스 한계 초과 문제 해결 아님. (C) L2가 정상 확인됐으므로 물리·논리 경로 재검증은 원인과 무관. (D) 포트 179(BGP)는 라우터 간 세션이지 SG/NACL 대상이 아님(BGP는 VPC 데이터플레인이 아닌 제어). 【시험 포인트】 "서브넷 추가 후 DX 사설 VIF BGP down" → 광고 프리픽스 한계 초과, 필터/집계로 축소.

해설

【핵심 용어】 ▸ Cloud WAN + Network Manager 이벤트 — VPC 어태치먼트 상태 변경이 EventBridge 이벤트로 발생 ▸ EventBridge 규칙 → Lambda — Network Manager 이벤트 매칭 시 Lambda 호출해 조건 검사·자동 수락 ▸ 비용 효율 — 서버리스 이벤트 기반, 상시 실행 리소스 불필요 【정답 포인트】 ▸ "새 VPC 어태치먼트 조건부 자동 수락 + 가장 비용 효율적" → (B) Network Manager 이벤트를 매칭하는 EventBridge 규칙 생성, 규칙이 Lambda 호출 【오답 체크】 (A) network function group / service insertion은 검사 트래픽 삽입용이지 어태치먼트 자동 수락 메커니즘 아님. (C) CloudWatch Logs→Kinesis→Lambda는 상시 스트림 처리로 비용·복잡도 큼. (D) EventBridge Pipes는 가능하나 단순 규칙 대비 오버헤드가 커 최소 비용 요구엔 EventBridge 규칙이 우위. 【시험 포인트】 "AWS 이벤트 기반 자동화 최소 비용" → EventBridge 규칙 + Lambda 타겟.

해설

【핵심 용어】 ▸ Split-horizon DNS — 동일 도메인을 소스에 따라 다른 대상으로 해석(내부=프라이빗 ALB, 외부=퍼블릭 ALB) ▸ Route 53 퍼블릭 + 프라이빗 호스티드 존 — 같은 도메인의 공개/사설 뷰 분리 ▸ Inbound Resolver endpoint — 온프레미스 DNS가 VPC의 프라이빗 존을 조회하도록 쿼리 포워딩 대상 제공 【정답 포인트】 ▸ "회사망 요청→프라이빗 ALB, 인터넷 요청→퍼블릭 ALB" → (B) 퍼블릭 호스티드 존(퍼블릭 ALB alias) + 프라이빗 호스티드 존(프라이빗 ALB alias) + inbound resolver 엔드포인트로 온프레미스 쿼리를 프라이빗 존으로 포워딩 ▸ 온프레미스는 프라이빗 존 뷰, 인터넷은 퍼블릭 존 뷰로 split-horizon 해석 【오답 체크】 (A) CloudFront + Lambda@Edge로 요청 출처별 ALB 라우팅은 과도하게 복잡하고 사설 ALB 접근 부적합. (C) 단일 퍼블릭 존에 지오로케이션 + 사설 ALB alias는 프라이빗 리소스 공개 해석 불가·부정확. (D) EC2 DNS 서버 자체 구축은 운영 오버헤드 크고 "퍼블릭 inbound resolver" 개념도 잘못됨. 【시험 포인트】 "동일 도메인 내부/외부 다르게 해석" → 퍼블릭+프라이빗 호스티드 존(split-horizon) + inbound resolver.

해설

【핵심 용어】 ▸ Route 53 Profile — DNS 구성(프라이빗 호스티드 존 연결 등)을 묶어 여러 VPC/계정에 일괄 적용, RAM으로 공유 ▸ AWS RAM 공유 — 네트워킹 계정의 Profile을 조직에 공유해 스포크 VPC가 자동 DNS 해석 ▸ CloudFormation IaC — 엔드포인트·PHZ·PHZ 연결을 코드로 함께 프로비저닝 【정답 포인트】 ▸ "신규 중앙 VPC 엔드포인트의 DNS 해석을 다른 팀 수작업 없이" + "최소 오버헤드" → (A) Route 53 Profile 생성 후 RAM으로 조직에 공유 ▸ (D) VPC 엔드포인트·PHZ·PHZ의 Profile 연결을 네트워킹 계정의 단일 CloudFormation 스택에서 함께 생성 ▸ Profile 공유로 신규 엔드포인트 추가 시 스포크 팀 개입 불필요 【오답 체크】 (B) 스택셋 + EventBridge + Lambda로 PHZ 생성 감지는 불필요하게 복잡, 오버헤드 큼. (C) 크로스 계정 Lambda로 각 스포크 VPC에 PHZ 연결은 커스텀 유지보수 부담. (E) 신규 PHZ를 Route 53 Profile에 연결하는 Lambda 역시 추가 커스텀 코드로 오버헤드 증가. 【시험 포인트】 "중앙 DNS를 조직에 자동 배포 최소 오버헤드" → Route 53 Profile + RAM 공유 + CloudFormation 일괄 생성.