AWS Advanced Networking Specialty (ANS-C01) 실전 모의고사 65문제

A) VPC 피어링 - 더 저렴하고 간단함 B) Transit Gateway - 중앙 집중식 라우팅, 전이적 라우팅 지원, N개 VPC 연결 시 관리 복잡성 O(1) C) 두 방식은 동일하며 비용만 다름 D) VPC 피어링 - 더 낮은 레이턴시

정답: B

설명: VPC 피어링은 전이적(transitive) 라우팅을 지원하지 않습니다. A-B, B-C가 피어링되어 있어도 A에서 C로 직접 통신할 수 없습니다. 10개 VPC를 모두 연결하려면 최대 N*(N-1)/2 = 45개의 피어링이 필요합니다. Transit Gateway는 중앙 허브 역할로 하나의 TGW에 모든 VPC를 연결하면 전이적 라우팅이 가능합니다. 10+ VPC 환경에서는 Transit Gateway가 훨씬 효율적입니다.

A) VPC 피어링 생성 - 겹치는 CIDR도 지원 B) VPC 피어링은 불가능하며, PrivateLink(엔드포인트 서비스)를 사용하여 특정 서비스 노출 C) NAT Gateway로 주소 변환 D) 인터넷을 통해 통신

정답: B

설명: VPC 피어링과 Transit Gateway는 겹치는 CIDR 블록을 허용하지 않습니다. AWS PrivateLink를 사용하면 NLB 뒤의 서비스를 VPC 엔드포인트 서비스로 노출하여 다른 VPC에서 인터페이스 엔드포인트를 통해 접근할 수 있습니다. CIDR 충돌이 있어도 작동합니다. 장기적으로는 VPC CIDR 재설계가 권장됩니다.

A) TGW 리전 간 피어링은 자동으로 라우팅 전파 지원 B) TGW 리전 간 피어링은 정적 라우팅만 지원하며, 피어링 어태치먼트에 수동으로 경로 추가 필요 C) BGP를 사용한 동적 라우팅 지원 D) 동일 리전 TGW와 동일하게 동작

정답: B

설명: Transit Gateway 리전 간 피어링은 BGP 동적 라우팅을 지원하지 않습니다. 정적 라우팅만 지원하므로 각 TGW 라우팅 테이블에 수동으로 상대 리전의 CIDR 블록을 추가해야 합니다. 리전 간 트래픽은 AWS 글로벌 네트워크를 통해 암호화되어 전송됩니다.

A) IPv6 NAT Gateway 사용 B) Egress-Only Internet Gateway(EIGW) 사용 및 라우팅 테이블에 ::/0 → EIGW 경로 추가 C) 일반 인터넷 게이트웨이(IGW)로 충분 D) IPv6는 NAT 불필요하여 별도 구성 없음

정답: B

설명: Egress-Only Internet Gateway는 IPv6 전용으로, IPv4의 NAT Gateway와 유사하게 아웃바운드 IPv6 트래픽은 허용하지만 인터넷에서 인스턴스로의 인바운드 연결을 차단합니다. 프라이빗 서브넷의 IPv6 인스턴스가 인터넷으로 패치를 받거나 외부 API를 호출할 때 사용합니다.

A) VPC 피어링 설정 B) NLB(Network Load Balancer) 뒤에 서비스를 배치하고 VPC 엔드포인트 서비스를 생성 C) 퍼블릭 IP로 서비스 노출 D) Site-to-Site VPN 설정

정답: B

설명: AWS PrivateLink 아키텍처에서 서비스 제공자는 NLB(또는 GWLB) 뒤에 서비스를 배치하고 VPC Endpoint Service를 생성합니다. 소비자는 인터페이스 VPC 엔드포인트를 생성하여 Private IP를 통해 서비스에 접근합니다. 트래픽은 AWS 네트워크 내에서만 이동하며 인터넷을 경유하지 않습니다. NLB는 IP, 인스턴스, Lambda 타겟을 지원합니다.

A) Route 53 퍼블릭 호스팅 영역 생성 B) Route 53 Resolver 인바운드 엔드포인트를 VPC에 생성하고 온프레미스 DNS 서버에서 해당 VPC 도메인에 대한 조건부 포워더 설정 C) Route 53 Resolver 아웃바운드 엔드포인트만으로 충분 D) VPC Flow Logs로 DNS 쿼리 분석

정답: B

해설: Route 53 Resolver 인바운드 엔드포인트는 VPC 내에 ENI를 생성하여 온프레미스 DNS 서버가 Direct Connect나 VPN을 통해 VPC 내 도메인 이름을 조회할 수 있게 합니다. 온프레미스 DNS 서버에 internal.corp 도메인에 대해 인바운드 엔드포인트의 IP로 조건부 포워딩을 설정합니다.

A) 모든 VPC에 개별 NAT Gateway 생성 B) Transit Gateway에 모든 VPC와 Egress VPC 연결, Spoke VPC의 기본 경로(0.0.0.0/0)를 TGW로 향하게 하고 Egress VPC에서 NAT Gateway로 라우팅 C) VPC 피어링으로 Egress VPC에 연결 D) 각 VPC에서 인터넷 게이트웨이 연결

정답: B

해설: 중앙 집중식 인터넷 아웃바운드 설계: 1) Egress VPC에 NAT Gateway와 IGW 구성, 2) Transit Gateway에 모든 스포크 VPC와 Egress VPC 연결, 3) 스포크 VPC 라우팅 테이블에 0.0.0.0/0 → TGW 경로 추가, 4) TGW 라우팅 테이블에서 기본 경로를 Egress VPC로 향하게 설정, 5) Egress VPC에서 NAT Gateway로 라우팅. 이 패턴은 NAT Gateway 비용을 절감하고 중앙 집중식 보안 통제가 가능합니다.

A) EC2 인스턴스 간 멀티캐스트 B) VPN 어태치먼트를 통한 멀티캐스트 C) 피어링된 TGW 간 멀티캐스트 D) 멀티캐스트 도메인 내 여러 그룹 지원

정답: C

해설: Transit Gateway 멀티캐스트는 피어링된 TGW(리전 간 또는 동일 리전 TGW 간 피어링) 간에는 지원되지 않습니다. 또한 Direct Connect Gateway와 VPN 어태치먼트도 멀티캐스트를 지원하지 않습니다. EC2 인스턴스는 TGW 멀티캐스트 그룹에 구성원으로 등록될 수 있습니다.

A) 10.0.0.0/24와 같은 작은 CIDR로 시작 B) RFC 1918 주소 범위(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) 내에서 충분히 큰 CIDR 할당, 온프레미스 및 다른 VPC와 겹치지 않도록 계획, /16 ~ /20 권장 C) 공인 IP 범위를 VPC CIDR로 사용 D) CIDR는 언제든지 변경 가능하므로 작게 시작

정답: B

해설: VPC CIDR 계획 모범 사례: 1) RFC 1918 프라이빗 주소 사용, 2) 충분히 큰 범위 할당(/16 권장 - 65,536개 IP), 3) 온프레미스 네트워크와 겹치지 않도록 조직 전체 IP 계획 수립, 4) VPC 간 겹침 방지(피어링/TGW 연결 고려), 5) 서브넷 계획을 위한 여유 공간 확보. VPC CIDR은 추가는 가능하지만 변경은 불가합니다.

A) 모든 VPC 트래픽이 단일 중앙 Network Firewall VPC를 통과 B) 각 VPC에 Network Firewall 엔드포인트를 배포, VPC 내부 트래픽을 로컬에서 검사 C) Transit Gateway와 별개로 독립 배포 D) 인바운드 트래픽만 검사

정답: B

해설: Network Firewall 배포 모델: 1) 분산(Distributed) - 각 VPC에 방화벽 엔드포인트 배포, VPC 레벨에서 트래픽 검사, 2) 중앙 집중(Centralized) - 전용 보안 VPC에 방화벽 배포, TGW를 통해 모든 트래픽을 라우팅하여 검사, 3) 결합(Combined) - 인터넷 엣지는 중앙 집중, East-West는 분산. 분산 모델은 VPC 별 세밀한 정책 적용이 가능하지만 비용이 더 높습니다.

A) 모든 경우에 Transit VIF 사용 B) 퍼블릭 AWS 서비스(S3, DynamoDB) 접근 → Public VIF, 단일 VPC 접근 → Private VIF, Transit Gateway 통한 다중 VPC 접근 → Transit VIF C) Private VIF만 사용하여 보안 강화 D) 용도에 상관없이 동일한 VIF 사용

정답: B

해설: Direct Connect Virtual Interface 유형: 1) Public VIF - AWS 퍼블릭 서비스(S3, Glacier, SNS 등) 및 AWS IP 주소 접근, BGP로 AWS 퍼블릭 IP 수신, 2) Private VIF - 단일 VPC 또는 동일 리전의 Direct Connect Gateway로 VPC 접근, 3) Transit VIF - Direct Connect Gateway를 통해 Transit Gateway로 다중 VPC 및 리전 접근. Transit VIF는 Private VIF와 동시 사용 불가.

A) LAG는 여러 Direct Connect 위치에 걸쳐 구성 가능 B) LAG는 동일 Direct Connect 위치에서 동일 속도의 여러 연결을 논리적으로 묶어 대역폭 증가와 장애 복구 제공 C) LAG는 자동으로 Active/Passive 페일오버를 제공 D) LAG 내 연결은 서로 다른 속도 가능

정답: B

해설: LAG(Link Aggregation Group)는 동일 Direct Connect 위치에서 동일 속도의 여러 물리적 연결을 하나의 논리 연결로 결합합니다. LACP(Link Aggregation Control Protocol)를 사용하여 대역폭을 집계합니다. 모든 연결은 동일한 속도여야 하고 동일 Direct Connect 위치에 있어야 합니다. 최소 활성 연결 수를 설정하여 SLA를 보장할 수 있습니다.

A) 비용 절감을 위해 B) Direct Connect는 기본 경로, Site-to-Site VPN은 백업 경로로 구성하여 고가용성 확보 C) 두 방식은 동시에 사용 불가 D) VPN이 Direct Connect보다 더 빠름

정답: B

해설: Direct Connect + VPN 이중화 패턴: DX는 낮은 레이턴시와 높은 대역폭의 기본 경로로 사용하고, VPN은 DX 장애 시 자동 페일오버를 위한 백업 경로로 구성합니다. BGP MED(Multi-Exit Discriminator) 속성이나 AS Path Prepending을 사용하여 DX 경로를 우선 선택하도록 합니다. DX 장애 시 VPN으로 자동 전환됩니다.

A) VPN 성능 모니터링 B) 피어의 활성 상태를 주기적으로 확인하여 비활성 피어를 감지하고 터널을 재초기화하거나 페일오버를 트리거 C) VPN 트래픽 암호화 방식 결정 D) 최대 전송 단위(MTU) 설정

정답: B

해설: Dead Peer Detection(DPD)은 IKE(Internet Key Exchange) 프로토콜의 확장으로, 일정 간격으로 R-U-THERE 메시지를 보내 VPN 피어의 생존 여부를 확인합니다. DPD 타임아웃이 발생하면 죽은 피어 액션에 따라 터널을 제거(Clear), 재시작(Restart), 또는 보류(Hold)합니다. AWS VPN은 DPD를 지원하며, 활성 터널 유지를 위해 BGP keepalive 또는 DPD 설정이 중요합니다.

A) 더 강력한 암호화 제공 B) AWS Global Accelerator의 Anycast IP와 엣지 로케이션을 활용하여 인터넷 구간을 최소화하고 AWS 백본을 통한 최적 경로 사용 C) 무료로 제공 D) 더 많은 터널 지원

정답: B

해설: Accelerated VPN은 AWS Global Accelerator를 사용하여 VPN 트래픽을 가장 가까운 AWS 엣지 로케이션으로 라우팅한 후 AWS 글로벌 네트워크를 통해 AWS 리전으로 전달합니다. 인터넷을 통한 구간이 최소화되어 레이턴시가 낮아지고 연결 안정성이 향상됩니다. Transit Gateway에 연결된 VPN에서만 사용 가능합니다.

A) VPN 암호화를 대체하기 위해 B) 물리적 Direct Connect 연결 레이어에서 Layer 2 보안 제공(이더넷 프레임 암호화), 물리적 도청으로부터 보호 C) 레이턴시 감소 D) 대역폭 증가

정답: B

해설: MACsec(IEEE 802.1AE)은 이더넷 링크 레벨에서 데이터를 암호화합니다. Direct Connect에서 MACsec을 활성화하면 온프레미스 장비와 AWS Direct Connect 위치 간의 물리적 링크에서 Layer 2 암호화가 적용됩니다. 특히 공유 코로케이션 환경에서 물리적 도청을 방지합니다. 10Gbps 및 100Gbps 전용 연결에서 지원됩니다.

A) 정적 라우팅보다 느리지만 더 안전함 B) 동적 라우팅 업데이트, 자동 페일오버, ECMP(Equal Cost Multi-Path) 지원으로 여러 VPN 터널을 통한 로드 밸런싱 C) 설정이 더 간단함 D) BGP를 사용하면 암호화가 자동 적용

정답: B

해설: BGP VPN의 장점: 1) 네트워크 변경 시 자동 라우팅 업데이트, 2) 터널 장애 시 자동 페일오버(DPD와 함께 작동), 3) Transit Gateway와 함께 ECMP 사용 시 여러 VPN 터널의 대역폭 집계, 4) BGP 커뮤니티 속성으로 경로 선호도 조정. 각 VPN 연결에는 2개의 IPSec 터널이 있으며 BGP로 두 터널을 모두 사용 가능합니다.

A) 단일 VPN 연결로 충분 B) TGW에 여러 Site-to-Site VPN 연결을 생성하고 ECMP를 활성화, 온프레미스 라우터에서 동일한 BGP 경로를 여러 터널로 광고 C) Direct Connect와 함께 사용할 때만 ECMP 가능 D) ECMP는 VPN에서 지원되지 않음

정답: B

해설: Transit Gateway는 ECMP를 통해 여러 VPN 연결의 대역폭을 집계합니다. 각 VPN 연결은 두 개의 IPSec 터널을 제공하며, 여러 VPN 연결을 사용하면 최대 대역폭을 늘릴 수 있습니다(최대 50Gbps 집계 가능). 온프레미스 라우터에서 동일한 BGP 경로를 모든 터널로 광고해야 합니다. TGW에서는 VPN 어태치먼트에 ECMP를 활성화해야 합니다.

A) 두 서비스는 동일한 기능 제공 B) Reachability Analyzer는 두 특정 엔드포인트 간 연결 경로를 분석하고 차단 요소를 식별, Network Access Analyzer는 의도하지 않은 네트워크 접근 경로를 식별 C) Network Access Analyzer만 VPC Flow Logs 분석 D) Reachability Analyzer는 실시간 트래픽 분석

정답: B

해설: AWS Reachability Analyzer: 두 네트워크 엔드포인트(EC2, ENI, IGW 등) 간의 도달 가능성을 분석하여 연결 가능 여부와 경로를 보여주고 차단 원인(SG, NACL, 라우팅)을 식별합니다. Network Access Analyzer: 네트워크 보안 요구사항을 정의하고 이에 위배되는 예상치 못한 접근 경로(인터넷에서 EC2로의 접근 등)를 식별합니다. 두 서비스 모두 실제 트래픽을 전송하지 않는 정적 분석입니다.

A) VPC 간 트래픽 복제 및 동기화 B) EC2 인스턴스의 네트워크 트래픽을 복사하여 침입 탐지 시스템(IDS) 또는 패킷 분석 도구로 전송 C) 로드 밸런서 트래픽 분산 D) VPN 트래픽 암호화

정답: B

해설: VPC Traffic Mirroring은 EC2 인스턴스의 ENI(Elastic Network Interface)에서 네트워크 트래픽을 미러링하여 보안 분석, 위협 탐지, 트러블슈팅에 활용합니다. 트래픽을 다른 EC2 인스턴스(IDS/IPS 어플라이언스) 또는 NLB로 전송합니다. 소스와 대상 ENI에 필터를 적용하여 특정 트래픽만 미러링할 수 있습니다. 에이전트 없는 방식으로 동작합니다.

A) CloudWatch 지표 사용 B) Athena에서 CREATE EXTERNAL TABLE로 Flow Logs S3 경로를 테이블로 생성 후 SQL 쿼리 실행 C) GuardDuty 대시보드에서 확인 D) VPC Flow Logs 콘솔에서 필터링

정답: B

해설: VPC Flow Logs + Athena 분석 절차: 1) Athena에서 Flow Logs S3 버킷을 가리키는 외부 테이블 생성(Flow Logs 필드에 맞는 스키마 정의), 2) SQL 쿼리 실행 - SELECT srcaddr, SUM(bytes) as total_bytes FROM vpc_flow_logs WHERE dstport = 443 AND start BETWEEN timestamp1 AND timestamp2 GROUP BY srcaddr ORDER BY total_bytes DESC LIMIT 10. 파티셔닝으로 쿼리 성능과 비용을 최적화합니다.

A) AWS 서비스의 API 오류 모니터링 B) 하이브리드 네트워크(Direct Connect, VPN)의 레이턴시, 패킷 손실, 지터를 지속적으로 모니터링 C) VPC 내 EC2 인스턴스 CPU 사용률 모니터링 D) S3 버킷 접근 모니터링

정답: B

해설: CloudWatch Network Monitor는 하이브리드 네트워크의 성능 지표를 지속적으로 모니터링합니다. 온프레미스 위치와 AWS 리소스 간의 레이턴시, 패킷 손실률, 지터(jitter) 지표를 측정합니다. Direct Connect 또는 VPN 성능 저하를 감지하고 알람을 통해 운영 팀에 알립니다. 네트워크 성능 SLA 모니터링에 활용됩니다.

A) TGW의 라우팅 테이블 자동 설정 B) 글로벌 네트워크(Transit Gateway, Direct Connect, VPN, SD-WAN)를 중앙 대시보드에서 시각화하고 이벤트 모니터링 C) TGW 비용 분석 D) VPC Flow Logs 중앙 집계

정답: B

해설: Transit Gateway Network Manager는 글로벌 네트워크 토폴로지를 시각화하는 중앙 관리 서비스입니다. AWS 리전 전반의 TGW, VPC 연결, Direct Connect, VPN, SD-WAN 장치를 지도 기반 뷰로 표시합니다. 이벤트(라우팅 변경, 연결 상태)를 모니터링하고 CloudWatch와 통합됩니다. Route Analyzer로 경로 분석도 가능합니다.

A) 보안 그룹 규칙 수를 줄이고 여러 보안 그룹에서 공유하여 일관성 있는 IP 목록 관리 B) 자동으로 위협 IP를 차단 C) NACL 규칙을 대체 D) 비용 절감

정답: A

해설: 관리형 프리픽스 리스트는 CIDR 블록의 집합으로, 보안 그룹 규칙이나 라우팅 테이블에서 참조할 수 있습니다. 예: 10개의 IP 주소를 한 프리픽스 리스트로 관리하면 여러 보안 그룹이 이 리스트를 참조하여 규칙 수를 줄입니다. IP 주소 변경 시 프리픽스 리스트만 업데이트하면 참조하는 모든 보안 그룹에 자동 반영됩니다. AWS 서비스용 관리형 프리픽스 리스트(CloudFront, S3 등)도 제공됩니다.

A) ALB + ACM 퍼블릭 인증서 B) ALB에서 mTLS 활성화 + ACM Private CA로 클라이언트/서버 인증서 발급, 또는 API Gateway + mTLS 설정 C) CloudFront + WAF 조합 D) NLB + TCP 패스스루

정답: B

해설: mTLS 구현 옵션: 1) ALB - mTLS 지원 활성화 시 클라이언트 인증서를 검증하고 인증서 정보를 헤더로 백엔드에 전달, ACM Private CA에서 클라이언트 인증서 발급, 2) API Gateway - 클라이언트 인증서 구성으로 mTLS 구현, 신뢰 저장소 업로드, 3) App Mesh/Service Mesh - 서비스 간 mTLS 자동 처리.

A) 서버가 클라이언트 응답을 보내는 포트이며 허용 불필요 B) NACL이 상태 비저장이므로 서버의 응답이 클라이언트의 임시 포트(Linux: 32768-60999, Windows: 49152-65535, AWS 권장: 1024-65535)로 나가는 것을 아웃바운드에서 허용해야 함 C) 임시 포트는 보안 그룹에서만 관리 D) 임시 포트 범위는 고정되어 있지 않아 모든 포트를 허용해야 함

정답: B

해설: NACL은 상태 비저장(stateless)으로 응답 트래픽도 별도 규칙이 필요합니다. 클라이언트가 서버의 80포트에 요청 시, 서버의 응답은 클라이언트의 임시 포트로 돌아갑니다. AWS는 1024-65535 범위 허용을 권장합니다. 반면 SG는 상태 저장이므로 자동으로 응답 트래픽을 허용합니다. 실무에서는 SG만으로도 충분한 경우가 많지만, NACL을 추가 방어층으로 사용할 때 임시 포트 설정이 필요합니다.

A) VPN 암호화 제공 B) 원본 패킷을 캡슐화하여 가상 어플라이언스로 전송, 어플라이언스는 검사 후 GWLB에 반환, 원본 패킷의 소스/목적지 정보 보존 C) Layer 7 로드 밸런싱 수행 D) DNS 기반 라우팅 제공

정답: B

해설: GWLB는 GENEVE(Generic Network Virtualization Encapsulation) 프로토콜을 사용하여 원본 패킷을 캡슐화하고 가상 어플라이언스(IDS/IPS, 방화벽)로 전달합니다. 어플라이언스는 패킷을 검사한 후 GWLB에 반환하고, GWLB는 원본 목적지로 트래픽을 전달합니다. GENEVE는 원본 IP/포트 정보를 보존하여 어플라이언스가 실제 트래픽 정보를 볼 수 있게 합니다.

A) 단일 루트 CA로 모든 인증서 발급 B) 루트 CA(오프라인 유지) → 중간 CA(발급 CA) → 리프 인증서 계층 구조, 각 환경/팀별 별도 발급 CA 구성 C) 모든 CA를 활성 상태로 유지 D) 리프 인증서만 사용하고 CA는 외부 위탁

정답: B

해설: PKI 계층 설계 모범 사례: 1) 루트 CA - 최상위 신뢰 앵커, 오프라인 상태 유지 권장(실제 서명에 사용하지 않음), 2) 중간/발급 CA - 실제 리프 인증서를 발급하는 CA, 각 환경(prod/dev)이나 팀별 별도 구성, 3) 리프 인증서 - TLS/mTLS에 사용되는 실제 인증서. 루트 CA 손상 시 영향을 최소화하기 위해 이 계층 구조가 중요합니다.

A) 인터넷 연결 속도 향상 B) MPI(Message Passing Interface) 기반 HPC 및 머신러닝 분산 훈련을 위한 OS 우회(OS-bypass) 통신으로 초저지연 고대역폭 달성 C) VPN 성능 향상 D) S3 전송 속도 향상

정답: B

해설: EFA(Elastic Fabric Adapter)는 AWS의 맞춤형 고성능 네트워크 인터페이스입니다. OS 우회 기능으로 커널을 거치지 않고 직접 NIC와 통신하여 마이크로초 단위의 초저지연을 달성합니다. HPC 클러스터의 MPI 애플리케이션(기상 예측, 유체 역학, 분자 동역학)과 딥러닝 분산 훈련(PyTorch Distributed, Horovod)에 사용됩니다. 클러스터 배치 그룹에서 사용하면 최대 효과를 발휘합니다.

A) Active/Passive/Standby 세 가지 유형 B) 클러스터(초저지연 HPC), 분산(고가용성, 단일 실패점 방지), 파티션(Kafka, HDFS 등 대용량 분산 처리) C) 모든 배치 그룹은 동일한 기능 제공 D) 온디맨드/스팟/예약 인스턴스 유형에 따라 구분

정답: B

해설: EC2 배치 그룹 유형: 1) 클러스터(Cluster) - 동일 AZ의 단일 랙 또는 인접 랙에 인스턴스 배치, 10Gbps 네트워크, 낮은 레이턴시, HPC용, 2) 분산(Spread) - 각 인스턴스를 별도의 하드웨어에 배치, AZ별 최대 7개 인스턴스, 중요한 워크로드의 고가용성, 3) 파티션(Partition) - 각 파티션을 다른 랙에 배치, AZ당 최대 7개 파티션, Kafka, Cassandra, HDFS 같은 대규모 분산 시스템용.

A) Global Accelerator는 콘텐츠 캐싱을 제공 B) Global Accelerator는 Anycast IP를 사용하여 TCP/UDP 트래픽을 최적의 AWS 엣지에서 수신 후 AWS 백본으로 라우팅, 비HTTP 프로토콜 및 정적 IP 요구 사항 지원 C) CloudFront보다 느림 D) HTTP 트래픽만 지원

정답: B

해설: Global Accelerator vs CloudFront: GA는 Anycast IP 2개를 제공하여 전 세계 엣지 로케이션에서 수신 후 AWS 글로벌 네트워크로 라우팅합니다. TCP, UDP 프로토콜을 지원하여 게임, IoT, VoIP에 적합하고 정적 IP가 필요한 경우에 사용합니다. 트래픽 다이얼로 가중치 기반 라우팅, 헬스 체크 기반 자동 페일오버를 지원합니다. CloudFront는 HTTP/HTTPS 콘텐츠 캐싱 및 동적 가속에 특화되어 있습니다.

A) 사용자의 위치에 기반한 DNS 응답 B) AWS 리소스 또는 사용자 정의 위치의 편향값(bias)을 조정하여 트래픽 분산 비율을 세밀하게 제어 C) 대기 시간 기반 라우팅 D) IP 주소 기반 라우팅

정답: B

해설: Route 53 Geoproximity 라우팅은 사용자와 리소스 간의 지리적 거리를 기반으로 트래픽을 라우팅합니다. 편향값(bias)을 양수로 설정하면 해당 리소스로 더 많은 트래픽을 유도하고, 음수로 설정하면 줄입니다. AWS 리소스는 리전을 기준으로, 비AWS 리소스는 위도/경도 좌표로 지정합니다. 트래픽 흐름 정책으로 시각적으로 설정할 수 있습니다.

A) 두 기능은 동일하며 이름만 다름 B) Lambda@Edge는 뷰어/오리진 요청/응답 4개 이벤트 처리 가능, Node.js/Python 지원, 실행 시간 최대 30초; CloudFront Functions는 뷰어 요청/응답만 지원, JavaScript만, 실행 시간 밀리초, 더 저렴 C) Lambda@Edge만 HTTP 헤더 수정 가능 D) CloudFront Functions는 오리진 요청 수정 가능

정답: B

해설: Lambda@Edge: 뷰어 요청, 뷰어 응답, 오리진 요청, 오리진 응답 4개 이벤트에서 실행, Node.js/Python 지원, 최대 5초(뷰어)/30초(오리진), 1MB 패키지 크기. CloudFront Functions: 뷰어 요청, 뷰어 응답만 지원, JavaScript(ECMAScript 5.1), 실행 시간 밀리초 이내, 2KB 코드 크기 제한, 100배 더 저렴. 간단한 헤더 조작, URL 재작성, A/B 테스트는 CloudFront Functions가 적합합니다.

A) 두 개의 별도 도메인 사용 B) Route 53 가중치 기반(Weighted) 라우팅 정책으로 온프레미스 IP와 AWS 리소스에 가중치를 설정하여 점진적 트래픽 전환 C) CloudFront로 트래픽 분산 D) ALB로 트래픽 분산

정답: B

해설: Route 53 가중치 기반 라우팅으로 점진적 마이그레이션: 예를 들어 초기에는 온프레미스 90, AWS 10으로 설정하고 테스트 후 점진적으로 AWS 가중치를 높입니다. 헬스 체크와 결합하면 장애 시 자동으로 정상 리소스로 트래픽이 이동합니다. 최종적으로 온프레미스 0, AWS 100으로 전환 완료합니다.

A) 단순 라우팅 정책 B) 지연 시간 기반(Latency) 라우팅 + 헬스 체크를 조합, 각 리전 ALB에 지연 시간 레코드 생성 및 헬스 체크 연결 C) 지리적 위치(Geolocation) 라우팅만 사용 D) 가중치 기반 라우팅만 사용

정답: B

해설: Active-Active 멀티 리전 설계: 1) 각 리전의 ALB/NLB에 대해 Route 53 지연 시간 기반 레코드 생성, 2) 각 레코드에 헬스 체크 연결, 3) 정상 상태에서는 최저 지연 시간 리전으로 라우팅, 4) 헬스 체크 실패 시 해당 리전의 레코드를 자동으로 제외하고 다음 최저 지연 시간 리전으로 라우팅. Global Accelerator도 동일한 패턴을 TCP/UDP 레이어에서 구현할 수 있습니다.

A) 단일 Direct Connect 연결로 충분 B) 서로 다른 Direct Connect 위치에서 두 개의 Direct Connect 연결 + 각각 별도의 고객 라우터와 AWS 디바이스 C) Direct Connect + NAT Gateway 이중화 D) 두 개의 VPN 연결로 DX 대체

정답: B

해설: Direct Connect 고가용성 아키텍처: 최고 수준 - 두 개의 서로 다른 DX 위치, 각각 다른 AWS 디바이스, 고객 측 다른 라우터. 이를 통해 장비 장애, 위치 장애, 케이블 절단 등 모든 단일 실패점을 제거합니다. 최소 권장 - 동일 DX 위치에서 두 개의 연결(서로 다른 AWS 디바이스). VPN은 DX 장애 시 백업으로 사용하는 경우 단독 이중화 수단으로는 부적절합니다.

A) enableDnsSupport만 활성화 B) enableDnsSupport(DNS 서버 제공)와 enableDnsHostnames(EC2에 DNS 이름 할당) 모두 활성화 C) Route 53 Resolver 엔드포인트만 필요 D) DHCP 옵션 세트 수정 필요

정답: B

해설: VPC DNS 속성: 1) enableDnsSupport - AWS가 제공하는 DNS 서버(169.254.169.253 또는 VPC CIDR + 2번 주소)를 VPC 내 인스턴스에서 사용 가능하게 합니다. 기본값: 활성화, 2) enableDnsHostnames - 퍼블릭 IP가 있는 EC2 인스턴스에 퍼블릭 DNS 이름을 할당합니다. 기본 VPC: 활성화, 신규 VPC: 비활성화. 프라이빗 호스팅 영역을 VPC에 연결하려면 두 속성이 모두 활성화되어야 합니다.

A) 온프레미스 DNS 서버에 하드코딩된 IP 등록 B) Direct Connect/VPN 구성 + Route 53 Resolver 인바운드 엔드포인트 생성 + 온프레미스 DNS 서버에 조건부 포워더 설정(AWS 내부 도메인 → 인바운드 엔드포인트 IP) C) 퍼블릭 Route 53 호스팅 영역 사용 D) CloudFront로 DNS 처리

정답: B

해설: 하이브리드 DNS 통합 아키텍처: 1) Direct Connect 또는 VPN으로 온프레미스 - AWS 간 네트워크 연결, 2) VPC에 Route 53 Resolver 인바운드 엔드포인트 생성(ENI 2개, 각 AZ에 하나), 3) 온프레미스 DNS 서버에 조건부 포워더 설정: *.ap-northeast-1.compute.internal 또는 커스텀 도메인 → 인바운드 엔드포인트의 IP 주소, 4) 온프레미스 애플리케이션이 내부 DNS 이름으로 AWS 리소스에 접근.

A) VPC 엔드포인트 성능 최적화 B) VPC 엔드포인트를 통해 접근할 수 있는 AWS 서비스 리소스와 작업을 제한 C) VPC 간 연결 허용/거부 D) 네트워크 ACL 대체

정답: B

해설: VPC 엔드포인트 정책은 엔드포인트를 통한 서비스 접근을 제한하는 리소스 기반 정책입니다. 예: S3 게이트웨이 엔드포인트 정책에서 특정 S3 버킷만 허용: "Resource": "arn:aws:s3:::my-company-bucket/*". DynamoDB, S3 같은 게이트웨이 엔드포인트와 인터페이스 엔드포인트 모두에 적용 가능합니다. 이를 통해 VPC에서 S3에 접근할 때 특정 버킷으로만 제한하여 데이터 유출을 방지할 수 있습니다.

A) S3 버킷을 프라이빗으로 설정 B) S3 게이트웨이 엔드포인트 생성 + 라우팅 테이블 업데이트 + S3 버킷 정책에서 aws:SourceVpce 조건으로 엔드포인트 외 접근 거부 C) S3 Transfer Acceleration 비활성화 D) CloudFront + OAC(Origin Access Control) 사용

정답: B

해설: 구현 단계: 1) VPC에 S3 게이트웨이 엔드포인트 생성, 2) 서브넷 라우팅 테이블에 S3 엔드포인트 경로 추가, 3) S3 버킷 정책에 조건 추가: "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-xxxxx"}} → 지정된 VPC 엔드포인트 외의 접근 거부, 4) EC2 인스턴스의 IAM 역할에 S3 접근 권한 부여. 이를 통해 모든 S3 트래픽이 AWS 내부 네트워크만 경유합니다.

A) IP 주소 기반 차단만 지원 B) HTTP SNI 및 HTTPS SNI 검사로 특정 도메인 허용/차단, 와일드카드 지원(.example.com) C) DNS 쿼리만 차단 D) 정규 표현식만 사용 가능

정답: B

해설: Network Firewall 도메인 리스트 규칙 그룹은 HTTP Host 헤더 및 HTTPS SNI(Server Name Indication)를 검사하여 특정 도메인에 대한 트래픽을 허용하거나 차단합니다. .example.com처럼 와일드카드를 사용하면 서브도메인을 포함한 모든 하위 도메인을 처리합니다. HTTP 및 HTTPS 트래픽에 대한 화이트리스트/블랙리스트 정책을 구현할 수 있습니다.

A) 성능 향상을 위해 B) 트래픽 분리 및 네트워크 세그멘테이션 구현(예: 개발/운영 VPC 분리, Spoke-to-Spoke 트래픽 차단, 검사 VPC를 통한 강제 라우팅) C) 비용 절감을 위해 D) AWS 서비스 제한 때문에

정답: B

해설: TGW 다중 라우팅 테이블 사용 사례: 1) 환경 분리 - Prod VPC와 Dev VPC가 서로 직접 통신하지 못하도록 별도 라우팅 테이블에 연결, 2) 보안 검사 - 모든 East-West 트래픽을 보안 VPC(Network Firewall, IDS)를 통과하도록 강제 라우팅, 3) 공유 서비스 - DNS, Active Directory 같은 공유 서비스 VPC는 모든 스포크와 통신 가능하지만 스포크 간 직접 통신은 차단. 블랙홀 라우팅으로 특정 CIDR 트래픽을 완전 차단도 가능합니다.

A) 여러 오리진에 부하 분산 B) 기본 오리진 장애 시 자동으로 보조 오리진으로 페일오버 C) 여러 오리진의 콘텐츠를 병합 D) 오리진 서버의 성능을 향상

정답: B

해설: CloudFront 오리진 그룹은 고가용성을 위한 자동 오리진 페일오버를 제공합니다. 기본 오리진(primary)과 보조 오리진(secondary)을 그룹으로 구성하고, 기본 오리진이 지정된 HTTP 응답 코드(4xx, 5xx)를 반환하거나 연결 실패 시 자동으로 보조 오리진으로 전환합니다. 예: S3 버킷이 기본, 다른 리전 S3가 보조로 구성하여 리전 장애에 대비.

A) VPC 피어링은 자동으로 라우팅 구성 B) 라우팅 테이블 미업데이트, 보안 그룹 미허용, NACL 차단, DNS 해석 설정 누락 C) 피어링 상태가 Active가 아닌 경우 D) 두 VPC가 다른 리전에 있는 경우

정답: B

해설: VPC 피어링 후 통신 실패 체크리스트: 1) 양쪽 VPC의 라우팅 테이블에 상대방 VPC CIDR → 피어링 연결 경로 추가 여부 확인, 2) 보안 그룹에서 상대방 VPC CIDR 또는 SG를 소스로 허용 여부 확인, 3) NACL에서 해당 트래픽 허용 여부 확인(임시 포트 포함), 4) 피어링 연결 상태가 Active인지 확인, 5) 피어링된 VPC의 DNS 해석 옵션 활성화 여부 확인.

A) 두 유형은 동일한 방식으로 동작 B) 인터페이스 엔드포인트는 ENI 기반으로 VPC 내 프라이빗 IP 할당, 비용 발생, 보안 그룹 적용 가능, 다양한 서비스 지원; 게이트웨이 엔드포인트는 라우팅 테이블 항목 기반, 무료, S3/DynamoDB만 지원 C) 게이트웨이 엔드포인트가 모든 서비스를 지원 D) 인터페이스 엔드포인트는 퍼블릭 트래픽 포함

정답: B

해설: 엔드포인트 유형 비교: 인터페이스 엔드포인트 - VPC에 ENI 생성, 프라이빗 IP 주소 할당, 보안 그룹 연결 가능, 엔드포인트당 시간당 비용 + 데이터 처리 비용, 대부분의 AWS 서비스 지원, DNS 이름으로 접근. 게이트웨이 엔드포인트 - 라우팅 테이블에 경로 추가, 추가 비용 없음, S3 및 DynamoDB만 지원, 정책으로 접근 제어.

A) 외관상 차이 없음 B) ENA는 SR-IOV를 통해 하이퍼바이저를 우회하여 하드웨어와 직접 통신, 최대 100Gbps 대역폭, 더 낮은 레이턴시, 더 높은 PPS(Packet Per Second) C) ENA는 IPv6만 지원 D) ENA는 특정 AZ에서만 사용 가능

정답: B

해설: Enhanced Networking(ENA): SR-IOV(Single Root I/O Virtualization)를 사용하여 하이퍼바이저 오버헤드 없이 직접 NIC와 통신합니다. 최대 100Gbps 네트워크 대역폭, 높은 PPS(패킷 처리 수), 낮은 지터(jitter). 최신 세대 EC2 인스턴스(C5, M5, R5 등)에서 기본 활성화됩니다. Intel 82599 VF(10Gbps)도 ENA의 이전 버전으로 지원됩니다.

A) 버킷 정책에 CloudFront IP 목록 추가 B) Origin Access Control(OAC) 사용 - CloudFront가 AWS SigV4로 S3에 서명된 요청을 보내고, S3 버킷 정책에서 CloudFront 서비스 주체만 허용 C) S3 퍼블릭 읽기 허용 후 CloudFront에서 WAF로 보호 D) Origin Access Identity(OAI) 사용 - 구성이 더 간단

정답: B

해설: OAC(Origin Access Control)는 OAI(Origin Access Identity)의 후속 기능으로 더 강력한 보안을 제공합니다. OAC는 SigV4로 S3 요청에 서명하여 인증합니다. S3 버킷 정책에서 "Principal": {"Service": "cloudfront.amazonaws.com"} 와 "Condition": {"StringEquals": {"AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT:distribution/DIST_ID"}} 조건으로 특정 CloudFront 배포만 허용합니다.

A) Direct Connect 연결의 대역폭 증가 B) 단일 Private VIF 또는 Transit VIF를 여러 AWS 리전의 VPC 또는 Transit Gateway에 연결(교차 리전 연결) C) Direct Connect 연결 비용 절감 D) VPN 연결 지원

정답: B

해설: Direct Connect Gateway는 온프레미스에서 단일 DX 연결을 사용하여 여러 AWS 리전의 VPC에 접근할 수 있게 합니다. Private VIF를 DXGW에 연결하면 여러 리전의 VPC를 단일 VIF로 접근 가능합니다. Transit VIF를 DXGW에 연결하면 Transit Gateway를 통해 여러 VPC에 접근합니다. 다만 DXGW는 동일 계정과 동일 리전의 VPC 간 라우팅은 제공하지 않습니다.

A) 모든 헤더, 쿼리 스트링, 쿠키를 캐시 키에 포함 B) 캐시 정책(Cache Policy)에서 실제로 캐시 결과에 영향을 미치는 헤더, 쿼리 스트링, 쿠키만 캐시 키에 포함, 나머지는 오리진 요청 정책(Origin Request Policy)으로 오리진에만 전달 C) 모든 캐싱 비활성화 D) CloudFront 분산 설정 변경

정답: B

해설: CloudFront 캐시 히트율 최적화: 캐시 키에 포함되는 항목이 많을수록 캐시 항목 수가 많아져 히트율이 낮아집니다. 예: User-Agent 헤더를 캐시 키에 포함하면 브라우저마다 별도 캐시 항목이 생성됩니다. 캐시 정책에는 실제로 응답에 영향을 주는 파라미터만 포함하고, 오리진에 전달이 필요하지만 캐시 키에는 불필요한 정보(인증 헤더 등)는 오리진 요청 정책으로 분리합니다.

A) RDS 인스턴스에 공인 IP 할당 B) Direct Connect 또는 Site-to-Site VPN으로 온프레미스 - VPC 연결, RDS 서브넷의 보안 그룹에서 온프레미스 CIDR 허용, Route 53 Resolver를 통한 RDS DNS 이름 해석 C) RDS 프록시를 인터넷에 노출 D) Lambda를 중간 계층으로 사용

정답: B

해설: 온프레미스 - RDS 프라이빗 접근 아키텍처: 1) DX 또는 VPN으로 네트워크 연결, 2) RDS 인스턴스가 있는 서브넷의 보안 그룹에 온프레미스 IP 범위에서 DB 포트(3306, 5432 등) 인바운드 허용, 3) Route 53 Resolver 인바운드 엔드포인트로 온프레미스에서 RDS DNS 이름(FQDN) 해석, 4) RDS에 퍼블릭 액세스 비활성화. Secrets Manager로 DB 자격증명 관리 권장.

A) 각 스포크 VPC에 Network Firewall 배포 B) 검사 VPC(Inspection VPC)에 Network Firewall을 중앙 배포, TGW에서 스포크 VPC의 트래픽을 검사 VPC로 강제 라우팅(Appliance Mode 활성화) C) 보안 그룹으로 스포크 간 직접 통신 제어 D) WAF로 East-West 트래픽 검사

정답: B

해설: 중앙 집중식 East-West 트래픽 검사: 1) 검사 VPC에 Network Firewall 엔드포인트 배포, 2) TGW에 검사 VPC 연결, 3) TGW의 라우팅 테이블에서 스포크 VPC 간 트래픽을 검사 VPC로 라우팅, 4) 검사 VPC의 TGW 어태치먼트에 Appliance Mode 활성화(비대칭 라우팅 방지), 5) 검사 VPC 내에서 트래픽이 NF를 통과 후 목적지 스포크 VPC로 전달.

A) 두 정책은 동일한 결과를 제공 B) 지연 시간 기반은 AWS가 측정한 네트워크 레이턴시를 기준으로 최적 리전에 라우팅(더 빠른 응답), 지리적 위치는 사용자의 IP 위치를 기준으로 특정 지역 규정 준수/콘텐츠 제공에 사용 C) 지리적 위치가 항상 더 낮은 레이턴시 제공 D) 지연 시간 기반은 IP 주소 기반

정답: B

해설: Latency 라우팅: AWS가 측정한 리전 간 실제 네트워크 레이턴시 기준으로 가장 빠른 응답을 제공하는 리전으로 라우팅. 성능 최적화에 적합. Geolocation 라우팅: 사용자의 IP 주소에서 국가/대륙/주를 판단하여 해당 위치에 맞는 리소스로 라우팅. GDPR(EU 데이터 주권), 지역별 콘텐츠(언어, 가격), 컴플라이언스에 적합. 사용자의 실제 물리적 위치가 반드시 레이턴시가 낮은 곳과 일치하지 않을 수 있습니다.

A) 보조 CIDR는 추가 불가 B) VPC와 겹치지 않는 CIDR 추가 가능, 기존 연결(피어링/TGW)의 CIDR과 겹치지 않아야 함, 총 5개까지 CIDR 블록 가능(기본값) C) 보조 CIDR는 반드시 기본 CIDR의 서브셋이어야 함 D) 보조 CIDR 추가 시 기존 서브넷 재생성 필요

정답: B

해설: VPC 보조 CIDR 블록 제한: 1) 기본 VPC CIDR와 겹치지 않아야 함, 2) 연결된 VPC 피어링이나 TGW의 다른 VPC CIDR와 겹치지 않아야 함, 3) RFC 1918 주소 범위 사용 권장, 4) 기본 최대 5개 CIDR 블록(AWS Support에 한도 증가 요청 가능), 5) 특정 CIDR 범위는 예약되어 사용 불가(예: 198.19.0.0/16은 AWS 내부 사용).

A) 복잡한 딥 패킷 검사(DPI) 수행 B) 패킷별 개별 처리(세션 추적 없음), 단순한 5-tuple(프로토콜, 소스/목적지 IP, 소스/목적지 포트) 기반 허용/거부/포워드 결정 C) DNS 쿼리 검사 D) TLS 검사

정답: B

해설: Stateless 규칙 그룹은 각 패킷을 독립적으로 처리합니다(SG와 달리 세션 상태 추적 없음). 5-tuple 기반으로 패킷을 허용, 거부, 또는 Stateful 규칙 그룹으로 포워드합니다. 고성능 기본 필터링에 사용합니다. Stateful 규칙 그룹은 세션을 추적하여 더 정교한 검사(HTTP 검사, Suricata IDS 규칙, TLS SNI 검사)를 수행합니다.

A) SD-WAN은 AWS에서 지원되지 않음 B) EC2에 SD-WAN 가상 어플라이언스(VMware SD-WAN, Cisco Viptela 등) 배포 또는 Transit Gateway Network Manager와 연동 C) 직접 API 통합만 가능 D) AWS Marketplace에서만 배포 가능

정답: B

해설: AWS에서 SD-WAN 통합 방법: 1) EC2에 SD-WAN 어플라이언스 가상 인스턴스 배포, Site-to-Site VPN 또는 Direct Connect로 온프레미스 SD-WAN 패브릭과 연결, 2) Transit Gateway Network Manager의 SD-WAN 장치 등록 기능으로 글로벌 네트워크 시각화, 3) AWS Marketplace의 서드파티 SD-WAN 솔루션 AMI 활용. SD-WAN은 지점(branch) 네트워킹을 중앙에서 관리하고 다중 WAN 링크를 최적화합니다.

A) 각 계정에 별도의 Route 53 호스팅 영역 생성 B) 공유 서비스 VPC에 Route 53 Resolver 엔드포인트와 프라이빗 호스팅 영역을 중앙 배치하고, RAM(Resource Access Manager)으로 Resolver 규칙을 다른 계정과 공유 C) 퍼블릭 DNS만 사용 D) 각 계정에 독립적인 DNS 서버 구성

정답: B

해설: 중앙 집중식 DNS 아키텍처: 1) 공유 서비스 계정의 중앙 VPC에 Route 53 인바운드/아웃바운드 엔드포인트 배포, 2) 모든 내부 도메인에 대한 프라이빗 호스팅 영역을 중앙 VPC에 연결, 3) RAM으로 Resolver 포워딩 규칙을 다른 계정과 공유, 4) 스포크 계정의 VPC에서 공유된 Resolver 규칙을 연결하여 중앙 DNS로 포워딩. 이를 통해 일관된 네임스페이스와 DNS 정책 관리가 가능합니다.

A) 해당 IP를 수동으로 모든 인스턴스의 SG에서 차단 B) WAF IP 세트 또는 NACL에 차단 규칙 추가, 또는 Network Firewall 상태 비저장 규칙에서 해당 IP 차단 C) EC2 인스턴스 종료 D) 인터넷 게이트웨이 삭제

정답: B

해설: 포트 스캔 공격 대응: 1) Network Firewall(가장 빠른 차단 - 네트워크 레이어에서 차단), 2) WAF IP 세트(HTTP/HTTPS 트래픽 차단, ALB/CloudFront 앞단), 3) NACL(서브넷 레이어에서 차단, 단 수동이고 규칙 수 제한 있음). GuardDuty가 활성화되어 있다면 Recon:EC2/PortProbeUnprotectedPort 탐지 결과를 받을 수 있습니다. 자동화된 대응은 EventBridge + Lambda로 NACL 또는 WAF IP 세트를 자동 업데이트합니다.

A) 두 유형은 기술적으로 동일 B) Dedicated Connection은 단일 고객 전용 물리적 연결(1Gbps, 10Gbps, 100Gbps), Hosted Connection은 파트너를 통해 더 작은 대역폭(50Mbps~10Gbps)을 공유 인프라에서 제공 C) Hosted Connection이 더 비쌈 D) Dedicated Connection은 더 많은 가상 인터페이스 지원

정답: B

해설: DX 연결 유형: Dedicated Connection - AWS와 고객 간의 전용 물리적 이더넷 연결, 1/10/100Gbps, 최대 50개 VIF 생성 가능. Hosted Connection - AWS Direct Connect 파트너가 제공, 50Mbps~10Gbps, VIF 1개만 생성 가능(호스팅 VIF). 소규모 대역폭이 필요하거나 빠른 프로비저닝이 필요한 경우 Hosted Connection이 적합합니다.

A) 실시간 분석이 필요한 경우 B) 비용 절감(S3 저장 비용이 CW Logs보다 낮음), Athena로 대용량 장기 분석, S3 Lifecycle 정책으로 데이터 보관 관리, 서드파티 SIEM 통합 C) 더 빠른 수집을 위해 D) CloudWatch Logs가 Flow Logs를 지원하지 않음

정답: B

해설: Flow Logs 저장 대상 선택: CloudWatch Logs - 실시간 모니터링, 지표 필터, 알람, 구독 필터(Lambda, Kinesis로 스트리밍), 비용이 높음. S3 - 대용량 데이터 비용 효율적 저장, Athena로 직접 쿼리, 서드파티 도구 통합, Glacier 아카이빙. 두 대상을 동시에 사용할 수도 있습니다. 대부분의 대규모 환경에서는 S3 + Athena가 기본, 실시간 보안 알람은 CloudWatch 구독 필터로 Lambda를 트리거합니다.

A) 서비스가 중단됨 B) Global Accelerator가 자동으로 트래픽을 정상 상태의 다른 엔드포인트(다른 리전 또는 AZ)로 라우팅 C) 사용자가 수동으로 페일오버를 실행해야 함 D) DNS 캐시가 만료될 때까지 기다려야 함

정답: B

해설: Global Accelerator의 헬스 체크는 TCP, HTTP, HTTPS를 지원하며 각 엔드포인트(ALB, NLB, EIP, EC2)의 상태를 지속적으로 확인합니다. 엔드포인트 장애 감지 시 1분 이내에 트래픽을 정상 엔드포인트로 자동 리다이렉션합니다. 이는 Route 53 헬스 체크(DNS TTL에 의존)보다 훨씬 빠른 페일오버를 제공합니다. 또한 트래픽 다이얼(Traffic Dial)로 특정 엔드포인트 그룹의 트래픽 비율을 0으로 설정하여 수동 페일오버도 가능합니다.

A) TLS 트래픽의 암호화 키를 볼 수 있음 B) TLS 복호화(SSL inspection)를 수행하여 HTTPS 페이로드를 검사하며, 이를 위해 Network Firewall이 중간자(MITM) 역할을 하고 ACM Private CA로 발급한 인증서 사용 C) TLS 1.0 이하만 검사 가능 D) TLS 검사는 성능에 영향 없음

정답: B

해설: Network Firewall TLS 검사: 아웃바운드 또는 양방향 TLS 트래픽을 복호화하여 Suricata 규칙으로 검사할 수 있습니다. Network Firewall이 MITM(Man-In-The-Middle) 역할을 수행하므로 ACM Private CA에서 발급한 CA 인증서가 필요하며, 클라이언트가 이 CA를 신뢰해야 합니다. 검사 후 원래 목적지와 새로운 TLS 세션을 설정합니다. 성능 영향이 있으므로 적절한 용량 계획이 필요합니다.

A) VPC 어태치먼트 B) VPN 어태치먼트 C) Direct Connect Gateway 어태치먼트 D) S3 버킷 어태치먼트

정답: D

해설: Transit Gateway 지원 어태치먼트 유형: 1) VPC - Transit Gateway와 VPC 연결, 2) VPN - Customer Gateway와 IPSec VPN 연결, 3) Direct Connect Gateway - DXGW를 통한 DX 연결, 4) Transit Gateway Peering - 다른 TGW와 피어링(리전 간 또는 리전 내), 5) Connect - SD-WAN 장치와 GRE/BGP로 연결. S3 버킷은 TGW 어태치먼트 유형이 아닙니다.

A) HTTP 쿠키 기반 세션 고정이 필요한 경우 B) 초저지연, 극도로 높은 처리량(수백만 RPS), TCP/UDP/TLS 패스스루, 고정 IP 주소, PrivateLink 백엔드 서비스 노출이 필요한 경우 C) 경로 기반 라우팅이 필요한 경우 D) WAF 통합이 필요한 경우

정답: B

해설: NLB 사용 사례: 1) 극도로 높은 처리량과 초저지연(마이크로초 레이턴시), 2) TCP/UDP/TLS 트래픽의 패스스루(Layer 4), 3) 고정 IP 주소 제공(EIP 연결 가능), 4) PrivateLink 서비스의 엔드포인트로 사용, 5) Source IP 보존(Client IP를 백엔드로 직접 전달). ALB는 HTTP/HTTPS(Layer 7), 경로/헤더 기반 라우팅, WAF 통합에 적합합니다.

A) 한 번에 하나의 터널만 활성화하여 충돌 방지 B) 두 터널 모두 활성화하고 BGP 또는 Static 라우팅으로 두 터널 모두 사용(Active/Active 또는 Active/Standby) C) 터널 수는 성능에 영향 없음 D) 두 번째 터널은 AWS에서 자동으로 관리

정답: B

해설: AWS Site-to-Site VPN은 항상 두 개의 IPSec 터널을 제공합니다(고가용성). 두 터널 모두 활성화하는 것이 모범 사례입니다. BGP 사용 시: 두 터널에서 BGP 세션을 유지하고 MED 값 또는 AS Path로 기본/보조 터널을 설정합니다. Transit Gateway와 ECMP를 사용하면 두 터널을 Active/Active로 구성하여 대역폭을 집계할 수 있습니다. 하나의 터널만 활성화하면 AWS의 유지보수 작업 중 연결이 끊어질 수 있습니다.

A) CloudFront 캐시 TTL을 0으로 설정 B) 오리진 그룹으로 보조 오리진 페일오버 구성, 오리진 응답 타임아웃 값 증가, AWS Shield Advanced로 DDoS 방어, WAF 속도 제한으로 오리진 과부하 방지 C) CloudFront 배포를 삭제하고 직접 오리진에 접근 D) Route 53 헬스 체크로 오리진 상태 확인

정답: B

해설: CloudFront 오리진 오류 감소 전략: 1) 오리진 그룹으로 자동 페일오버(기본 오리진 실패 시 보조로 전환), 2) 오리진 응답 타임아웃(기본 30초, 최대 60초로 증가 가능), 3) 오리진 연결 시도 횟수 증가(기본 3회), 4) WAF 속도 제한으로 오리진 과부하 방지, 5) AWS Shield Advanced로 DDoS 공격으로 인한 오리진 과부하 방지, 6) 스케일링 자동화로 오리진 용량 확장.