정답 · 해설

해설

【핵심 용어】 ▸ FSx for NetApp ONTAP — NFS+SMB 동시 지원 ▸ 코드 변경 없음 — 파일시스템 마이그레이션만 ▸ 데이터 중복 제거 — 단일 스토리지 (Linux/Windows 공유) 【정답 포인트】 ▸ NetApp ONTAP = NFS(Linux)+SMB(Windows) 양쪽 프로토콜 지원 ▸ 5분 주기 데이터 공유 → 파일시스템 레벨 동기화 ▸ EC2는 변경 최소, 애플리케이션 코드 유지 【오답 체크】 (A) Lambda+S3 = 5분 주기 지연 불가, 배치 처리용 (B) ECS+FSx Gateway = Gateway는 온프레미스 용도 (C) SQS = 메시지 큐, 파일 공유 아님 【시험 포인트】 패턴: 혼합OS+파일공유+코드변경X → NetApp ONTAP 다중프로토콜

해설

【핵심 용어】 ▸ API Gateway + Lambda — 서버리스 백엔드 ▸ SES — 이메일 전송 ▸ 매월 100회 미만 — 요청 거의 없음, 고정 비용 불필요 【정답 포인트】 ▸ Lambda = 요청 기반 비용 (100/월 = 거의 무료) ▸ API Gateway = REST 엔드포인트 ▸ SES = 이메일 발송 ▸ S3 + Serverless = 최저 비용 【오답 체크】 (A) ECS = 컨테이너 관리 오버헤드, 최소 비용 (C) Lightsail = 월정액 ($3.5~), 100요청 대비 낭비 (D) EC2 t2.micro = 월 $10~, 연 $120+ 낭비 【시험 포인트】 패턴: 저트래픽+동적+최소비용 → Lambda+API Gateway 서버리스

해설

【핵심 용어】 ▸ CloudFront 캐시 무효화(Invalidation) — 배포된 콘텐츠의 캐시된 버전을 즉시 삭제하여 최신 버전 제공 ▸ CI/CD 파이프라인 정상 — S3 배포는 검증됨, 웹사이트 미반영 원인은 CloudFront 캐시 ▸ 엣지 로케이션 — 최종 사용자에게 캐시된 이전 콘텐츠 제공 【정답 포인트】 ▸ 파이프라인 정상 작동 → S3 콘텐츠는 최신 상태 ▸ 웹사이트 미반영 → CloudFront가 이전 버전 서빙 중 ▸ 캐시 무효화로 CloudFront가 S3에서 최신 콘텐츠 재다운로드 ▸ 다음 요청부터 최신 버전 제공 【오답 체크】 (A) ALB는 로드밸런싱 기능만 제공, 캐시 문제 해결 불가 (B) ElastiCache는 데이터베이스 캐싱용, CDN 캐시와 무관 (D) SSL 인증서는 보안 설정, 콘텐츠 업데이트와 무관 - 엔드 유저가 최신 콘텐츠 보지 못하는 증상 ▸ 원인 분석: 파이프라인은 정상, 캐시 검증 필요 【시험 포인트】 CloudFront 배포 후 콘텐츠 미반영 → 캐시 무효화 배포 자동화 시스템 + CDN → 캐시 관리 필수

해설

【핵심 용어】 ▸ Windows File Server — SMB 프로토콜 기반, Windows 애플리케이션과 네이티브 호환 ▸ SQL Server 특정 기능 — 라이선싱, Native Tools, 백업 유틸리티 완전 지원 ▸ FSx for Windows File Server — AWS 관리형 SMB 공유 스토리지 【정답 포인트】 ▸ 세 계층 모두 EC2에서 운영 → SQL Server 라이선싱/기능 완전 제어 ▸ FSx for Windows File Server → Windows 네이티브 파일 공유, SMB/NFS 지원 ▸ Windows 애플리케이션과 완벽한 호환성 ▸ Multi-AZ, 자동 백업 지원 【오답 체크】 (A) FSx File Gateway는 온프레미스 환경용, AWS 내부 구조에 부적합 (C) EFS는 Linux/Unix용, Windows에 최적화 아님, RDS는 특정 기능 손실 (D) EBS는 블록 스토리지, 다중 계층 네트워크 파일 공유 설계 불가 【시험 포인트】 Windows 애플리케이션 → Windows 기반 스토리지 필수 SQL Server 특정 기능 필요 → EC2 호스팅 필수

해설

【핵심 용어】 ▸ IAM 역할(Execution Role) — 서비스가 임시 자격증명으로 작동 ▸ 최소 권한 원칙(Principle of Least Privilege) — 필요한 것만 부여 ▸ 자격증명 비노출 — 코드에 키 저장 금지 【정답 포인트】 ▸ Lambda 실행 역할에 정책 부여 → 임시 자격증명 자동 관리 ▸ 특정 S3 버킷만 권한 → 보안 최강화, 자격증명 노출 없음 ▸ AWS에서 임시 토큰 자동 발급 및 순환 ▸ CloudTrail에서 감사 추적 가능 【오답 체크】 (A) 버킷 정책은 리소스 기반, Lambda 역할 부여 더 효율적 (C) 코드에 액세스 키 내장 → 극도로 위험, 노출 가능성 높음, 회전 어려움 (D) 모든 S3 버킷 권한 → 최소 권한 위반, 과도한 권한 부여 - 임시 자격증명은 15분~1시간 자동 갱신 ▸ 감사 추적: 누가 어떤 리소스 접근했는지 기록 정책 구조: Effect(Allow) + Action(s3:GetObject) + Resource(arn:aws:s3:::bucket/*) ▸ 버킷 정책과의 차이: 역할은 Principal 명시 필요 없음 ▸ 리소스 기반 정책: 버킷 소유자가 제어 【시험 포인트】 AWS 서비스 + 권한 → IAM 역할이 표준 방식 가장 안전한 방식 → 역할 기반 + 특정 리소스 정책

해설

【핵심 용어】 ▸ 스팟 인스턴스 — AWS 미사용 용량 활용, 온디맨드의 70~90% 할인 ▸ 장기 약정 없음 — 예약 인스턴스(1년/3년 약정) 제외 요구사항 ▸ Auto Scaling 혼합 — 온디맨드로 최소 용량, 스팟으로 추가 용량 【정답 포인트】 ▸ 스팟 + 온디맨드 혼합 → 최고 비용 효율, 유연성 유지 ▸ Auto Scaling으로 스팟 인스턴스 중단 시 온디맨드로 자동 보충 ▸ 가용성 목표(SLA) 충족 + 비용 최소화 ▸ 약정 기간 없이 언제든 조정 가능 【오답 체크】 (A) 전용 인스턴스는 격리만, 비용 절감 효과 없음 (B) 온디맨드 전용 → 최고 비용, 절감 기회 상실 (D) 예약 인스턴스는 1~3년 약정 필요, 요구사항 위배 - 비용 구조: 스팟 70~90% 할인 + 온디맨드 안정성 ▸ Auto Scaling 정책: 스팟 부족 시 온디맨드 자동 보충 스팟 인스턴스 비용: 1시간 온디맨드 100원 → 스팟 10~30원 ▸ 가용 영역 분산: Capacity-optimized 배치로 중단 확률 최소화 ▸ 스팟 풀: 72가지 조합(인스턴스 타입 × AZ) 자동 선택 【시험 포인트】 비용 최적화 + 약정 불가 → 스팟 인스턴스 활용 Auto Scaling + 스팟 → 혼합 구매 전략이 정답

해설

【핵심 용어】 ▸ 서명된 URL — CloudFront 특정 객체, URL 변경 가능한 클라이언트용 ▸ 서명된 쿠키 — CloudFront 다중 객체, 하드코딩 URL 유지 가능 ▸ CloudFront Origin Access Control — S3 보호 기능 【정답 포인트】 ▸ (B) 서명된 URL → URL 변경 가능 사용자 그룹용, 동적 접근 ▸ (A) 서명된 쿠키 → 하드코딩 URL 유지 사용자 그룹용, 쿠키 미지원 우회 ▸ 두 그룹 모두 수용 가능한 전략 ▸ 시간 제한 서명으로 추가 보안 확보 【오답 체크】 (C) AppSync는 GraphQL 서비스, CloudFront 콘텐츠 보호와 무관 (D) JWT는 애플리케이션 토큰, CloudFront 서명 메커니즘 아님 (E) Secrets Manager는 자격증명 관리, 콘텐츠 접근 제어 아님 - 쿠키: 여러 요청에 걸쳐 유지, HTTP 헤더 자동 포함 ▸ URL: 각 요청마다 생성, 시간 제한(5~20분) 가능 【시험 포인트】 CloudFront 콘텐츠 보호 → Signed URL/Cookie 조합 다양한 클라이언트 지원 → 두 메커니즘 병행(AB 정답)

해설

【핵심 용어】 ▸ 실시간 스트리밍 변환 — Kinesis/MSK 수집 → 변환 엔진 → S3 적재 ▸ SQL 쿼리 — Athena는 S3 데이터 SQL 조회, RDS는 S3 직접 쿼리 불가 ▸ Kinesis Data Analytics — Kinesis용 변환, MSK는 미지원 ▸ AWS Glue — MSK, Kinesis 모두 지원 【정답 포인트】 ▸ (A) Kinesis 파이프라인: KDS 수집 → KDA 변환 → Firehose S3 적재 → Athena 조회 ▸ (B) MSK 파이프라인: MSK 수집 → Glue 변환 → S3 적재 → Athena 조회 ▸ 두 파이프라인 모두 요구사항 충족 ▸ Athena로 S3 데이터 SQL 쿼리 가능 【오답 체크】 (C) DMS는 DB 마이그레이션용, 다중 소스 스트림 처리 아님 (D) MSK + KDA 혼합 불가, RDS는 S3 직접 쿼리 불가 (E) Kinesis + Glue 혼합, RDS는 S3 데이터 쿼리 불가 【시험 포인트】 실시간 스트리밍 데이터 → Kinesis/MSK 선택 S3 데이터 SQL 쿼리 → Athena 필수, RDS 아님

해설

【핵심 용어】 ▸ 게이트웨이 VPC 엔드포인트(S3/DynamoDB용) — VPC 내부에서 AWS 서비스 접근, 인터넷 우회 ▸ 라우팅 테이블 수정 — S3 트래픽을 엔드포인트로 자동 라우팅 ▸ 프라이빗 연결 — NAT 게이트웨이/IGW 사용 안 함 【정답 포인트】 ▸ 게이트웨이 엔드포인트 설정 → VPC 내 프라이빗 연결 ▸ EC2에서 S3 액세스 시 인터넷 게이트웨이 우회 ▸ 라우팅 테이블 자동 업데이트 ▸ 추가 비용 없음, 높은 가용성 【오답 체크】 (A) Route 53은 DNS 호스팅, 접근 제어 기능 없음 (C) NAT 게이트웨이 → 인터넷 게이트웨이를 통해 인터넷 경유, 요구사항 위배 (D) Site-to-Site VPN은 온프레미스 연결용, 같은 계정 S3 접근에 불필요 - 라우팅: EC2에서 S3 주소 검색 → 엔드포인트로 자동 라우팅 ▸ 비용: 추가 요금 없음, NAT 게이트웨이보다 저렴 【시험 포인트】 VPC 내 S3 접근 + 인터넷 우회 → Gateway VPC Endpoint S3, DynamoDB는 게이트웨이 엔드포인트 지원, 다른 서비스는 Interface 엔드포인트

해설

【핵심 용어】 ▸ S3 Object Lambda — 애플리케이션 코드 수정 없이 S3 객체 동적 변환 ▸ 최소 운영 오버헤드 — 사전 데이터 복제/처리 불필요 ▸ 요청 시점 필터링 — 각 애플리케이션별 맞춤형 응답 【정답 포인트】 ▸ S3에 단일 원본 데이터 저장 ▸ Object Lambda로 요청 애플리케이션별 PII 제거 로직 실행 ▸ 응답만 필터링, 저장소 중복 및 수동 처리 제거 ▸ 운영 관리 최소화, 비용 효율적 【오답 체크】 (A) 프록시 계층 → 별도 애플리케이션 개발/운영 필요, 복잡도 증가 (C) (D) 3개 버킷/테이블 → 데이터 중복, ETL 파이프라인 운영 오버헤드 증가 - Lambda로 요청 시점에 동적으로 PII 필터링 ▸ 저장소 이중화 제거로 운영 복잡도 감소 S3 Object Lambda 가격: 요청당 비용(GetObject 변환) ▸ 메타데이터: 원본 객체는 변경 없음, 응답만 필터링 ▸ 성능: Lambda 실행 시간에 따른 P99 레이턴시 고려 【시험 포인트】 요청 시점 데이터 변환 → S3 Object Lambda 최소 운영 오버헤드 → 기존 애플리케이션 코드 수정 없음

해설

【핵심 용어】 ▸ VPC 피어링 — 중복되지 않는 CIDR 블록 필수 조건 ▸ /32 vs /24 — /32는 호스트 1개, /24는 256개 주소 ▸ 최소 CIDR 블록 — VPC 실제 운영에 필요한 최소 크기 【정답 포인트】 ▸ 개발 VPC: 192.168.0.0/24 (범위: 192.168.0.0~192.168.0.255) ▸ 새 VPC CIDR은 겹치지 않아야 함 ▸ 10.0.1.0/24 → 10.0.1.0~10.0.1.255 (비겹침, 최소 /24) ▸ /32는 호스트 1개만 지원, 실제 VPC 운영 불가능 【오답 체크】 (A) 10.0.1.0/32 → 호스트 1개만 지원, 실제 VPC용으로 부족 (B) 192.168.0.0/24 → 개발 VPC와 중복, 피어링 불가능 (C) 192.168.1.0/32 → 호스트 1개, 게다가 192.168.x.x 범위 사용 - /32는 호스트 마스크, VPC로 사용하려면 최소 /28 ▸ VPC 피어링 테스트: 라우팅 테이블 확인 필수 【시험 포인트】 VPC 피어링 → CIDR 겹치기 금지 실용적 최소값 → /24 (256 주소) CIDR 겹침 판단 능력 필수

해설

【핵심 용어】 ▸ Auto Scaling 대상 추적(Target Tracking) — 목표 지표 자동 유지 ▸ 최소/원하는/최대 인스턴스 — 비용 최적화와 성능 균형 ▸ ASGAverageCPUUtilization — Auto Scaling 그룹 평균 CPU 【정답 포인트】 ▸ Auto Scaling 그룹 생성 → ALB 기존 리소스 활용 ▸ 대상 추적 정책(목표 CPU 50%) → 급증 시 자동 확장, 저사용시 축소 ▸ Min 2/Desired 3/Max 6 → 비용 최적화, 성능 보장 ▸ CPU 65% 급증 시 → 6개 인스턴스까지 자동 확장 【오답 체크】 (A) 수동 Lambda 해제 → 확장 자동화 아님, 복잡하고 비효율적 (C) 정책 없이 고정 크기 → 급증 대응 불가, 비용 절감 기회 상실 (D) 수동 SNS 알림 → 운영자 개입, 자동화 아님, 반응 시간 지연 - 저사용시 최소 2개만 유지(비용 최적화) ▸ 급증시 최대 6개까지 확장(성능 확보) 【시험 포인트】 자동 확장 + 급증 대응 → Target Tracking Policy 필수 비용 최적화 → Auto Scaling 그룹의 Min/Max 설정

해설

【핵심 용어】 ▸ 다중 AZ(RDS) — Primary-Standby 동기 복제, 자동 장애조치 ▸ 서브넷 — 각 AZ별 1개씩만 존재(서브넷은 단일 AZ 내에서만 존재) ▸ Auto Scaling 분산 배포 — 여러 AZ에서 자동으로 균형 유지 【정답 포인트】 ▸ EC2: 각 AZ 서브넷에서 Auto Scaling → 분산 배포 ▸ RDS: Multi-AZ 활성화 → Primary AZ 다운 시 자동 장애조치 ▸ 아키텍처 고가용성 완성 ▸ 데이터 손실 없음, 자동 복구 【오답 체크】 (A) DB 각 네트워크 연결 → 수동 장애조치, Multi-AZ 이점 없음 (B) 서브넷이 "2개 AZ에 걸쳐" → AWS VPC 설계 위반 (D) 서브넷 설계 오류 + DB 단순 연결 → 가용성 보장 불충분 - 서브넷이 AZ 경계를 넘을 수 없음(AWS 제약사항) ▸ Multi-AZ RDS: Primary 다운 시 Standby로 자동 승격(RPO=0) Multi-AZ 구성: Primary(읽기/쓰기) + Standby(읽기전용 대기) ▸ 동기 복제: 쓰기 ACK 전 Standby에 복제(데이터 손실 0) ▸ 자동 네임: DNS 자동 변경으로 애플리케이션 코드 수정 불필요 【시험 포인트】 고가용성 RDS → Multi-AZ 필수 서브넷은 단일 AZ 속함, 각 AZ당 1개씩 구성

해설

【핵심 용어】 ▸ FSx for Lustre — HPC용 고성능 병렬 파일시스템, <1ms 지연시간 ▸ 영구 SSD — 6GBps 처리량 충족, HDD는 처리량 저하 ▸ S3 연동 — 데이터 로드/언로드 자동화 【정답 포인트】 ▸ 1ms 이하 대기시간 + 6GBps 처리량 → Lustre SSD만 충족 ▸ S3와 연동 → 데이터 로드/언로드 자동화 ▸ 수백 EC2 병렬 접근 → Lustre 높은 동시성 지원 ▸ POSIX 호환 파일시스템 → Linux 애플리케이션 완벽 호환 【오답 체크】 (A) FSx ONTAP → NFS, 지연시간/처리량 요구사항 미달 (C) Lustre HDD → SSD 대비 처리량 저하, 6GBps 미충족 (D) ONTAP (A와 동일) → HPC 성능 아님 Lustre 용량 확장: 초기 용량 정하고 자동 확장(최대 500GB+) ▸ 비용 구조: 용량(GB/월) + 처리량(MB/s/월) 조합 요금 ▸ 임시 스토리지: 계산 완료 후 S3로 내보내고 삭제 【시험 포인트】 HPC/고성능 컴퓨팅 → FSx for Lustre <1ms 지연 + 높은 처리량 → Lustre SSD 선택 필수

해설

【핵심 용어】 ▸ 예약 인스턴스 — 1~3년 약정, 온디맨드 대비 72% 할인 ▸ 24/7 지속 실행 → 예약 인스턴스 최적화 ▸ Aurora — MySQL/PostgreSQL 호환, RDS 보다 비용 효율적 【정답 포인트】 ▸ 지속 운영 애플리케이션 → EC2 예약 인스턴스 ▸ 스토리지 계속 증가 → Aurora 자동 확장, RDS는 용량 사전 결정 필요 ▸ Aurora 예약 인스턴스 → 비용 최적화 ▸ 예약 인스턴스로 고정 비용 절감, Aurora로 가변 비용 절감 【오답 체크】 (A) Spot 인스턴스는 중단 가능, 24/7 미션크리티컬 부적합 (B) RDS 온디맨드 → 예약 대비 비용 높음 (D) EC2 온디맨드 → 예약 대비 비용 높음 - 예약 인스턴스: 선결제로 최대 할인(1년 33%, 3년 60%) ▸ Aurora: 스토리지 자동 확장으로 용량 계획 불필요 Aurora 비용: 온디맨드 대비 40% 저렴, 스토리지 자동 청구 ▸ Read Replica: 최대 15개 가능, 리드 전용 자동 확장 ▸ 백업: 35일 보존, PITR(Point-in-Time Restore) 지원 【시험 포인트】 24/7 지속 운영 → 예약 인스턴스 스토리지 증가 → Aurora(자동 확장) vs RDS(용량 계획)

해설

【핵심 용어】 ▸ DataSync — 네트워크 기반 데이터 전송, 대역폭 제어 기능(Throttling) ▸ 대역폭 조절 → 다른 부서 영향 최소화 ▸ 5일 기간 → 30TB 필요 처리량 가능 【정답 포인트】 ▸ DataSync는 대역폭 제어(throttling) 지원 ▸ Windows File Server → FSx for Windows 마이그레이션 최적화 ▸ 네트워크 기반 → 5일 내 가능 (30TB/5일 = 6TB/일 필요) ▸ 자동 재시도, 데이터 검증 기능 【오답 체크】 (A) Snowcone → 물리 기기, 5일 배송 시간 포함, 비현실적 (B) FSx File Gateway → 온프레미스 캐싱용, 마이그레이션 도구 아님 (D) Transfer Family → SFTP/FTP 전송, 대역폭 제어 기능 약함 - 일반 WAN: 대역폭 공유로 경쟁(네트워크 혼잡 가능) ▸ DataSync Throttling: 예약 가능한 대역폭량 설정(Mbps) 【시험 포인트】 대역폭 제어 필요 → DataSync만 지원 네트워크 기반 마이그레이션 + 스케줄링 → DataSync 최선

해설

【핵심 용어】 ▸ CloudFront — 글로벌 CDN, 엣지 로케이션 캐싱, 대역폭 비용 절감 ▸ Elastic Transcoder — 비디오 형식 변환, 파일 크기 최적화 ▸ 운영 오버헤드 최소화 — 관리형 서비스 【정답 포인트】 ▸ (A) CloudFront → 원시 비디오 배포 시간 단축, 글로벌 캐싱 ▸ (C) Transcoder → 원시 형식 → 모바일 최적화 형식 변환 ▸ 조합: 작은 파일 + CDN 배포 = 빠른 스트리밍 ▸ 자동 확장, 관리 부하 최소화 【오답 체크】 (B) DataSync → S3 간 복제, 최종 사용자 성능 개선 아님 (D) Local Region EC2 → 운영 오버헤드 높음, CloudFront 더 효율적 (E) EC2 변환 → CloudFront 캐싱 없음, 네트워크 지연 해결 불가 - CloudFront: 200+ 엣지 로케이션에서 캐싱 ▸ Transcoder: 비디오 해상도/비트레이트 자동 최적화 【시험 포인트】 모바일 스트리밍 + 버퍼링 → CDN(CloudFront) 필수 파일 크기 문제 → 형식 변환(Transcoder) 운영 오버헤드 최소화 → 관리형 서비스 조합

해설

【핵심 용어】 ▸ Application Auto Scaling — ECS/RDS용, 목표 추적 정책 ▸ Fargate → EC2 관리 불필요, 태스크 수 조정 ▸ 목표 추적 정책 — 목표 메트릭 자동 유지 【정답 포인트】 ▸ Fargate ECS → Application Auto Scaling(EC2 Auto Scaling 아님) ▸ 대상 추적 정책 → CPU/메모리 기반 자동 조정 ▸ 비용 절감 + 성능 확보 동시 달성 ▸ 메트릭 목표 자동 유지, 운영자 개입 최소화 【오답 체크】 (A) EC2 Auto Scaling → EC2 인스턴스용, ECS 작업 직접 조정 불가 (B) Lambda 함수 → 수동 작업, 자동 조정 아님 (C) EC2 Auto Scaling + Simple Policy → ECS Fargate에 부적합 - ECS 태스크: 컨테이너 단위 스케일링(인스턴스가 아님) ▸ Application Auto Scaling이 ECS 태스크 개수 조정 【시험 포인트】 Fargate 자동 확장 → Application Auto Scaling 목표 추적 정책 → 비용 최적화 + 성능 유지

해설

【핵심 용어】 ▸ DataSync — NFS 지원, 리전 간 데이터 동기화 ▸ 정기적 양방향 전송 → 자동 스케줄링 가능 ▸ 최소 운영 오버헤드 → 관리형 서비스 【정답 포인트】 ▸ DataSync는 NFS 파일시스템 지원 ▸ 리전 간 자동 동기화 설정 가능 ▸ 네트워크 최적화, 대역폭 제어 기능 ▸ 자동 재시도, 데이터 검증 기능 【오답 체크】 (B) Snowball → 일회성 마이그레이션, 정기 동기화 부적합 (C) SFTP 서버 → 운영 오버헤드 높음, 수동 관리 필요 (D) DMS → 데이터베이스 마이그레이션용, 파일시스템 아님 - DataSync 활성화: 리전 간 자동 동기화 스케줄 설정 ▸ RTO/RPO: DataSync 처리량과 스케줄에 따라 결정 DataSync 에이전트: AWS DataSync 온프레미스 설치 또는 AWS 제공 기기 ▸ 검증: 체크섬으로 전송 무결성 자동 확인 ▸ 성능: WAN 대역폭 최대 100Mbps 사용(조절 가능) 【시험 포인트】 정기적 리전 간 데이터 전송 → DataSync NFS 파일시스템 → DataSync 최선

해설

【핵심 용어】 ▸ FSx for Windows File Server — SMB/CIFS 프로토콜 지원, 완전 관리형 Windows 파일 서버 ▸ 공유 스토리지 — 여러 EC2 인스턴스가 동시 접근 가능 【정답 포인트】 ▸ SMB 클라이언트 요구 → FSx Windows 선택 (C) ▸ 완전 관리형 → EC2 Windows 인스턴스 자동 관리는 불가 (B 제외) 【오답 체크】 (A) DataSync는 데이터 복제 도구, 마운트 불가 (B) EC2 자체 관리 필요 → 운영 오버헤드 높음 (D) S3는 SMB 미지원, 객체 스토리지 【시험 포인트】 윈도우 파일 공유 프로토콜 → AWS 관리형 솔루션 → FSx Windows 선택 기준