정답 · 해설

해설

【핵심 용어】 ▸ EFS(Elastic File System) — 여러 EC2 인스턴스가 동시에 마운트 가능한 공유 NFS 파일 시스템 ▸ 자동 확장 — 데이터 추가 시 용량 제약 없이 자동으로 증가 【정답 포인트】 ▸ 다중 AZ 배포 + 여러 인스턴스의 동시 액세스 필요 → EFS 필수 ▸ 증가하는 저장 공간(6개월) → 자동 확장 지원하는 EFS가 적합 ▸ 시간당 분석 + 실시간 데이터 수정 → EFS의 동시성 처리 활용 【오답 체크】 (A) Glacier는 아카이브용 콜드 스토리지이며 시간당 분석 불가능 (B) EBS 볼륨은 단일 EC2 인스턴스 전용이므로 여러 인스턴스 공유 불가 (D) EBS는 기술적으로 다중 인스턴스 공유 지원하지 않음 【시험 포인트】 ▸ 다중 인스턴스 + 공유 스토리지 + 자동 확장 → EFS 패턴 반사 ▸ 함정: EBS는 인스턴스별 전용 스토리지 → 공유 불가능

해설

【핵심 용어】 ▸ RDS 읽기 복제본 — 원본 DB 인스턴스에서 데이터를 복제하는 읽기 전용 복제본 ▸ 읽기 트래픽 분산 — SELECT 쿼리를 복제본으로 분산하여 원본 부하 경감 【정답 포인트】 ▸ DB 쿼리 성능 저하 진단 → 읽기 트래픽 분산 필요 ▸ 읽기 복제본이 SELECT 쿼리 처리 → 원본 DB의 쓰기 성능 향상 ▸ 별도 엔드포인트 제공 → 애플리케이션 변경으로 읽기 분산 구현 【오답 체크】 (A) 다중 AZ 대기 복제본은 페일오버용이지 읽기 분산 기능 없음 (B) Transfer Acceleration은 S3 데이터 전송 최적화이며 DB 쿼리 성능 무관 (D) Kinesis Data Firehose는 스트리밍 데이터 수집용이지 DB 쿼리 처리 안 함 【시험 포인트】 ▸ DB 읽기 성능 저하 → 읽기 복제본으로 분산 기본 패턴 ▸ 함정: 다중 AZ(고가용성)와 읽기 복제본(성능) 목적 혼동 주의

해설

【핵심 용어】 ▸ 교차 계정 액세스 — 다른 AWS 계정의 리소스에 대한 권한 위임 ▸ IAM 역할 신뢰 관계 — 외부 계정이 역할을 맡을 수 있도록 설정하는 권한 부여 메커니즘 【정답 포인트】 ▸ 여러 대행사 계정 + S3 데이터 공유 필요 → 교차 계정 액세스 설정 ▸ 원본 계정에서 각 대행사 계정에 IAM 역할 신뢰 관계 정의 ▸ 역할 기반 권한 → 각 사용자 관리 제거로 운영 오버헤드 최소 【오답 체크】 (A) S3 글로벌 테이블은 리전 간 복제이지 계정 간 공유 메커니즘 아님 (B) 공개 버킷은 보안 위험으로 컴플라이언스 위반 (D) 각 분석가마다 IAM 사용자 생성 → 운영 오버헤드 급증 【시험 포인트】 ▸ 다중 조직 + 데이터 공유 → 교차 계정 역할 기반 권한 패턴 ▸ 함정: 공개 또는 사용자 단위 관리는 보안/운영 모두 열악

해설

【핵심 용어】 ▸ FSx for NetApp ONTAP—NFS/CIFS 프로토콜 모두 지원하는 관리형 파일 시스템 ▸ SnapMirror—NetApp 기술로 동기식/비동기식 데이터 복제 제공 【정답 포인트】 ▸ 재해복구 + 동일 프로토콜 유지 필요 → FSx for NetApp ONTAP 선택 ▸ SnapMirror로 네이티브 데이터 복제 → 프로토콜 변환 없음 ▸ NetApp 기술 지원 → 최소 운영 오버헤드로 복제 구현 【오답 체크】 (A) S3 복제는 프로토콜(NFS/CIFS) 변환 필요로 호환성 감소 (B) AWS Backup 복구는 프로토콜 유지하지 않으므로 NFS/CIFS 요구 미충족 (D) EFS는 NFS만 지원하고 CIFS 미지원으로 혼합 환경 불가 【시험 포인트】 ▸ NetApp FSx 재해복구 → SnapMirror 복제 패턴 필수 ▸ 함정: S3 복제로 프로토콜 보존 불가 → 동일 기술(ONTAP) 필수

해설

【핵심 용어】 ▸ SQS(Simple Queue Service)—메시지 큐로 비동기 처리 및 버퍼링 제공 ▸ 확장성—큐를 통한 처리량 제어로 Lambda 자동 확장 관리 【정답 포인트】 ▸ S3 이벤트 → SNS → SQS 큐로 변환 → Lambda 트리거 ▸ SQS 큐가 이벤트 버퍼링 → 급증 이벤트 대응 및 Lambda 동시 실행 관리 ▸ 확장 가능한 처리 → 큐 길이에 따른 Lambda 자동 스케일링 【오답 체크】 (A) ECS/EKS는 S3 이벤트 직접 대상으로 권장되지 않음 (B) 컨테이너는 스토리지 이벤트 처리에 부적합 (D) AWS SMS는 마이그레이션 서비스이지 메시징 플랫폼 아님 【시험 포인트】 ▸ S3 → SNS → SQS → Lambda 이벤트 처리 체인 구조 ▸ 함정: SNS만으로는 확장성 부족 → SQS 큐 필수

해설

【핵심 용어】 ▸ AWS Lambda—예측 불가능한 트래픽에 자동 확장되는 서버리스 함수 ▸ DynamoDB—키-값 기반 NoSQL로 프로비저닝 없이 자동 스케일링 【정답 포인트】 ▸ 예측 불가능한 트래픽(0~500req/s) → Lambda 자동 확장 필수 ▸ 간단한 키-값 쿼리 + 자동 스케일링 → DynamoDB 최적 ▸ 1GB 미만 데이터 → DynamoDB 온디맨드 모드로 경제적 【오답 체크】 (A) Fargate는 컨테이너이며 초당 0 요청 상태에서 비용 낭비 (D) EC2 Auto Scaling은 인스턴스 시작 시간 길어 급증 대응 지연 (E) Aurora는 1GB 미만 데이터에 오버스펙이며 최소 비용 높음 【시험 포인트】 ▸ 급격한 트래픽 변화 → Lambda + DynamoDB 조합 필수 ▸ 함정: Fargate/EC2의 시작 시간 간과로 오류 → 서버리스 선택 필수

해설

【핵심 용어】 ▸ S3 사전 서명 URL—AWS 자격증명 노출 없이 제한된 시간 동안만 유효한 임시 액세스 링크 ▸ 임직원 확장성—IAM 사용자 생성 제거로 대규모 사용자 관리 【정답 포인트】 ▸ 임직원 다수 + IAM 관리 오버헤드 회피 → 사전 서명 URL 생성 ▸ Lambda 함수에서 URL 생성 → 보안 관리 중앙화 ▸ 시간 제한 URL → 일회성 액세스로 보안성 향상 【오답 체크】 (B) 각 직원마다 IAM 사용자 생성 → 운영 오버헤드 급증 (C) 파일 게이트웨이는 온프레미스 네트워크 연결 필요로 복잡 (D) Transfer Family SFTP는 엔드포인트 관리 오버헤드 증가 【시험 포인트】 ▸ 대량 사용자 + 최소 운영 오버헤드 → 사전 서명 URL 패턴 반복 ▸ 함정: IAM 사용자는 수백 명 규모 스케일링 불가능

해설

【핵심 용어】 ▸ 세션 선호도(스티키 세션)—사용자 세션을 특정 EC2 인스턴스로 고정 ▸ 비활성화 → 각 요청을 라운드로빈으로 균등 분배 【정답 포인트】 ▸ 트래픽 편중으로 한 인스턴스 부하 집중 → 스티키 세션 활성화 확인 ▸ 세션 선호도 비활성화 → 모든 인스턴스에 부하 균등 분배 ▸ 부하 균형 복원 → 지연 시간 감소 【오답 체크】 (B) NLB로 교체해도 스티키 세션 문제 존재하면 미해결 (C) 인스턴스 추가는 근본 원인(편중) 해결 아님 (D) 상태 확인 빈도 조정은 트래픽 편중과 무관 【시험 포인트】 ▸ ALB 트래픽 편중 → 스티키 세션 설정 확인 필수 ▸ 함정: 인스턴스 추가로 임시 완화 가능하지만 근본 원인 미해결

해설

【핵심 용어】 ▸ KMS 키 정책—KMS 키에 대한 권한을 명시적으로 허용하는 리소스 정책 ▸ IAM 역할 정책—Lambda 실행 역할이 수행 가능한 작업 정의 【정답 포인트】 ▸ KMS 암호 해독 권한은 키 정책 + IAM 역할 정책 모두 필요 ▸ (C) KMS 키 정책에 Lambda IAM 역할을 신뢰 주체로 명시 ▸ (E) Lambda 실행 역할에 kms:Decrypt 권한 정책 첨부 【오답 체크】 (A) Lambda 리소스 정책은 KMS 권한 부여 불가 (KMS는 키 정책만 인정) (B) 키 정책에 권한 추가하지만 IAM 정책 필수 (D) IAM 정책만으로는 KMS 키 정책 부재 시 불가 【시험 포인트】 ▸ KMS 권한 = 키 정책 + IAM 역할 정책 2개 모두 필수 ▸ 함정: 리소스 정책으로 KMS 권한 부여 불가 → 키 정책 사용 필수

해설

【핵심 용어】 ▸ Network Load Balancer(NLB)—UDP/TCP 프로토콜 모두 지원 (게임, IoT) ▸ Application Load Balancer(ALB)—HTTP/HTTPS HTTP 기반 트래픽 전용 【정답 포인트】 ▸ UDP 패킷 기반 게임 트래픽 → NLB 필수 ▸ ALB는 HTTP만 지원하므로 UDP 게임 데이터 처리 불가 ▸ Auto Scaling 연동 → NLB로 게임 세션 관리 【오답 체크】 (B) ALB는 HTTP 기반만 지원이므로 UDP 미지원 (C) Route 53 가중치 기반 라우팅은 로드 밸런싱 기능 부족 (D) NAT 포트 포워딩은 복잡하고 확장성 제한 【시험 포인트】 ▸ UDP 기반 트래픽 → NLB 선택 필수 ▸ 함정: ALB는 HTTP 계층 로드 밸런서 → UDP 레이어 4 불가

해설

【핵심 용어】 ▸ Amazon Athena—S3의 파일을 SQL로 직접 분석하는 쿼리 엔진 ▸ 비용 효율—스캔한 데이터량만 청구하는 페이-어-유-스캔 모델 【정답 포인트】 ▸ 매일 수십GB 로그 + 주 1회 온디맨드 분석 → S3 + Athena ▸ 표준 SQL 지원 → 개발자 친화적인 쿼리 작성 ▸ 저장 비용 최소 → S3에 저장하고 필요시만 쿼리 【오답 체크】 (B) RDS는 매일 수십GB 데이터 관리로 인스턴스 비용 높음 (C) OpenSearch는 로그 분석용이지만 지속 비용 및 관리 오버헤드 증가 (D) EMR은 클러스터 유지 비용 증가로 온디맨드 분석에 부적합 【시험 포인트】 ▸ 대용량 로그 + 온디맨드 분석 → S3 + Athena 기본 패턴 ▸ 함정: RDS/OpenSearch는 지속 인프라 비용 발생

해설

【핵심 용어】 ▸ FSx for Lustre—HPC 워크로드용 고성능 병렬 파일 시스템 (<1ms 지연) ▸ S3 연결—처리 완료 후 데이터 자동 S3 export로 워크플로우 효율화 【정답 포인트】 ▸ 수백 개 EC2 병렬 액세스 + <1ms 지연 → Lustre 필수 ▸ 대규모 데이터 분산 처리 → 병렬 파일 시스템 고성능 ▸ 후처리용 S3 연결 → 효율적인 데이터 워크플로우 구성 【오답 체크】 (A) EFS는 1ms 이내 지연 성능 불가능 (일반적으로 10ms 이상) (B) S3 직접 마운트는 성능 극도로 부족 (D) RAM 액세스 관리자는 데이터 공유만 지원이며 파일 시스템 아님 【시험 포인트】 ▸ HPC + 병렬 처리 + <1ms → FSx for Lustre 패턴 필수 ▸ 함정: EFS는 일반 NFS로 HPC 지연 요구사항 미충족

해설

【핵심 용어】 ▸ Global Accelerator—IP 캐싱 문제 해결, 고정 애니캐스트 IP 제공, 상태 확인 기반 자동 장애 조치 ▸ VoIP 실시간 통신—저지연 및 자동 조치 필수 【정답 포인트】 ▸ "IP 주소 캐싱에 의존하지 않고" → Global Accelerator는 고정 IP 제공, DNS 캐싱 우회 ▸ "자동화된 장애 조치" → Health Check + 상태 기반 라우팅으로 밀리초 단위 조치 ▸ "전 세계 사용자" → 애니캐스트 네트워크로 지연 시간 최소화 【오답 체크】 (B) Route 53 geolocation은 지역별 라우팅만 가능, IP 캐싱 문제 해결 못함 (C) CloudFront는 콘텐츠 배포 (HTTP/HTTPS) 중심, 실시간 VoIP 부적합 (D) ALB는 지역 내 로드 밸런싱만 가능, 다중 리전 자동 장애 조치 미지원 【시험 포인트】 ▸ 고정 IP + 자동 장애 조치 → Global Accelerator ▸ "IP 캐싱" 함정 → DNS 기반 솔루션 (Route 53) 제외

해설

【핵심 용어】 ▸ Lustre 퍼시스턴트 파일 시스템—지속적 스토리지, 높은 처리량, 데이터 보호 ▸ Lustre 스크래치 파일 시스템—임시 데이터, 비용 저, 데이터 손실 허용 【정답 포인트】 ▸ "대량의 지속적인 처리량" → 퍼시스턴트 Lustre 지원, 스크래치 불가 ▸ "수천 개의 컴퓨팅 인스턴스" → 병렬 처리, 낮은 지연시간 필수 ▸ HPC 최적화—Lustre는 수백 GB/s 처리량, EFS는 상대적으로 낮음 【오답 체크】 (A) 스크래치는 임시 데이터 전용, "지속적"이라는 요구 미충족 (C) EFS는 범용 파일 시스템, HPC 고처리량에 최적화되지 않음 (D) EFS 프로비저닝도 Lustre 대비 처리량 낮음 【시험 포인트】 ▸ HPC + 지속적 + 고처리량 → FSx Lustre Persistent ▸ 스크래치 vs 퍼시스턴트 구분 핵심

해설

【핵심 용어】 ▸ gp3—용량과 무관하게 IOPS 독립 설정, 비용 효율적 ▸ gp2—IOPS 자동 비례 (용량 3:1), 독립 프로비저닝 불가 ▸ io1—고성능 전용, 높은 비용 【정답 포인트】 ▸ "디스크 스토리지 용량과 무관하게" → gp3만 지원 (분리형 가격 책정) ▸ 15,000 IOPS 요구—gp3은 3,000~16,000 범위 충족 ▸ 비용 효율성—gp3 > io1 (io1은 16,000 IOPS 이상 필요할 때) 【오답 체크】 (A) gp2는 용량 기반 IOPS, 독립 프로비저닝 불가능 (B) io1은 15,000 IOPS에 과도한 비용 (D) 마그네틱은 최대 1,000 IOPS 미만 【시험 포인트】 ▸ "용량과 무관하게" → gp3 분리형 설정 ▸ gp2 vs gp3 구분: 용량 독립성

해설

【핵심 용어】 ▸ RDS for SQL Server—관리형 서비스, 자동 백업 및 장애 조치 ▸ 읽기 복제본—분석 쿼리 분리, OLTP 영향 최소화 ▸ 관리 오버헤드—RDS (최소) > EC2 (높음) 【정답 포인트】 ▸ "관리형 서비스로 전환" → RDS (자동 유지보수), EC2 제외 ▸ OLTP + OLAP 분리 필요 → 읽기 복제본 활용 ▸ SQL Server 라이선스 유지 → RDS 지원, DynamoDB/Aurora MySQL 불가 【오답 체크】 (B) EC2는 관리형 아님, 패치/백업 수동 운영 (C) DynamoDB는 관계형 DB 아님, 스키마 마이그레이션 불가 (D) Aurora MySQL로의 변환은 애플리케이션 재개발 필요 【시험 포인트】 ▸ 기존 SQL Server → 같은 DB 엔진 (RDS for SQL Server) ▸ 관리형 우선순위: RDS > EC2

해설

【핵심 용어】 ▸ Standard-IA—3개 AZ, 신뢰성 높음 ▸ One Zone-IA—1개 AZ, 비용 최저, 데이터 손실 위험 ▸ Glacier Instant—즉시 검색 (밀리초) ▸ Glacier Flexible—최대 12시간, 비용 최저 【정답 포인트】 ▸ "이미지가 손실될 수 없음" → One Zone-IA 제외 (1개 AZ) ▸ "360일 후 즉시 사용" → Glacier Instant Retrieval 필수 ▸ "12시간 이내 검색" → Glacier Flexible 지원 ▸ 비용 효율—Standard-IA + Instant + Flexible 조합 【오답 체크】 (A) One Zone-IA는 데이터 손실 위험, "손실 불가" 위반 (B) Glacier Flexible (12시간)은 "즉시" 요구 불충족 (D) Standard-IA + Flexible은 "즉시" 요구 미충족 【시험 포인트】 ▸ 데이터 손실 불가 → Standard-IA (다중 AZ) ▸ 즉시 vs 12시간 → Instant vs Flexible 구분

해설

【핵심 용어】 ▸ 임시 클러스터—작업 후 자동 종료, HDFS 데이터 손실 (외부 스토리지 필수) ▸ 장기 실행 클러스터—지속적 운영, HDFS 유지 ▸ 코어 노드—HDFS 데이터 저장, 스팟 인스턴스 사용 불가 【정답 포인트】 ▸ "데이터 손실 금지" + "6시간마다 실행" → 임시 클러스터 + 외부 스토리지 (S3) ▸ HDFS 데이터 보호—코어 노드는 온디맨드 필수 ▸ 비용 절감—작업 노드만 스팟 인스턴스 사용 ▸ "매다 실행" → 클러스터 재생성, 임시 구성 적합 【오답 체크】 (A) 장기 실행은 6시간 작업에 비효율, 비용 낭비 (C) 트랜지션 클러스터는 존재하지 않는 용어 (D) 코어 노드를 스팟으로 사용하면 HDFS 데이터 손실 【시험 포인트】 ▸ 주기적 작업 + 데이터 손실 불가 → 임시 + 코어 On-Demand ▸ 코어 노드 스팟 사용 함정

해설

【핵심 용어】 ▸ 읽기 복제본—OLTP 트래픽 분산, 데이터 동기화 오버헤드 ▸ Athena—S3 데이터 분석, OLAP 최적화, 비용 저 ▸ OLTP vs OLAP—실시간 vs 일괄 처리 【정답 포인트】 ▸ "한 달에 한 번" → 일괄 분석 작업, OLAP 특성 ▸ "일일 워크로드 성능 유지" → OLTP와 분리 필수 ▸ "보고서 쿼리" → S3 + Athena (분석 최적화, 저비용) ▸ 읽기 복제본도 쓰기 작업 동기화로 오버헤드 발생 【오답 체크】 (A) 읽기 복제본은 OLTP 쿼리 부하 (동기화), 보고서에 부적합 (B) 백업 복원은 일회성, 주기적 보고서에 비효율 (D) 인스턴스 업그레이드는 월 1회 피크에 비용 낭비 【시험 포인트】 ▸ 주기적 분석 쿼리 → S3 + Athena (OLAP 분리) ▸ 읽기 복제본 함정: OLTP 분산용, OLAP 아님

해설

【핵심 용어】 ▸ RDS Proxy—연결 풀링, 장애 조치 시간 66% 단축 ▸ 다중 AZ 클러스터—RDS 기능, Aurora 아님 ▸ 연결 오류—최대 연결 수 초과 【정답 포인트】 ▸ "장애 조치 시간 20% 단축" → RDS Proxy (기본 66% 단축 제공) ▸ "너무 많은 연결" → 연결 풀링으로 관리 ▸ 해결책이 데이터베이스 전환 필요 없음 (Aurora 유지) ▸ RDS Proxy는 기존 인프라 최소 변경 【오답 체크】 (A) Aurora → RDS 변환은 불필요, 기존 장애 조치 시간 단축 불가 (C) DynamoDB는 다른 DB 엔진, 데이터 재구성 필요 (D) Redshift는 분석 DB, OLTP 미지원 【시험 포인트】 ▸ 연결 부족 → RDS Proxy (연결 풀) ▸ 장애 조치 시간 단축 → RDS Proxy IAM DB Auth 지원