정답 · 해설

해설

【핵심 용어】 ▸ VPC Flow Logs — VPC의 모든 네트워크 인터페이스 트래픽을 기록하는 모니터링 도구 ▸ CloudWatch Logs Insights — 로그 데이터에 대한 실시간 대화식 쿼리 분석 ▸ Traffic Mirroring — 트래픽 복제로 깊은 패킷 검사 가능하지만 추가 비용 【정답 포인트】 ▸ 요구사항: 최소 비용 + 최소 관리 오버헤드 ▸ VPC Flow Logs: 네이티브, 네트워크 수준 트래픽 기록 제공 ▸ CloudWatch Logs: 기본 로깅 인프라로 추가 설정 최소 ▸ CloudWatch Logs Insights: 간단한 쿼리로 원본 리소스 IP 식별 가능 ▸ 비용 효율적: 트래픽 미러링보다 저렴, SIEM 솔루션 불필요 【오답 체크】 (A) Traffic Mirroring: 추가 EC2 비용, 도구 관리 오버헤드 증가 (B) SIEM 솔루션: 라이선스 및 관리 비용 크게 증가 (D) Kinesis + Firehose + Athena: 구성 복잡도 높음, 비용 증가 【시험 포인트】 보안 식별 + 저비용 + 최소 오버헤드 → VPC Flow Logs + CloudWatch Logs Insights 조합

해설

【핵심 용어】 ▸ Direct Connect Gateway — 다중 리전, 다중 계정의 VPC를 온프레미스와 연결하는 중앙 허브 ▸ Transit Gateway Peering — 리전 간 Transit Gateway 간 연결 ▸ Allowed Prefixes — Direct Connect 게이트웨이에서 통신 허용할 CIDR 범위 【정답 포인트】 솔루션 B: ▸ TGW-B를 Direct Connect 게이트웨이와 직접 연결 (계정 간 가능) ▸ VPC-B CIDR을 허용 접두사에 추가로 공지 ▸ TGW-A의 기존 Direct Connect 연결 활용 ▸ 가장 간단하고 직접적인 접근 솔루션 D: ▸ 리전 간 TGW 피어링으로 VPC 간 연결 ▸ 허용 접두사에 모든 CIDR 추가로 온프레미스 라우팅 활성화 ▸ 스케일 가능한 아키텍처 【오답 체크】 (A) VPC 피어링: 계정 간, 리전 간 가능하지만 Direct Connect 게이트웨이 연결 미흡 (C) 두 번째 Transit VIF: Direct Connect 연결 재구성 필요, 비효율적 (E) VPN over Transit VIF: 불필요한 암호화 오버헤드 【시험 포인트】 다중 리전 + 다중 계정 + Direct Connect = (B) TGW 직접 연결 또는 (D) TGW 피어링

해설

【핵심 용어】 ▸ Route 53 Resolver Inbound Endpoint — 온프레미스 DNS가 AWS의 Route 53 쿼리를 하도록 허용 ▸ Route 53 Resolver Outbound Endpoint — AWS VPC가 온프레미스 DNS로 쿼리를 포워드 ▸ Route 53 Private Hosted Zone — AWS 내부 호스트명 관리 【정답 포인트】 솔루션 A (Inbound Endpoint): ▸ 온프레미스 → AWS 쿼리 방향 지원 ▸ 온프레미스에서 Route 53 호스트명 해석 가능 솔루션 C (Outbound Endpoint): ▸ AWS VPC → 온프레미스 DNS 쿼리 방향 지원 ▸ AWS에서 온프레미스 DNS 해석 가능 솔루션 E (Private Hosted Zone): ▸ AWS 내 애플리케이션 호스트명 중앙 관리 ▸ 팀별 독립적 관리 동시에 통합 가능 양방향 해석 = Inbound + Outbound 엔드포인트 필수 【오답 체크】 (B) DHCP 옵션: Route 53 Resolver와 충돌, 불필요 (D) DNS 프록시: 관리 오버헤드 증가 (managed 솔루션 필요) (F) 영역 전송: 복제 복잡도, 관리 오버헤드 증가 【시험 포인트】 하이브리드 DNS 양방향 + 최소 오버헤드 → Inbound + Outbound Endpoint + Private Hosted Zone

해설

【핵심 용어】 ▸ Lambda@Edge — CloudFront 엣지 로케이션에서 요청/응답 전 실행되는 Lambda 함수 ▸ 운영 효율성 — 인프라 관리 최소화, 자동 스케일링 ▸ 토큰 검증 — GET/POST 페이로드 내 인증 토큰 확인 【정답 포인트】 ▸ CloudFront 분배가 이미 배포되어 있으므로 Lambda@Edge 활용 ▸ 엣지에서 인증 수행 → 원본 서버 부하 감소 ▸ 토큰 검증 후 사용자 정의 헤더 추가로 웹 앱이 신뢰할 수 있음 ▸ 운영 오버헤드: AWS 관리 서비스로 최소 ▸ 비용 효율적: 별도 ALB 필터링 불필요 【오답 체크】 (A) ALB: 요청 페이로드 검사 능력 제한, 토큰 검증 로직 복잡 (B) AWS WAF: 네트워크 방화벽, 애플리케이션 로직 검증 부족 (D) 타사 EC2 도구: 관리 오버헤드 증가, 운영 효율성 저하 【시험 포인트】 CloudFront + 토큰 검증 + 운영 효율 → Lambda@Edge 최적 솔루션

해설

【핵심 용어】 ▸ Transit Gateway Route Tables — TGW 연결의 라우팅 전파 및 격리를 관리 ▸ Route Propagation — VPC 경로를 TGW 라우팅 테이블에 자동 학습 ▸ Route Isolation — 특정 VPC 간 통신 차단 【정답 포인트】 요구사항: ▸ Prod ↔ Shared OK, Non-Prod ↔ Shared OK ▸ Prod ↔ Non-Prod NOT OK 해결책: Route Table 1: ▸ 첨부: Prod + Non-Prod 연결 ▸ 경로 전파: Shared Service VPC만 활성화 ▸ 결과: Prod와 Non-Prod는 Shared와만 통신 가능 Route Table 2: ▸ 첨부: Shared Service VPC 연결만 ▸ 경로 전파: Prod + Non-Prod 모두 활성화 ▸ 결과: Shared는 Prod, Non-Prod와 모두 통신 가능 이 구성으로 "Hub and Spoke" 아키텍처 구현 【오답 체크】 (B) 각 VPC의 전파된 경로: Prod와 Non-Prod 간 상호 통신 허용 (정책 위반) (C) 텍스트 오류 (VPC 누락), 개념적으로도 B와 동일 (D) 전파된 경로 비활성화: Shared VPC와 통신 불가능 【시험 포인트】 3VPC 아키텍처 + 선택적 통신 격리 → Route Table 분리 + 전파 제어

해설

【핵심 용어】 ▸ Accelerated VPN — Global Accelerator를 활용하여 공개 인터넷 경로 최적화 ▸ Transit Gateway — 다중 VPC와 하이브리드 연결의 중앙 허브 ▸ VPN Attachment — Transit Gateway에 VPN 연결 통합 【정답 포인트】 ▸ 기존 VPN이 인터넷 혼잡으로 성능 저하 ▸ 가속된 VPN = AWS Global Accelerator + VPN (공개 경로 최적화) ▸ Transit Gateway 통합 이유: - 향후 확장성 (추가 VPC 연결 용이) - VPN 첨부로 가속 VPN 지원 - Virtual Private Gateway는 가속 VPN 지원 안 함 ▸ 최소 관리: Transit Gateway 한 번 설정으로 모든 VPC 지원 【오답 체크】 (A) 기존 VPN 가속 불가능 — Virtual Private Gateway는 가속 VPN 미지원 (C) VPN은 가속 가능하지만 VPG에 연결 불가능 (D) Direct Connect: 구성 시간 길어서 "빨리" 요구사항 미충족 【시험 포인트】 VPN 성능 개선 + 최소 관리 + 빠른 구현 → Transit Gateway + Accelerated VPN

해설

【핵심 용어】 ▸ Transit Gateway Peering — 리전 간 Transit Gateway 간의 고속 연결 ▸ VPN Attachment — 인터넷 기반, 낮은 대역폭 (1.25 Gbps) ▸ 대역폭 최대화 — AWS 글로벌 백본 네트워크 활용 【정답 포인트】 ▸ 요구사항: 최대 대역폭 + 최소 지연 + 최소 오버헤드 ▸ Transit Gateway Peering: - 두 TGW를 AWS 글로벌 네트워크로 연결 - VPN보다 훨씬 높은 대역폭 (제한 없음) - 낮은 지연 (AWS 인프라 직접 연결) - 라우팅 자동 학습 (운영 간단) ▸ 각 리전 IP 주소 범위를 라우팅 테이블에 추가하여 양방향 통신 가능 【오답 체크】 (A) VPN 연결: 대역폭 제한 (1.25 Gbps), 지연 증가, BGP 설정 복잡 (C) VPN 서버: 관리 오버헤드 크게 증가, 성능 저하 (D) 직접 연결: 리전 간 거리로 지연 증가, 확장성 문제 【시험 포인트】 다중 리전 + 최대 대역폭 + 최소 지연 + 최소 오버헤드 → Transit Gateway Peering

해설

【핵심 용어】 ▸ BYOIP (Bring Your Own IP) — 온프레미스 IP를 AWS로 이전하여 클라이언트 연결 유지 ▸ Network Load Balancer (NLB) — TCP/UDP 프로토콜 지원, MQTT 호환 ▸ AWS Global Accelerator — 글로벌 엣지 로케이션을 통한 지연 최소화 【정답 포인트】 ▸ MQTT는 TCP 기반 프로토콜 → NLB 필수 (ALB는 HTTP/HTTPS) ▸ 하드웨어 재구성 불가 → BYOIP로 기존 공개 IP 주소 유지 ▸ 글로벌 지연 최소화 → Global Accelerator (엣지 로케이션 기반) ▸ Global Accelerator + NLB + BYOIP 조합: - 센서 → 동일 IP로 연결 (하드웨어 변경 없음) - 글로벌 엣지 → 가장 가까운 AWS 리전 라우팅 - NLB → TCP MQTT 프로토콜 지원 【오답 체크】 (A) Global Accelerator 없음 → 글로벌 지연 최소화 못함 (C) ALB: HTTP/HTTPS만 지원, MQTT(TCP) 프로토콜 미지원 (D) CloudFront: HTTP/HTTPS CDN, TCP MQTT 프로토콜 미지원 【시험 포인트】 BYOIP + TCP 프로토콜 + 글로벌 지연 최소화 → NLB + Global Accelerator

해설

【핵심 용어】 ▸ ALB Access Logs — ALB가 처리하는 모든 요청의 상세 정보 기록 ▸ Amazon S3 — ALB 액세스 로그의 기본 저장소 ▸ Amazon Athena — S3의 데이터에 대한 SQL 쿼리 실행 ▸ CloudWatch Logs Insights — 실시간 로그 쿼리 【정답 포인트】 ▸ ALB 액세스 로그는 기본적으로 S3로 저장됨 ▸ CloudWatch Logs로 직접 스트리밍은 추가 설정 필요 (복잡) ▸ S3 + Athena: - ALB 로그가 자동으로 S3에 저장됨 - Athena로 SQL 쿼리로 HTTP 상태 코드, 오류 분석 용이 - 비용 효율적 (S3 저장소만) ▸ CloudWatch Logs로 보내는 것 (A, D): - 추가 비용 발생 - 실시간 분석 필요할 때만 유용 - 기본 설정은 S3 저장소 【오답 체크】 (A) CloudWatch Logs Insights: 실시간 쿼리 가능하지만 ALB 로그 기본 저장소 아님 (C) CloudWatch는 S3에서 자동 로그 가져오기 기능 없음 (D) Athena CloudWatch 커넥터: 추가 복잡도, 일반적이지 않음 【시험 포인트】 ALB 액세스 로그 분석 → S3 저장 → Athena SQL 쿼리 = 표준 접근

해설

【핵심 용어】 ▸ Transit VIF — Direct Connect를 통한 프라이빗 연결 ▸ IPsec VPN — 암호화 터널 (전송 중 암호화) ▸ Interface VPC Endpoint — S3에 대한 프라이빗 액세스 (공개 인터넷 우회) ▸ HTTPS — 애플리케이션 계층 암호화 【정답 포인트】 ▸ 요구사항 1: 공개 인터넷을 통하지 않음 → Interface VPC Endpoint (S3 프라이빗 액세스) ▸ 요구사항 2: 전송 중 암호화 → IPsec VPN (추가 암호화) + HTTPS ▸ Transit VIF를 사용하는 이유: - 프라이빗 연결 (공개 인터넷 우회) - IPsec VPN 터널로 추가 보안 ▸ VPC + Interface Endpoint: - S3의 프라이빗 엔드포인트로 모든 트래픽이 AWS 내부 경로 - Direct Connect → Transit Gateway → VPC → Interface Endpoint → S3 【오답 체크】 (A) 공개 VIF: 공개 인터넷 사용, 요구사항 위반 (C) VPC Endpoint만: IPsec 암호화 없음, "전송 중 암호화" 미충족 (D) 공개 VIF + "S3 첨부": Direct Connect 게이트웨이는 S3 첨부 미지원 【시험 포인트】 금융 데이터 + 프라이빗 경로 + 암호화 → Transit VIF + IPsec + Interface VPC Endpoint

해설

【핵심 용어】 ▸ DNS Firewall — Route 53 Resolver 기반 DNS 필터링 ▸ Fail Open — DNS Firewall이 응답 불가능할 때 쿼리를 통과시킬지 차단할지 정책 ▸ SLA (Service Level Agreement) — 서비스 가용성 보장 【정답 포인트】 ▸ 현 상태: DNS Firewall 정책 기반 거부 (승인된 도메인만 허용) ▸ 문제: Firewall 장애 시 모든 쿼리 차단 → SLA 위반 위험 ▸ Fail Open 활성화: - DNS Firewall 응답 불가 상태에서 쿼리를 통과시킴 - SLA 보장: DNS 서비스 가용성 유지 - 비정상 상황에 대한 "open" (통과) 정책 ▸ 설정 위치: VPC의 DNS Firewall 구성 【오답 체크】 (A) Fail Open 비활성화: Firewall 장애 시 SLA 위반 (C) DHCP 옵션 설정: DNS Firewall VPC 설정이 아님, 구식 방법 (D) DHCP 옵션: 현대적 관리 방식이 아님 【시험 포인트】 DNS 가용성 + DNS Firewall 장애 대비 → Fail Open 활성화

해설

【핵심 용어】 ▸ Network Load Balancer (NLB) — TCP/TLS 기반 연결, 엔드투엔드 암호화 지원 ▸ Session Affinity (Sticky Sessions) — 동일 클라이언트를 같은 인스턴스로 라우팅 ▸ 엔드투엔드 암호화 — 클라이언트 ↔ 애플리케이션 전체 SSL 암호화 【정답 포인트】 ▸ 로드 밸런싱 선택: NLB (HTTPS/TLS 엔드투엔드 암호화 지원) - ALB는 ALB-EC2 간 HTTP 설정 후 EC2에서 암호화 (권장되지 않음) ▸ 프로토콜 설정: - 리스너: TCP 포트 443 (클라이언트 ↔ NLB) - 대상 그룹: TCP 포트 443 (NLB ↔ EC2) - 이 구성으로 SSL 패스스루 (NLB는 암호화 미해독) ▸ 세션 어피니티: Sticky Sessions 활성화 (클라이언트 세션 유지) ▸ SSL 인증서: EC2에 배포 (애플리케이션 인증서) ▸ 엔드투엔드 암호화: 클라이언트 → NLB → EC2 모두 암호화 【오답 체크】 (B) ALB + HTTP 대상: 클라이언트-ALB는 HTTPS, ALB-EC2는 HTTP → 중간 해독 (엔드투엔드 X) (C) NLB + TLS 대상: NLB에서 인증서 설정 (응용 인증서 X, 중복) (D) ALB + HTTPS 대상: ALB는 HTTPS 대상 미지원, 리스너 포트 불일치 【시험 포인트】 TCP HTTPS + 세션 고정 + 엔드투엔드 암호화 → NLB + TCP 443 + Sticky Sessions

해설

【핵심 용어】 ▸ DNS 미지원 — IP 주소로만 연결 가능 ▸ Network Load Balancer (NLB) — 고정 IP 주소 지원 ▸ Global Accelerator — 추가 비용, 글로벌 성능 요구 없음 ▸ 비용 효율성 — 불필요한 서비스 제외 【정답 포인트】 ▸ DNS 비지원 요구사항 → IP 주소 기반 연결만 가능 ▸ NLB 선택 이유: - 고정 IP 주소 제공 (Elastic IP) - TCP/UDP 프로토콜 지원 - IoT 디바이스 대규모 수용 가능 ▸ Auto Scaling: - NLB에 첨부로 자동 스케일링 - 수백만 디바이스 부하 처리 ▸ 비용 최소화: - Global Accelerator 불필요 (글로벌 최적화 요구 없음) - NLB + Auto Scaling만으로 충분 - ALB는 DNS 이름 필요 (요구사항 위반) 【오답 체크】 (A) NLB ALB 유형 대상 그룹: 혼합 로드 밸런서 (비표준) (B) Global Accelerator + ALB: 추가 비용, ALB는 DNS 필요 (D) Global Accelerator + NLB: 불필요한 글로벌 가속기 비용 【시험 포인트】 IP 기반 연결 + 최소 비용 + 대규모 확장 → NLB + Auto Scaling

해설

【핵심 용어】 ▸ AWS Global Accelerator — 고정 IP 주소로 글로벌 성능 최적화 ▸ Approved IP Addresses — 방화벽 화이트리스트 ▸ Minimum Latency — 지연 최소화 【정답 포인트】 ▸ 요구사항 분석: 1) 방화벽 화이트리스트: 승인된 IP만 허용 2) 글로벌 액세스: 최소 지연 ▸ Global Accelerator 선택 이유: - 고정 IP 주소 2개 제공 (화이트리스트에 추가) - 글로벌 엣지 로케이션 기반 라우팅 - 애니캐스트 주소: 사용자가 가장 가까운 엣지 위치로 자동 라우팅 - ALB를 엔드포인트로 설정 가능 ▸ 구성: - Global Accelerator 가속기 생성 - ALB를 엔드포인트로 등록 - 고정 IP를 방화벽 화이트리스트에 추가 - 결과: 모든 사용자가 고정 IP로 연결, 지연 최소화 【오답 체크】 (A) NLB: 고정 IP는 있지만, ALB-NLB 중복, 글로벌 라우팅 X (B) CloudFront: CDN, HTTP/HTTPS 컨텐츠 캐싱 (애플리케이션 로직 X) (D) Route 53: DNS 이름 기반, 고정 IP 미지원 【시험 포인트】 글로벌 클라이언트 + 고정 IP 화이트리스트 + 최소 지연 → Global Accelerator

해설

【핵심 용어】 ▸ Interface VPC Endpoint — AWS 서비스에 프라이빗 액세스 ▸ Private Hosted Zone — Route 53 기반 프라이빗 DNS 해석 ▸ Transit Gateway — 중앙 허브로 모든 VPC 연결 ▸ Route Propagation — DNS 쿼리 자동 라우팅 【정답 포인트】 ▸ 요구사항: 공개 엔드포인트 제거 + 최소 운영 오버헤드 ▸ 솔루션 C의 핵심: 1) 중앙 VPC에 Interface Endpoint 생성 - S3 + Systems Manager 프라이빗 엔드포인트 2) Private DNS 비활성화 (정확한 라우팅 제어) 3) Route 53 Private Hosted Zone 생성 - 서비스 도메인 이름 (예: s3.amazonaws.com) - 모든 VPC와 연결 4) Alias Records 설정 - 서비스 도메인 → Interface VPC Endpoint IP 5) Transit Gateway 연결로 네트워크 통합 ▸ 결과: 모든 VPC가 DNS로 쿼리 시 자동 라우팅 【오답 체크】 (A) Private NAT Gateway: "프라이빗 NAT" 존재 안 함 (모순) (B) Route 53 Forwarding Rules: 복잡, 관리 오버헤드 증가 (D) Private DNS 활성화: 여러 VPC에서 충돌 위험, Transit Gateway DNS 지원 필수 【시험 포인트】 중앙집중식 Interface Endpoint + Private Hosted Zone + Transit Gateway = 운영 효율성 최대

해설

【핵심 용어】 ▸ Private Hosted Zone — Route 53의 VPC 내부 DNS 도메인 ▸ Zone Association — 호스팅 영역을 VPC와 연결하여 DNS 해석 ▸ AWS DNS Suffix — 모든 리소스에 일관된 도메인 적용 【정답 포인트】 ▸ 요구사항: 모든 리소스에 aws.example.com 접미사 적용 ▸ 솔루션 D의 장점: 1) 1개의 중앙 Private Hosted Zone - aws.example.com 도메인 보유 - 모든 리전의 리소스 DNS 레코드 포함 2) 모든 VPC와 연결 - 여러 리전: 각 VPC와 연결 가능 - 호스팅 영역은 1개 (중앙 관리) 3) 단일 DNS 소스 - 어느 리전의 VPC에서든 aws.example.com으로 해석 - 관리 효율성 최대 【오답 체크】 (A) 리전별 호스팅 영역: 분산 관리, 복잡도 증가, DNS 일관성 어려움 (B) Zone Transfer: 호스팅 영역 복제 메커니즘, AWS Route 53 기능 아님 (C) Multivalue Answer: 모든 리소스를 단일 레코드에 포함 (확장성 제한) 【시험 포인트】 다중 리전 + 단일 DNS 도메인 + 중앙 관리 → 1개 Private Hosted Zone + 모든 VPC 연결

해설

【핵심 용어】 ▸ Route 53 Resolver — 하이브리드 DNS 환경에서 양방향 DNS 해석 제공 ▸ Private Hosted Zone — VPC 내 프라이빗 도메인 관리 ▸ Inbound/Outbound Endpoint — DNS 쿼리 방향성 제어 【정답 포인트】 ▸ 프라이빗 호스팅 영역 사용 필요 (B 오답): 온프레미스 도메인은 프라이빗이므로 퍼블릭 영역 부적합 ▸ 아웃바운드 엔드포인트 사용 (C, D 오답): AWS에서 온프레미스 DNS로 쿼리 전달 시 아웃바운드 필요 ▸ Resolver 규칙 공유 필수: RAM을 통해 여러 VPC와 규칙 공유 ▸ 인바운드 엔드포인트: 온프레미스에서 AWS 도메인 해석 시 필요 【오답 체크】 (B) 퍼블릭 호스팅 영역은 인터넷 노출 위험 및 온프레미스 프라이빗 도메인과 충돌 (C) 아웃바운드 엔드포인트로 도메인 전달은 역방향 (온프레미스→AWS 해석 안 됨) (D) 규칙을 영역 대신 공유하는 것은 비효율적이며 확장성 부족 【시험 포인트】 멀티 VPC 마이그레이션에서 하이브리드 DNS 아키텍처는 Egress VPC 중앙화 + RAM 공유 패턴. 양방향 해석을 위해 인바운드(온프레미스→AWS)와 아웃바운드(AWS→온프레미스) 모두 필요하며, private hosted zone이 보안 기본.

해설

【핵심 용어】 ▸ VPN Acceleration — Site-to-Site VPN의 처리량 향상 (1.25 Gbps→2.5 Gbps) ▸ Transit Gateway Target — VPN 연결의 대상으로 TGW 지정 ▸ Virtual Private Gateway — 이전 방식의 VPN 게이트웨이 【정답 포인트】 ▸ 새 연결 필요 (B 오답): 기존 연결은 VGW 대상이므로 수정으로는 TGW 연결 불가 ▸ VPN Acceleration 활성화: 지연 시간 개선의 핵심 (처리량 2배 증가) ▸ Transit Gateway 대상: 피어링된 VPC들과의 효율적 연결 ▸ VPN 디바이스 업데이트: 엔드포인트 변경 필수 【오답 체크】 (B) 기존 VPN은 VGW 부착이므로 수정만으로는 TGW 연결 미지원 (C) 리전 간 TGW는 비용 증가 및 추가 지연 (가속은 단일 연결에만 적용) (D) Global Accelerator는 VPN 종단점 지원 불가 【시험 포인트】 VPN 지연 문제 해결은 VPN Acceleration 활성화 + Transit Gateway 중앙화 패턴. 새 연결 생성이 필수인 이유는 기존 VGW 기반 연결은 VPN 가속 미지원.

해설

【핵심 용어】 ▸ Interface VPC Endpoint — 프라이빗 IP로 AWS 서비스 액세스 ▸ Private Hosted Zone — 엔드포인트 DNS 해석 관리 ▸ Private DNS Names — 자동/수동 DNS 레코드 설정 【정답 포인트】 ▸ B (프라이빗 DNS 끔): 수동으로 호스팅 영역 관리 필요 ▸ C (수동 호스팅 영역): 온프레미스에서도 해석 가능하도록 명시적 설정 ▸ E (프라이빗 DNS 이름 사용): vpce 엔드포인트 DNS로 접근 ▸ 온프레미스 접근: Resolver로 프라이빗 호스팅 영역 공유 필요 (별도 구성) 【오답 체크】 (A) 프라이빗 DNS 켜면 자동 호스팅 영역 생성되어 온프레미스 공유 불가 (D) 자동 생성 영역은 VPC 간 연결만 가능, 온프레미스 미지원 (F) vpce.amazonaws.com 엔드포인트는 온프레미스에서 직접 해석 불가 【시험 포인트】 온프레미스 + 멀티 VPC 엔드포인트 접근 시 수동 호스팅 영역 + 프라이빗 DNS 이름 조합이 필수. 자동 옵션은 VPC 간에만 작동.

해설

【핵심 용어】 ▸ AWS Config — 리소스 구성 변경 추적 및 이력 관리 ▸ Config Rules — 원하는 상태 검증 및 자동 감지 ▸ Remediation — 비규격 리소스 자동 복구 【정답 포인트】 ▸ Config 필수: 과거 구성 이력 및 변경 추적 기능 ▸ 규칙 기반 검증: 보안 정책 준수 자동 확인 ▸ 재구성 자동화: 비규격 상태 자동 복구 ▸ 감시 + 이력 + 규정준수 세 가지 요구사항 완벽 충족 【오답 체크】 (A) EventBridge는 이벤트 트리거만 제공, 이력 관리 미지원 (B) CloudWatch는 메트릭 중심, 구성 추적 미지원 (D) Systems Manager는 구성 이력 관리 부족, Config만큼 상세한 변경 추적 불가 【시험 포인트】 네트워크 규정준수 + 이력 추적은 AWS Config 전담. 다른 서비스들은 부분 기능만 제공.