정답 · 해설

해설

【핵심 용어】 Transit Gateway 첨부(attachment)는 VPC의 서브넷들을 Transit Gateway에 연결합니다. Transit Gateway 첨부 시 지정된 서브넷만 Transit Gateway로 라우팅 가능합니다. Transit Gateway는 각 가용 영역에 네트워크 인터페이스를 배포하므로, 특정 AZ의 서브넷을 사용할 수 있습니다. 라우팅 테이블의 0.0.0.0/0 경로는 Transit Gateway 첨부에 포함된 서브넷만 사용할 수 있습니다. 【정답 포인트】 B가 정답입니다. 문제의 핵심은 서브넷 10.0.3.0/24 (us-west-2c AZ)가 Transit Gateway와 통신하지 못한다는 점입니다. 이는 Transit Gateway 첨부에 us-west-2c 가용 영역의 서브넷이 포함되지 않았기 때문입니다. Transit Gateway 첨부를 업데이트하여 10.0.3.0/24 서브넷을 추가하면, 이 서브넷이 Transit Gateway의 us-west-2c 네트워크 인터페이스를 통해 다른 VPC와 통신할 수 있게 됩니다. 라우팅 테이블의 0.0.0.0/0은 이미 Transit Gateway를 가리키고 있으므로, 첨부만 업데이트하면 됩니다. 【오답 체크】 A: 라우팅 테이블에 명시적 경로를 추가하는 것은 문제를 해결하지 못합니다. 이미 0.0.0.0/0이 설정되어 있고, 라우팅 테이블은 모든 서브넷이 공유하기 때문에, 첨부 문제를 해결하지 않습니다. C: Transit Gateway 라우팅 테이블의 정적 경로는 계정 A에서 생성되지만, 계정 B의 리소스가 첨부되지 않았으면 도움이 되지 않습니다. D: 전파(propagation) 다시 생성은 이미 0.0.0.0/0이 설정된 상황에서 불필요합니다. 【시험 포인트】 ANS-C01의 Transit Gateway 문제에서 핵심은 "Transit Gateway 첨부와 가용 영역 커버리지"입니다. 라우팅 테이블과 Transit Gateway 라우팅만으로는 부족하며, 반드시 VPC의 서브넷이 Transit Gateway 첨부에 포함되어야 합니다. 특히 멀티 AZ 환경에서 새 서브넷을 추가할 때는 Transit Gateway 첨부를 동시에 업데이트해야 합니다. "least maintenance overhead"와 "즉시 효과"를 고려할 때 첨부 업데이트가 가장 직접적인 해결책입니다.

해설

【핵심 용어】 ▸ SRX Series — Juniper 고급 방화벽/보안 플랫폼 ▸ 보고 엔진 — 보안 통계 및 트렌드 생성 ▸ 보안 로깅 — 정책 적용 및 위협 탐지 기록 【정답 포인트】 ▸ (B) 정답 — 보안 로깅 필수 ▸ Security Logging = 네트워크 보안 이벤트 기록 ▸ 정책 위반, 위협 탐지, 보안 인시던트 추적 ▸ 보고 엔진 → 보안 로깅 데이터로 정확한 통계 생성 【오답 체크】 (A) 패킷 캡처 — 트래픽 분석용. 보고 엔진 필수 요소 아님. (60~100자) (C) 시스템 로깅 — 운영 이벤트 기록. 보안 보고에는 보안 로깅 필요. (60~100자) (D) SNMP — 장비 모니터링 프로토콜. 보고 생성과 무관. (60~100자) 【시험 포인트】 ▸ SRX 보고 = 보안 로깅 기반 ▸ Security Logging = 정책 감사 필수 ▸ 컴플라이언스 보고 = 보안 로깅 활성화 전제 ▸ 실무 설정 = 보안 로깅 첫 확인 항목

해설

【핵심 용어】 ▸ Queue Status — 콜 센터 에이전트 상태 ▸ On Queue vs Off Queue — 고객 호출 수신 여부 ▸ Available Status — 시스템상 표시 상태 【정답 포인트】 ▸ (A) 정답 — Off Queue = Available (사용 가능) ▸ Off Queue 상태 → 고객 대기열 미수신 ▸ 시스템상 Available 표시 → 다른 작업 수행 가능 ▸ 교육, 관리업무, 휴식 활동 가능 【오답 체크】 (B) Busy — 에이전트가 고객과 활발히 통화 중인 상태. Off Queue 아님. (60~100자) (C) Away — 에이전트가 일시적으로 자리 비운 상태. (60~100자) (D) Break — 에이전트가 휴식 중인 명시적 상태. Available과는 다름. (60~100자) 【시험 포인트】 ▸ Queue Status = 호출 가용성 ▸ On Queue = Active 상태 ▸ Off Queue = Available (비호출 상태) ▸ 직원 배치 = Queue 상태 기반 조정

해설

【핵심 용어】 ▸ PCI DSS — 카드 소유자 데이터 보안 표준 ▸ PCI 컴플라이언스 — 결제 카드 데이터 보호 ▸ 미디어 캡처 제한 — 음성 데이터 녹음 금지 【정답 포인트】 ▸ (C) 정답 — 미디어 캡처 비활성화 필수 ▸ PCI DSS 규정 → 카드 소유자 데이터 보호 ▸ 음성 통화 녹음 → 카드 정보 포함 가능 ▸ 미디어 캡처 비활성화 → 카드 데이터 유출 방지 【오답 체크】 (A) 발신자 번호 — 통화 라우팅용. PCI DSS와 무관. (60~100자) (B) 프로토콜 캡처 — 네트워크 진단용. PCI DSS 직접 제약 없음. (60~100자) (D) SIP 액세스 레벨 — 네트워크 보안. PCI DSS 특정 대상 아님. (60~100자) 【시험 포인트】 ▸ PCI DSS = 음성 데이터 보호 ▸ 미디어 캡처 = 카드 정보 유출 위험 ▸ 클라우드 통신 = 규정 준수로 기능 제한 ▸ 콜 센터 = PCI 데이터 취급 시 필수 제한

해설

【핵심 용어】 ▸ External Trunk — 외부 통신망 연결 ▸ 신호 프로토콜 — SIP 신호 전송 방식 ▸ 전송 프로토콜 — TCP/UDP 기반 【정답 포인트】 ▸ (B) TCP — SIP 신호 전송 (신뢰성) ▸ (C) TLS — 암호화된 신호 (보안) ▸ (E) UDP — RTP 미디어 전송용 ▸ SIP + TCP/TLS/UDP 조합으로 안전한 통신 【오답 체크】 (A) RTP — 미디어 프로토콜. 신호 트렁크 선택 옵션 아님. (60~100자) (D) SIP — 기본 신호 프로토콜. 트렁크 설정에서 자동 포함. (60~100자) 【시험 포인트】 ▸ 신호 = TCP/TLS (SIP) ▸ 미디어 = UDP (RTP) ▸ 보안 = TLS 암호화 신호 ▸ 트렁크 설정 = 프로토콜 계층 구분 필수

해설

【핵심 용어】 ▸ DID — Direct Inward Dialing 번호 ▸ 라우팅 대상 — 외부 직접 연결점 ▸ 콜 센터 구축 — 개인/부서/자동응답 【정답 포인트】 ▸ (B) 담당자 — 특정 직원에게 DID 할당 ▸ (C) 콜 플로우 — 자동응답 시스템으로 라우팅 ▸ (D) 전화기 — 특정 물리 단말로 할당 ▸ 외부 발신자가 직접 대상으로 연결 가능 【오답 체크】 (A) 외부 트렁크 — 네트워크 연결점. DID 할당 대상 아님. (60~100자) (E) 큐 — 대기열 관리. DID는 큐로 할당 불가능. (60~100자) (F) Edge — 네트워크 엣지 장비. DID 할당 대상 아님. (60~100자) 【시험 포인트】 ▸ DID = 개인/부서/자동응답 할당 ▸ 콜 라우팅 = DID 기반 직접 연결 ▸ 콜 센터 = DID로 부서 분류 ▸ 네트워크 요소 ≠ DID 할당 대상

해설

【핵심 용어】 ▸ 멀웨어 분석 파이프라인 — 효율성 + 정확도 ▸ 캐시 조회 — 이미 알려진 파일 빠른 판정 ▸ 정적 분석 — 파일 구조 검사 ▸ 동적 분석 — 런타임 동작 모니터링 【정답 포인트】 ▸ (B) 정답 — 캐시 조회 → 안티바이러스 스캔 → 정적 분석 → 동적 분석 ▸ 캐시 먼저 = 가장 빠른 검증 ▸ 서명 스캔 = 이미 알려진 악성 파일 탐지 ▸ 정적 분석 = 파일 코드/구조 검사 ▸ 동적 분석 = 실제 실행 모니터링 (시간 소모) 【오답 체크】 (A) 캐시 조회 누락 — 초반 캐시 확인 생략은 비효율. (60~100자) (C) 안티바이러스 스캔 먼저 — 캐시 확인 우선. 중복 스캔 피함. (60~100자) (D) 안티바이러스 마지막 — 로직 역순. 서명 스캔이 먼저 수행. (60~100자) 【시험 포인트】 ▸ 멀웨어 탐지 = 캐시→서명→정적→동적 ▸ 성능 최적화 = 빠른 검증 우선 ▸ 정확도 = 깊이 있는 분석 보완 ▸ 실무 구현 = 파이프라인 효율성 필수

해설

【핵심 용어】 ▸ CIDR 표기법 — /32는 호스트 라우트 ▸ 서브넷 마스크 — 255.255.255.255 (/32) ▸ 호스트 라우팅 — 단일 IP 주소 대상 【정답 포인트】 ▸ (B) 정답 — 단일 목적지 주소 ▸ /32 프리픽스 = 모든 비트가 네트워크 ▸ 정확히 하나의 IP 주소만 지정 ▸ 특정 호스트로의 직접 라우팅 【오답 체크】 (A) 10.0.1.0/24 — 전체 서브넷 (256개 호스트). /32는 1개만. (60~100자) (C) 소스 주소 — 라우팅 테이블은 목적지 기반. 소스와 무관. (60~100자) (D) 10.0.0.0/16 — 전체 네트워크. /32는 단일 호스트. (60~100자) 【시험 포인트】 ▸ /32 = 호스트 라우트 ▸ /31 = 포인트-투-포인트 (2개 호스트) ▸ /24 = C클래스 네트워크 (256개 호스트) ▸ 라우팅 최적화 = 호스트 라우트 필요 시 /32 사용

해설

【핵심 용어】 ▸ Packet Mode — 개별 패킷 처리 ▸ Flow-based Mode — 세션 기반 추적 ▸ 흐름 모듈 — 상태 유지 메커니즘 【정답 포인트】 ▸ (C) 정답 — 패킷 모드는 흐름 모듈을 우회 ▸ 패킷 모드 = 각 패킷 독립 처리 ▸ 상태 추적(Flow State) 없음 ▸ 고급 기능 불필요한 경우 효율성 높음 【오답 체크】 (A) 세션 기반 처리 — 반대. 패킷 모드는 세션 추적 안 함. (60~100자) (B) 고급 보안 서비스 — Flow-based Mode에서만 작동. (60~100자) (D) 상태 유지 기반 — Flow-based Mode의 기반. (60~100자) 【시험 포인트】 ▸ Packet Mode = 단순, 빠름 ▸ Flow-based Mode = 고급 기능, 상태 추적 ▸ 모드 선택 = 성능 vs 기능 트레이드오프 ▸ 실무 = 정책 요구에 따라 모드 결정

해설

【핵심 용어】 ▸ Juniper 인터페이스 명명 — 계층적 구조 ▸ 미디어 타입 — ge, et 등 인터페이스 타입 ▸ 슬롯 번호 — 물리적 위치 식별 【정답 포인트】 ▸ (C) 정답 — 인터페이스 미디어 타입 → 시스템 슬롯 → 라인 카드 슬롯 → 포트 번호 ▸ 예: ge-0/0/0 (Gigabit Ethernet, PIC 0, 포트 0) ▸ 미디어 타입 먼저 → 물리적 위치 순서대로 【오답 체크】 (A) 슬롯 먼저 — Juniper 표준과 맞지 않음. 타입이 접두사. (60~100자) (B) 포트 번호 위치 잘못 — 포트는 마지막. (60~100자) (D) 포트와 슬롯 순서 역함 — 슬롯-카드-포트 순서 필수. (60~100자) 【시험 포인트】 ▸ Juniper = ge-FPC:PIC:port 형식 ▸ FPC = Flexible PIC Concentrator (시스템 슬롯) ▸ PIC = Physical Interface Card (라인 카드) ▸ 명확한 명명법 = 장비 관리 필수

해설

【핵심 용어】 ▸ VPC PrivateLink 엔드포인트 — AWS 서비스 프라이빗 액세스 ▸ DNS 해석 — 서비스 DNS를 프라이빗 IP로 변환 ▸ 엔드포인트 정책 — 통신 허용/거부 제어 【정답 포인트】 ▸ (B) VPC enableDnsSupport = True 확인 → AWS 서비스 DNS를 프라이빗 IP로 변환 ▸ 각 VPC 엔드포인트 DNS 지원 활성화 필수 ▸ (C) 엔드포인트 정책 검증 → 기본값 deny-all, 명시적 Allow 설정 필요 ▸ 라우팅 추가 불필요 (DNS 해석으로 작동) 【오답 체크】 (A) 라우트 테이블 경로 추가 — 불필요. PrivateLink는 DNS 기반. 라우팅 불필요. (60~100자) (D) Route 53 공개 호스팅 존 — 공개 인터넷 경로. 역효과. VPC 엔드포인트 DNS 사용. (60~100자) (E) Route 53 프라이빗 호스팅 존 — 불필요. VPC 엔드포인트 기본 DNS 지원으로 충분. (60~100자) 【시험 포인트】 ▸ PrivateLink DNS = enableDnsSupport(VPC) + 엔드포인트 DNS 활성화 ▸ 엔드포인트 정책 = 명시적 Allow (deny-all 기본값) ▸ 라우팅 테이블 = 불필요 (DNS 해석이 핵심) ▸ Route 53 호스팅 존 = 불필요한 추가 구성

해설

【핵심 용어】 ▸ BGP Longest Prefix Match — 더 구체적인(긴) 접두사를 우선하는 경로 선택 메커니즘 ▸ 접두사 집계(Aggregation) — 여러 CIDR을 상위 범위로 요약(예: /16 상위 15개 VPC /20) ▸ Transit VIF — Direct Connect Gateway와 Transit Gateway 간 연결 【정답 포인트】 ▸ 로컬 리전 VPC는 구체적인 /20 CIDR 광고 → longest prefix match로 로컬 Direct Connect 선호 (B) ▸ 원격 리전은 집계된 경로만 광고 → 재해복구 시 WAN을 통해 원격 Direct Connect 도달 가능 ▸ BGP 원리로 자동 페일오버 달성(로컬 연결 장애 시 WAN 경로 사용) 【오답 체크】 (A) 집계 경로만 광고 — 로컬 최적화 불가. 모든 트래픽이 가장 가까운 경로를 보장하지 못함 (C) 모든 특정 VPC CIDR(30개) 광고 — 경로 테이블 폭발, 경로 경합, 복잡도 증가 (D) BGP 커뮤니티 — 추가 설정 필요. prefix 전략이 더 효율적(자동 페일오버) 【시험 포인트】 ▸ 다지역 경로 최적화 → 로컬 구체적(최장매칭) + 원격 집계(페일오버) 조합 ▸ 함정: (C) 는 15개 VPC를 모두 광고하면 경로 복잡도 폭증, 운영 비효율

해설

【핵심 용어】 ▸ AWS Firewall Manager — Organizations 단위 중앙 집중식 방화벽 정책 관리 ▸ AWS Config — 리소스 규정 준수 모니터링(Firewall Manager의 필수 종속성) ▸ Firewall Manager 관리자 계정 — 조직의 다른 계정 firewall 정책을 관리하는 중앙 역할 【정답 포인트】 ▸ 모든 계정 조직 가입 (B) → Firewall Manager가 관할할 수 있는 범위 확대 ▸ 관리자 계정 지정 (C) → 중앙에서 firewall 정책 배포 및 관리 ▸ 모든 계정의 모든 리전에서 AWS Config (E) → 규정 준수 모니터링, 정책 적용 검증 【오답 체크】 (A) 관리자 계정만 가입 — Firewall Manager가 다른 계정을 접근할 수 없음. 모든 계정 필요 (D) 자식 계정 설정 — Firewall Manager 용어가 아님. 조직 OUs 또는 계정 기반 구조 사용 (F) 관리 계정에만 Config — 불충분. 관할 계정(member accounts)의 리소스 모니터링 불가 【시험 포인트】 ▸ Firewall Manager 구성 → 모든 계정 + 관리자 지정 + AWS Config 전역 활성화 ▸ 함정: Config는 관리 계정만으로는 부족. 모든 리소스가 있는 계정 + 리전에서 필수

해설

【핵심 용어】 ▸ AWS 관리형 접두사 목록 — AWS 서비스 IP 범위를 자동 관리(예: CloudFront IP) ▸ 보안 그룹(Layer 4) — ALB 인바운드 필터, AWS 관리 접두사 목록 지원 ▸ 네트워크 ACL(Layer 3-4) — 서브넷 레벨 필터, 수동 관리 필요 【정답 포인트】 ▸ 보안 그룹 + CloudFront 접두사 목록 (A) → 네트워크 계층, 자동 유지보수 ▸ CloudFront IP 범위 변경 시 AWS가 접두사 목록 자동 업데이트 ▸ 운영 오버헤드 없음 — 수동 IP 관리 불필요 【오답 체크】 (B) 네트워크 ACL — 기술적으로 작동하지만, 보안 그룹보다 복잡하고 권장되지 않음 (C) HTTP 헤더 검증 — 애플리케이션 계층. 문제는 "네트워크 계층" 구현 명시 (D) AWS WAF + Lambda — 애플리케이션 계층(L7). Lambda 수동 관리로 운영 비효율 【시험 포인트】 ▸ 네트워크 계층 필터링 → 보안 그룹(권장) 또는 네트워크 ACL ▸ 함정: 자동 유지보수 가능한 AWS 관리형 접두사 목록 선택이 "운영 효율적"의 핵심

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — Organizations 레벨 API 호출 제어(preventive) ▸ AWS Config — VPC 규정 준수 모니터링(reactive, 사후 감지) ▸ Ipv4IpamPoolId 컨텍스트 키 — CreateVpc/AssociateVpcCidrBlock의 CIDR 출처 검증 【정답 포인트】 ▸ SCP로 CreateVpc/AssociateVpcCidrBlock 호출 자체를 제한 (B) ▸ Ipv4IpamPoolId = 조직의 IPAM 풀 ID 조건 추가 ▸ 정책 레벨 차단 → 우회 불가능, 사전 예방(preventive control) 【오답 체크】 (A) AWS Config + 규칙 위반 감지 — 이미 생성된 VPC 발견 후 삭제(reactive) (C) Lambda 정기 호출 — 사후 감시, 운영 비용 증가, 삭제 오류 위험 (D) EventBridge + CloudTrail 감시 — 이벤트 발생 후 삭제(reactive), 데이터 손실 가능성 【시험 포인트】 ▸ VPC 생성 제약 → 사전(preventive) vs 사후(reactive) 제어 비교 ▸ 함정: Config/Lambda는 "사후 삭제" 방식으로 데이터 손실·운영 비효율. SCP는 "사전 차단"으로 안전

해설

【핵심 용어】 ▸ AWS PrivateLink — 프라이빗하게 SaaS 또는 AWS 서비스 접근 가능한 VPC 엔드포인트 ▸ VPC 엔드포인트 서비스 — PrivateLink 기반 서비스 제공자(예: 파트너 SaaS) ▸ 보안 그룹 — 엔드포인트 서비스의 백엔드 네트워크 인터페이스(ENI) 수신 허용 【정답 포인트】 ▸ VPC 엔드포인트 서비스 생성(제공자) → 서비스 이름 노출 ▸ 소비자 VPC에서 엔드포인트 생성 → 프라이빗하게 접근 ▸ 서비스 보안 그룹이 엔드포인트 traffic 허용해야 통신 가능 【오답 체크】 (A) 로드 밸런서 직접 노출 — PrivateLink 아님. 공인 인터넷 경로 또는 VPN 필요 (B) VPC 피어링 — 공인 인터넷 우회하지만, PrivateLink보다 관리 복잡 (D) S3 게이트웨이 엔드포인트 — S3용. 외부 서비스 노출에는 부적합 【시험 포인트】 ▸ PrivateLink 2가지 구성 → 제공자(서비스) + 소비자(엔드포인트) ▸ 함정: 제공자 쪽 보안 그룹이 모든 규칙의 기본. 거기가 먼저 차단되면 통신 불가

해설

【핵심 용어】 ▸ Direct Connect 연결 — AWS로의 전용 네트워크 회선(공인 인터넷 우회) ▸ VIF(Virtual Interface) — Direct Connect 위의 VLAN 기반 논리적 연결 ▸ Private VIF — VPC로의 프라이빗 연결 ▸ Transit VIF — Transit Gateway로의 연결(여러 VPC 지원) 【정답 포인트】 ▸ 온프레미스와 여러 VPC 연결 → Transit VIF(Transit Gateway 경유) ▸ Direct Connect Gateway — 리전별 중앙 진입점 ▸ Transit Gateway 피어링 — 리전 간 VPC 통신 【오답 체크】 (A) Private VIF만 — 1 VPC당 1 VIF. 15 VPC = 15 VIF 관리 복잡 (B) VGW(Virtual Private Gateway) + VPN — 성능 낮음, 공인 인터넷 경로 (D) AWS PrivateLink — 단방향 서비스 노출. 양방향 멀티 VPC 연결 부적합 【시험 포인트】 ▸ 다중 VPC 및 리전 → Transit VIF + Transit Gateway 조합 ▸ 함정: Private VIF는 VPC당 1개씩 필요하므로 15 VPC = 15 VIF 관리 번거로움

해설

【핵심 용어】 ▸ CloudFront Origin Shield — CloudFront와 Origin 사이의 추가 캐시 레이어 ▸ Origin 성능 — 반복되는 요청 시 Shield 캐시로 Origin 부하 감소 ▸ Cost — Origin Shield 활성화 시 추가 비용(request, data transfer) 【정답 포인트】 ▸ Origin Shield = 중간 캐시 레이어 → Origin 부하 감소, 캐시 히트율 증가 ▸ 반복 요청이 많을수록 효과적(예: 핫 콘텐츠) ▸ 비용 vs 이득 트레이드오프 【오답 체크】 (A) Origin Shield만으로는 Latency 보장 불가 — 캐시 미스 시 Origin으로 가야 함 (B) CloudFront 엣지 로케이션 추가 — 이미 많음. 문제는 Origin 부하 감소 (D) Origin 서버 스케일링 — 비용 많음. Shield로 먼저 부하 감소 시도 【시험 포인트】 ▸ 반복 콘텐츠 요청 최적화 → Origin Shield 활성화(캐시 레이어 추가) ▸ 함정: Shield는 모든 사용 케이스에 필요 X. 반복 요청이 많을 때만 효과적

해설

【핵심 용어】 ▸ Global Accelerator — 고정 IP 2개로 AWS 엣지 로케이션 경유 글로벌 라우팅 ▸ 엣지 로케이션 — Global Accelerator의 진입점(anycast IP) ▸ Origin — 실제 애플리케이션(ALB, NLB, EC2, Elastic IP) 【정답 포인트】 ▸ 글로벌 사용자 → 가장 가까운 엣지 로케이션 자동 라우팅 ▸ 고정 IP 2개 → DNS 변경 없음(IP 화이트리스팅 가능) ▸ TCP/UDP 모두 지원(CloudFront는 HTTP/HTTPS만) 【오답 체크】 (A) CloudFront — HTTP/HTTPS만. TCP/UDP 프로토콜 지원 불가 (B) Route 53 지리 기반 라우팅 — DNS 기반. IP 화이트리스팅 불가(DNS 변경) (D) VPN/Direct Connect — 글로벌 사용자 대상 부적합 【시험 포인트】 ▸ 글로벌 + TCP/UDP + 고정 IP → Global Accelerator 조합 ▸ 함정: CloudFront는 HTTP/HTTPS만. 다른 프로토콜은 Global Accelerator 또는 Route 53

해설

【핵심 용어】 ▸ AWS Outposts — 온프레미스에 AWS 인프라 배포(AWS 관리) ▸ AWS Local Zones — 대도시에 위치한 AWS 저지연 엣지(3자리 리전 코드) ▸ Edge locations — CloudFront 캐시 엣지(용량 제한적) 【정답 포인트】 ▸ 온프레미스 데이터센터 환경 → AWS Outposts 선택(완전 제어 가능) ▸ Outposts는 AWS 관리형 하드웨어 + 소프트웨어 통합 제공 ▸ VPC 확장, EC2/RDS 실행 가능 【오답 체크】 (A) Local Zones — 온프레미스 아님. 도시 엣지 위치(3자리 지역 코드) (B) Edge locations — CloudFront 캐시 전용. 컴퓨팅 환경 부족 (D) S3 Transfer Acceleration — 콘텐츠 전송 가속만. 온프레미스 인프라 배포 불가 【시험 포인트】 ▸ 온프레미스 AWS 인프라 배포 → AWS Outposts 유일한 선택지 ▸ 함정: Local Zones과 Outposts 헷갈림. Local Zones는 "지역"이지 온프레미스 아님