정답 · 해설

해설

【핵심 용어】 ▸ 읽기 복제본 — 프라이머리의 복제본, 읽기만 가능 ▸ 쓰기-읽기 분리 → 성능 향상 【정답 포인트】 ▸ "쓰기에 영향 없음" → 읽기 전용 복제본 생성 ▸ 비즈니스 보고 → 읽기 쿼리, 복제본에 오프로드 ▸ 간단한 구성 → RDS 읽기 복제본 자동 동기화 【오답 체크】 (B) 로드 밸런서 → 데이터베이스 트래픽 분산 불가 (C) 수직 확장 → 쓰기 성능은 개선되지만 비용 증가, 읽기 분리 아님 (D) 다중 AZ → 장애 조치용, 읽기 성능 향상 안 됨 【시험 포인트】 ▸ "쓰기 영향 없이" + "읽기 쿼리" → 읽기 복제본 패턴 ▸ 보고 작업 → 항상 복제본으로 오프로드 전략

해설

【핵심 용어】 ▸ 세션 선호도(Sticky Session) — 같은 클라이언트 → 같은 인스턴스 ▸ 지속적 저장 — 메모리가 아닌 데이터베이스/캐시에 저장 【정답 포인트】 ▸ (A) ALB Sticky Session → 라운드로빈 대신 특정 서버 유지 ▸ (D) ElastiCache Redis → 세션 스토어, 빠른 접근 ▸ 조합: 라우팅 (A) + 저장소 (D) 로 세션 일관성 보장 【오답 체크】 (B) DynamoDB → 쓰기 비용 높음, 세션용으로는 과도 (C) Cognito → 사용자 인증, 세션 관리 도구 아님 (E) Systems Manager → 애플리케이션 관리, 세션 저장소 아님 【시험 포인트】 ▸ Auto Scaling + 세션 → Sticky Session (A) + 외부 저장소 (D) 필수 ▸ "트랜잭션 중" → 세션 일관성 > 단순 메모리 캐시

해설

【핵심 용어】 ▸ 상태 비저장 웹앱 → EC2 인스턴스는 언제든지 교체 가능 ▸ AMI — 웹/앱 계층 재구성 템플릿 ▸ RDS 자동 백업 → 지정 시간 복구(PITR)로 RPO 2시간 달성 【정답 포인트】 ▸ 상태 비저장 → EC2 스냅샷 불필요, AMI만 유지 ▸ EBS/EBS 스냅샷 → 설정 변경용, 지속적 백업 오버헤드 ▸ RDS 자동 백업 + PITR → RPO 2시간 충족, 운영 간단 【오답 체크】 (A) 2시간 스냅샷 → EC2는 상태 비저장이므로 백업 불필요, 비용 낭비 (B) EBS 수명 주기 정책만 → RDS 백업 자동화 아님 (D) EC2 스냅샷 계속 생성 → 상태 비저장 특성 무시, 비용 과다 【시험 포인트】 ▸ 상태 비저장 + Auto Scaling → AMI 템플릿 유지, 인스턴스 백업 X ▸ "지속적 저장" 데이터 → RDS 자동 백업 + PITR만 필요

해설

【핵심 용어】 ▸ 글로벌 고객 → 동적 IP 주소, CIDR 범위 지정 불가 ▸ 보안 그룹 체이닝 → 웹 SG 참조로 DB 접근 제한 【정답 포인트】 ▸ 웹 서버 SG → 0.0.0.0/0 포트 443 허용(인터넷 수용) ▸ DB SG → 웹 서버 SG만 3306 허용(최소 권한) ▸ 이중 계층 방어 → 인터넷 ↔ 웹, 웹 ↔ DB만 통신 【오답 체크】 (B) 고객 IP 사전 파악 불가 → "동적 IP" 요구 미충족 (C) DB를 인터넷에 노출 → 보안 위협 (D) DB 포트 3306 인터넷 공개 → 보안 최악 【시험 포인트】 ▸ "동적 IP" + "글로벌" → 0.0.0.0/0만 가능 ▸ "웹-DB 통신" → 보안 그룹 참조로 격리(A만 해결)

해설

【핵심 용어】 ▸ Transcribe — 오디오 → 텍스트 변환 ▸ PII 수정(Redaction) — Transcribe 기본 기능 ▸ S3 이벤트 트리거 → Lambda로 자동화 【정답 포인트】 ▸ Transcribe PII 수정 활성화 → 자동으로 민감정보 마스킹 ▸ S3 업로드 → Lambda 트리거 → Transcribe 작업 시작 ▸ 출력을 별도 버킷에 저장 → 원본과 처리본 분리 【오답 체크】 (A) Kinesis Video Streams → 실시간 스트리밍용, 저장 파일에 부적절 (B) Textract → 문서 이미지/OCR용, 오디오 처리 불가 (D) Amazon Connect → 콜센터 플랫폼, S3 보관 오디오 연동 복잡 【시험 포인트】 ▸ "음성 녹음" + "텍스트 변환" → Transcribe 전담 ▸ "PII 제거" → Transcribe의 built-in PII Redaction 기능

해설

【핵심 용어】 ▸ gp3 — 최대 16,000 IOPS(기본 3,000) ▸ 볼륨 크기 → IOPS 상한선과 관계 없음(일반적) ▸ 다중 볼륨 → 병렬 처리로 총 IOPS 증가 【정답 포인트】 ▸ 현재 20,000 IOPS 요구 → gp3 단일 최대(16,000) 초과 ▸ 2개 볼륨 분산 → 각 ~10,000 IOPS 처리 가능 ▸ 비용 효율 → io2(더 비쌈) 대신 gp3 2개 활용 【오답 체크】 (A) 마그네틱 → 구형 저성능, IOPS 더 낮음 (B) gp3 IOPS 증가 → 최대 16,000 한계, 여전히 부족 (C) io2 → 비용 높고, 2개 gp3가 경제적 【시험 포인트】 ▸ "IOPS 초과" + gp3 → 볼륨 분산이 먼저 ▸ io2 upgrade 전에 → 다중 gp3 병렬화 확인

해설

【핵심 용어】 ▸ CloudTrail — 모든 API 호출 로깅(who/what/when/where) ▸ 감사 추적(Audit Log) → IAM 사용자 활동 추적 【정답 포인트】 ▸ "어떤 사용자가" → IAM 아이디 필요 ▸ "언제 변경했는지" → 타임스탐프 필요 ▸ CloudTrail만 제공 → 상세 API 호출 기록 【오답 체크】 (A) GuardDuty → 악성 활동 탐지, 일반 API 로깅 아님 (B) Inspector → 취약점 스캔, 변경 추적 기능 없음 (D) AWS Config → 리소스 상태 변경 이력만, 사용자 정보 없음 【시험 포인트】 ▸ "누가 변경했는지" → CloudTrail 필수(감사 추적) ▸ 보안 그룹 API 호출 기록 → CreateSecurityGroupIngress 등 로깅

해설

【핵심 용어】 ▸ Shield Advanced — DDoS 공격 방어(전용 보호) ▸ Global Accelerator — 엣지에서 트래픽 진입점 ▸ DNS 레이어 보호 → Global Accelerator 앞단 필수 【정답 포인트】 ▸ DDoS 공격 → Shield Advanced 필수(Shield Standard 불충분) ▸ Global Accelerator → DDoS 진입점, 보호 대상 1순위 ▸ Shield Advanced 가입 → 가속기를 보호 리소스로 등록 【오답 체크】 (B) EC2만 보호 → Global Accelerator 미보호, DDoS 진입점 공격 (C) WAF 속도 규칙 → Layer 7(애플리케이션), Layer 3/4 DDoS 미방어 (D) WAF + EC2 → 오리진 보호만, 가속기 미보호 【시험 포인트】 ▸ "DDoS 공격" → Shield Advanced 전담 ▸ "Global Accelerator" → 진입점 보호가 우선순위

해설

【핵심 용어】 ▸ 예약 일일 작업 → 정기 실행, EventBridge 스케줄 ▸ 최대 1시간, CPU/메모리 일정 → 컨테이너 적합 ▸ 10GB 파일 처리 → Lambda (15분 제한) 초과 가능 【정답 포인트】 ▸ "최대 1시간" → Lambda 15분 제한 초과 ▸ Fargate → 서버 관리 없음, EventBridge 트리거 가능 ▸ 최소 운영 노력 → EC2 인스턴스 관리 불필요 【오답 체크】 (A) Lambda → 15분 제한, 1시간 작업 불가능 (B) API Gateway → Lambda와 동일 제한, 불필요한 복잡도 (D) EC2 + ECS → 인스턴스 관리 오버헤드, Fargate보다 운영 부담 【시험 포인트】 ▸ "최대 1시간" → Lambda 제한 초과 → ECS/Fargate ▸ "운영 노력 최소" → Fargate 선택(EC2 관리 X)

해설

【핵심 용어】 ▸ Snow Family — 물리 데이터 전송 서비스(인터넷 불필요) ▸ 600TB + 2주 + 100Mbps 제약 → Snowball 최적 【정답 포인트】 ▸ 100Mbps 제약 → 600TB를 2주 내 전송 불가능(이론값: ~13주 필요) ▸ Snowball Edge → 대용량 물리 전송, 암호화 기본 제공 ▸ 가장 비용 효율 → 인터넷 대역폭 구매 불필요 【오답 체크】 (A) HTTPS 인터넷 업로드 → 100Mbps로 600TB 는 ~13주, 2주 불가능 (B) VPN → HTTPS와 동일, 대역폭 제약 극복 불가 (D) Direct Connect → 10Gbps 설정 비용 높음, Snowball 더 경제적 【시험 포인트】 ▸ "인터넷 대역폭 제약" + "대용량" → Snow Family 고려 ▸ 데이터양/시간 계산 → 인터넷 전송 불가 판정 → Snowball

해설

【핵심 용어】 ▸ HTTP 플러드 — Layer 7 애플리케이션 계층 공격 ▸ Rate-based WAF — IP별 요청 속도 제한 ▸ API Gateway 단계 — WAF 직접 통합 가능 【정답 포인트】 ▸ 속도 기반 규칙 → 임계값 초과 IP 자동 차단 ▸ WAF 직접 통합 → 최소 운영 오버헤드 ▸ API Gateway 단계 → 보호 대상 직접 지정 【오답 체크】 (A) CloudFront 캐싱 → API 동적 응답에 부적절, 캐시 미스 시 플러드 통과 (C) 모니터링만 → 공격 자동 방어 안 됨, 수동 대응 필요 (D) Lambda@Edge → 복잡한 설정, CloudFront 필수, WAF 더 간단 【시험 포인트】 ▸ "HTTP 플러드" → Layer 7 공격 → WAF rate-based 규칙 ▸ "최소 운영 오버헤드" → AWS WAF 자동 차단 기능

해설

【핵심 용어】 ▸ DynamoDB 스트림 — 데이터 변경을 실시간으로 캡처하는 서비스 ▸ Lambda 트리거 — 스트림 이벤트 감지 시 자동 호출 ▸ SNS 디커플링 — 쓰기와 알림 로직을 분리 【정답 포인트】 ▸ "현재 애플리케이션의 성능에 영향" → 쓰기 경로와 분리 필요 ▸ "운영 오버헤드 최소" → 서버리스(Lambda) 선택 ▸ DynamoDB 스트림 활성화 → Lambda가 변경사항 자동 감지 ▸ SNS 게시 → 4개 팀에 확장성 있는 알림 【오답 체크】 (A) 트랜잭션으로 쓰기와 알림을 묶으면 성능 저하 발생 (B) 4개 주제 관리, 애플리케이션 코드 직접 수정 필요 → 운영 부담 (D) 폴링 기반 cron은 지연, 비효율적 + 높은 운영 비용 【시험 포인트】 "비동기 처리" 요구 + "성능 독립" → 스트림 + 서버리스 SNS(팬아웃) vs SQS(큐) → 여러 구독자 = SNS 선택

해설

【핵심 용어】 ▸ Kinesis 기본 보존 기간 — 24시간(데이터 손실 가능) ▸ "격일" 소비 — 24시간 초과 시 데이터 누락 ▸ 보존 기간 연장 — 데이터 유지 시간 증가 【정답 포인트】 ▸ "모든 데이터를 수신하지 못함" → Kinesis 기본값(24시간) 초과 ▸ "격일로" 처리 → 최소 48시간 보존 필요 ▸ 보존 기간을 수정하면 데이터 손실 방지 ▸ 용량(샤드)이 아닌 시간 문제 【오답 체크】 (B) KPL은 배치 최적화일 뿐, 보존 기간과 무관 (C) 처리량 문제가 아닌 "격일" 지연 접근 → 샤드 수 증가 불필요 (D) S3 버전 관리는 이미 들어온 데이터만 관리 【시험 포인트】 "데이터 손실" + "시간 간격" → 보존 기간 점검 비동기 처리(격일) = 저장소 기본값 초과 검토

해설

【핵심 용어】 ▸ IAM 실행 역할(Execution Role) — Lambda가 권한 상속 ▸ 신뢰 관계 — Lambda 서비스가 역할 사용 가능 ▸ 인라인 정책 — S3 접근 권한 부여 【정답 포인트】 ▸ Lambda는 IAM 사용자 자격 증명 사용 불가 → 역할 필수 ▸ 실행 역할 생성 → S3 정책 연결 → Lambda에 할당 ▸ AWS 서비스 신뢰 관계 자동 설정 ▸ 최소 권한 원칙 준수 【오답 체크】 (A) 리소스 정책은 호출자 제한용(S3 접근 권한 아님) (B) Lambda 코드에 IAM 자격 증명 하드코딩 → 보안 위험 (C) 새 사용자 생성 → 자격 증명 관리 복잡, Lambda와 비호환 【시험 포인트】 "Lambda" + "S3 접근" = 실행 역할 패턴 AWS 서비스 권한 = 역할(사용자 불가)

해설

【핵심 용어】 ▸ S3 이벤트 동시성 제한 — 동시 Lambda 실행 제약 ▸ SQS 버퍼링 — 대기열 기반 처리로 부하 분산 ▸ Lambda 배치 처리 — 여러 메시지 한 번에 처리 【정답 포인트】 ▸ "많은 문서를 처리하지 않음" → S3-Lambda 직접 연결 병목 ▸ SQS 도입 → 비동기 디커플링 + 동시성 제어 ▸ Lambda가 대기열에서 배치로 메시지 소비 ▸ 급증하는 문서 유입에 탄력적 대응 【오답 체크】 (A) 제한 시간 증가 → 처리 능력 개선 안 됨 (B) S3 복제 → 문서 복제일 뿐, 처리 속도 향상 없음 (C) Lambda 함수 추가 → S3 동시성 제한은 변하지 않음 【시험 포인트】 "처리 지연" + "버스트 트래픽" → 메시지 큐(SQS) S3 → Lambda 직접 연결 = 동시성 병목 → 큐 추가

해설

【핵심 용어】 ▸ 예약된 조정 — 시간 기반 자동 확장 ▸ 대상 추적 — 지표 기반 동적 조정 ▸ 메트릭 조정 vs 시간 조정 — 상호 보완 【정답 포인트】 ▸ "근무 시간" + "주말" → 예측 가능한 패턴 → 예약된 조정 (E) ▸ "트래픽 증가" → CPU 기반 실시간 조정 (D) ▸ 두 정책 조합 → 비용 최적화 + 성능 보장 ▸ 주말 0으로 설정 → 미사용 인스턴스 비용 절감 【오답 체크】 (A) ALB는 자동으로 확장, 용량 조정 불필요 (B) 인터넷 게이트웨이는 확장 개념 없음(VPC당 1개) (C) 다중 리전은 지역 내 수요 패턴 해결 불가, 비용 증가 【시험 포인트】 "정규적 패턴(주말/근무시간)" = 예약된 조정 "동적 트래픽" = 대상 추적(CPU/요청) 두 개 선택 → 보완 전략 조합

해설

【핵심 용어】 ▸ 웹 서버 보안 그룹 — 인바운드 443 개방 ▸ DB 보안 그룹 — 웹 SG만 3306 허용 ▸ 보안 그룹 레퍼런싱 — CIDR 대신 SG 이름으로 제어 【정답 포인트】 ▸ "포트 443 인터넷 개방" → 웹 SG 인바운드 (C) ▸ "웹 서버에서만 3306 접근" → DB SG 레퍼런싱 (D) ▸ 보안 그룹은 Stateful → 반환 트래픽 자동 허용 ▸ 보안 그룹 체인 구성 = 최소 권한 【오답 체크】 (A) NACL은 서브넷 수준, 세밀한 제어 불가 (B) CIDR 블록 → 모든 퍼블릭 서브넷 호스트 허용(과도) (E) 거부 규칙은 보안 그룹에서 불필요(명시 허용만) 【시험 포인트】 보안 그룹 체인 = SG-A → SG-B(레퍼런싱) NACL vs SG: 세밀한 제어 = SG(stateful)

해설

【핵심 용어】 ▸ FSx for Lustre — Lustre 프로토콜 완전 관리 ▸ 고성능 컴퓨팅(HPC) 특화 ▸ S3 원본 데이터 연계 【정답 포인트】 ▸ "Lustre 클라이언트" → Lustre 프로토콜 필수 ▸ "완전히 관리" → AWS 관리형 서비스 ▸ FSx for Lustre만이 Lustre 전용 ▸ 게임 애플리케이션 = 고성능 요구 【오답 체크】 (A) DataSync는 데이터 동기화, 파일 시스템 아님 (B) Storage Gateway는 NFS/SMB, Lustre 미지원 (C) EFS는 NFS 프로토콜, Lustre 지원 안 함 【시험 포인트】 Lustre = FSx for Lustre만 선택 "HPC" 또는 "고성능" + "파일 시스템" = FSx

해설

【핵심 용어】 ▸ Global Accelerator — 대기 시간 최소화, 빠른 장애조치 ▸ NLB + UDP 지원 — 실시간 처리 ▸ ECS 처리 — 상태 비저장 서비스 ▸ Anycast — 지리적으로 분산된 장치 수렴 【정답 포인트】 ▸ "UDP" → NLB 필수(ALB는 HTTP/HTTPS) ▸ "최소 대기 시간" → Global Accelerator(Anycast IP) ▸ "빠른 장애조치" → Global Accelerator 자동 감지 ▸ "즉시 처리" → ECS 서비스로 확장성 【오답 체크】 (A) Route 53은 DNS 기반(지연), Lambda 제한(15분) (C) ALB는 TCP/HTTP만 지원, UDP 불가 (D) Route 53은 Global Accelerator만큼 빠르지 않음 【시험 포인트】 UDP = NLB(Route 53 아님) "지리적 분산" + "최소 지연" = Global Accelerator

해설

【핵심 용어】 ▸ FSx for Windows — SMB/NTFS 네이티브 지원 ▸ 다중 AZ 배포 — 고가용성, 자동 복제 ▸ 관리형 파일 공유 【정답 포인트】 ▸ "Windows IIS" → SMB/NTFS 프로토콜 필수 ▸ "여러 가용 영역" → 다중 AZ FSx(탄력성) ▸ "파일 공유" → Windows File Server 호환 ▸ "가장 탄력적, 내구성" → 관리형 서비스 【오답 체크】 (A) RDS는 데이터베이스, 파일 시스템 아님 (B) Storage Gateway는 온프레미스 캐시, 클라우드 네이티브 아님 (D) EFS는 NFS(Linux), Windows SMB 미지원 【시험 포인트】 Windows 파일 공유 = FSx for Windows Linux NFS = EFS NTFS/SMB = Windows File Server