정답 · 해설

해설

【핵심 용어】 ▸ ElastiCache for Redis — 인메모리 캐시, 밀리초 지연 ▸ Session 캐싱 — 사용자 상태 빠른 조회 ▸ 성능 개선 — 데이터베이스 쿼리 부하 감소 【정답 포인트】 ▸ "사용자 세션" → Redis 캐시가 최적 (A) ▸ "빠른 응답" → 밀리초 수준 접근 속도 ▸ "데이터베이스 부하" → 캐시 히트로 쿼리 감소 ▸ "확장성" → 캐시 계층으로 수평 확장 【오답 체크】 (B) Memcached는 문자열만 저장, 세션 복잡 객체 부적절 (C) RDS 읽기 복제는 캐싱 아님, 지연 여전 (D) CloudFront는 정적 콘텐츠, 세션 동적 데이터 부적절 【시험 포인트】 ▸ "세션 캐싱" → Redis ▸ "밀리초 응답" → 인메모리 캐시 필수

해설

【핵심 용어】 ▸ Amazon SQS 데드레터 큐 — 실패 메시지 격리 ▸ 재시도 정책 — 실패 메시지 자동 재처리 ▸ 오류 처리 — 실패 격리, 성공 보장 【정답 포인트】 ▸ "실패 메시지" → 데드레터 큐로 격리 (B) ▸ "자동 재시도" → 최대 시도 횟수 후 DLQ로 이동 ▸ "모니터링" → DLQ 크기 모니터링으로 오류 탐지 ▸ "격리 처리" → 실패 메시지만 별도 처리, 성공 흐름 보호 【오답 체크】 (A) SNS는 팬아웃, 오류 처리 미흡 (C) 애플리케이션 재시도 = 복잡도 증가, 관리 부담 (D) Lambda 재시도는 제한적, 무한 재시도 위험 【시험 포인트】 ▸ "실패 메시지 처리" → SQS 데드레터 큐 ▸ "자동 재시도" → 큐 설정

해설

【핵심 용어】 ▸ Amazon EventBridge — 이벤트 기반 아키텍처, 라우팅 ▸ 이벤트 필터 — 규칙에 따른 선택적 전달 ▸ 느슨한 결합 — 소스와 대상 독립 【정답 포인트】 ▸ "이벤트 라우팅" → EventBridge 규칙으로 필터링 (A) ▸ "조건부 전달" → 이벤트 패턴으로 대상 선택 ▸ "느슨한 결합" → 소스 변경 시 대상 영향 최소 ▸ "다중 대상" → 하나 규칙으로 여러 대상 지원 【오답 체크】 (B) SNS는 구독 필터 제한적, 복잡한 조건 부적절 (C) SQS는 라우팅 기능 없음, 필터링 불가 (D) Lambda는 직접 호출, 라우팅 로직 추가 필요 【시험 포인트】 ▸ "이벤트 기반 라우팅" → EventBridge ▸ "조건부 필터" → 규칙 패턴

해설

【핵심 용어】 ▸ VPC 플로우 로그 — 네트워크 트래픽 기록 ▸ CloudWatch Logs 분석 — 실시간 로그 검색 ▸ 보안 감사 — 네트워크 통신 추적 【정답 포인트】 ▸ "네트워크 트래픽" → VPC 플로우 로그 필수 (A) ▸ "실시간 분석" → CloudWatch Logs로 검색 ▸ "보안 감시" → 비정상 통신 탐지 ▸ "규정 준수" → 모든 통신 기록 가능 【오답 체크】 (B) CloudTrail은 API 호출만, 네트워크 트래픽 기록 불가 (C) Security Groups 로그는 거부만 기록, 모든 트래픽 불가 (D) 애플리케이션 로깅은 수작업, 자동화 부족 【시험 포인트】 ▸ "네트워크 트래픽 감시" → VPC 플로우 로그 ▸ "실시간 분석" → CloudWatch Logs

해설

【핵심 용어】 ▸ Lifecycle Policy — 시간 기반 자동 스토리지 클래스 전환 ▸ S3 Glacier Deep Archive — 저비용 아카이브, 180일+ 보관용 ▸ 즉시 검색 — S3 Standard 필수, 2년 이내 접근 【정답 포인트】 ▸ "2년: 고가용성" → S3 Standard 유지 필수 (B) ▸ "2년 후: 저비용" → Glacier Deep Archive 전환 (B) ▸ "25년 보관" → Deep Archive 장기 보존 특성 적합 ▸ "Lifecycle 자동화" → 비용 최적화, 운영 오버헤드 0 【오답 체크】 (A) 즉시 아카이브 = 2년 내 필요 데이터 접근 지연 (C) Intelligent-Tiering은 접근 패턴 기반, 확정적 기간 부적합 (D) One Zone-IA는 단일 AZ, 25년 장기 보관 시 내구성 위험 【시험 포인트】 ▸ "2년 최근 + 25년 보관" → 2년 후 아카이브 ▸ "즉시 검색" → Standard 유지 ▸ "저비용 장기" → Deep Archive

해설

【핵심 용어】 ▸ EC2 인스턴스 스토어 — 최고 I/O 성능, NVMe SSD, 임시 스토리지 ▸ S3 — 높은 내구성(11개 9), 단일 서비스로 다중 용도 【정답 포인트】 ▸ 10TB 최대 I/O: EC2 인스턴스 스토어(EBS보다 높은 성능) ▸ 300TB 내구성: S3 Standard(최고 내구성 11개 9) ▸ 900TB 아카이브: S3 Glacier(저비용 장기 보관) ▸ 단일 서비스 확장 가능 — S3 무한 용량 【오답 체크】 (A) EBS는 인스턴스 스토어보다 I/O 성능 낮음 (B) EFS는 네트워크 파일시스템, 순차 접근, 비디오 처리에 비효율 (C) EFS(내구성)는 비용 높음, S3가 더 저렴하고 내구성 높음 【시험 포인트】 "최대 I/O 성능" = EC2 인스턴스 스토어 / "내구성" = S3 / "아카이브" = Glacier / 300TB + 900TB = S3 통합

해설

【핵심 용어】 ▸ Aurora — 자동 확장성, 자동 백업, 관리형 PostgreSQL ▸ Fargate — 컨테이너 실행, 인프라 관리 불필요 【정답 포인트】 (A) PostgreSQL → Aurora: 자동 확장, 용량 계획 제거 (E) 컨테이너 + Fargate: 서버리스 컨테이너, 인프라 관리 0 ▸ 조합: 데이터베이스+애플리케이션 모두 관리형 → 운영 오버헤드 최소화 【오답 체크】 (B) EC2 마이그레이션 → 여전히 인프라 관리 필요 (C) CloudFront는 정적 콘텐츠, 웹 애플리케이션 성능에 무관 (D) ElastiCache는 캐싱 계층, 용량 계획 오버헤드 해소 아님 【시험 포인트】 운영 오버헤드 감소 = 관리형 서비스 / PostgreSQL = Aurora / 컨테이너 = ECS+Fargate / 인프라 관리 제거

해설

【핵심 용어】 ▸ 대상 추적 정책 — 목표 메트릭(CPU 40%) 유지, 자동 조정 ▸ 간단한 정책 — 임계값 기반 스케일링, 정확도 낮음 【정답 포인트】 ▸ "CPU 40% 최적 성능" → 대상 추적 정책 직접 지정 ▸ 자동 인스턴스 추가/제거 → 목표값 유지 반복 ▸ "모든 인스턴스에서 원하는 성능" → 일관성 있는 유지 ▸ 정확한 메트릭 기반 → CPU 목표값 달성 【오답 체크】 (A) 간단한 정책은 CPU 상한선에서만 작동, 40% 유지 불가 (C) Lambda는 주기적 갱신, 실시간 목표값 추적 불가 (D) 예약된 조정은 시간 기반, 부하 변화에 대응 불가 【시험 포인트】 "목표 메트릭 유지" = 대상 추적 정책 / "CPU 40%" = 정책에 직접 지정 / 자동 조정 = 인스턴스 수 동적 변경

해설

【핵심 용어】 ▸ OAI(원본 액세스 ID) — CloudFront 전용 ID, S3 직접 접근 차단 ▸ S3 직접 접근 금지 — CloudFront만 허용하도록 격리 【정답 포인트】 ▸ OAI (D) — CloudFront만 S3 접근, 일반 사용자 직접 접근 불가 ▸ 가상 ID 기반 → IAM 사용자 불필요 ▸ 자동 구성 → CloudFront 배포 생성 시 OAI 연동 ▸ 보안 격리 — S3 정책에 OAI만 권한 부여 【오답 체크】 (A) 정책 텍스트로 CloudFront 특정 불가능, 버킷 정책은 도메인 기반 (B) IAM 사용자는 장기 크레덴셜 노출 위험, CloudFront 연동 불가 (C) CloudFront ID는 실제 보안 주체 아님, 정책 작성 불가 【시험 포인트】 CloudFront만 허용 = OAI 필수 / 일반 사용자 차단 = S3 정책에 OAI만 권한 / 보안 격리 = 가상 ID 기반

해설

【핵심 용어】 ▸ RDS Custom — OS 접근 가능, 관리형 DB 기능 결합 ▸ 읽기 전용 복제본 — 리전별 DR, 자동 동기화 【정답 포인트】 ▸ OS 액세스 필요 → RDS Custom(일반 RDS는 OS 접근 불가) ▸ 최신 버전 업그레이드 → Custom이 유연한 업그레이드 지원 ▸ DR 설정(리전 기반) → 읽기 복제본(다른 리전) ▸ 운영 오버헤드 최소 → Custom + 자동 복제 【오답 체크】 (A) EC2는 OS 접근 가능하나, 패치/백업/복제 수동 관리 (B) 일반 RDS는 OS 접근 불가, 요구사항 미충족 (D) 다중 AZ는 리전 내 DR, 진정한 재해 복구 아님(같은 리전) 【시험 포인트】 OS 액세스 + 관리형 = RDS Custom / 버전 업그레이드 = Custom 지원 / 리전 기반 DR = 읽기 복제본 / 최소 오버헤드 = 자동화

해설

【핵심 용어】 ▸ SSE-S3 — S3 자체 관리 암호화로 CRR 시 자동 호환 ▸ Athena — S3 데이터 직접 SQL 분석, 운영 오버헤드 최소 【정답 포인트】 ▸ 기존 버킷 재사용 → 신규 생성 비용 절감 ▸ SSE-S3 + CRR → 자동 암호화 복제 지원 ▸ Athena 쿼리 → 서버리스, 인프라 관리 불필요 【오답 체크】 (A) KMS 다중 리전 → A/B 모두 새 버킷 생성으로 불필요 비용 (B) RDS → 데이터 동기화 관리 필요, 운영 오버헤드 증가 (D) SSE-S3 + RDS 조합 → CRR 호환성 문제, 복잡도 증가 【시험 포인트】 서버리스 = 최소 운영 → Athena 우선, CRR + S3 암호화 자동화

해설

【핵심 용어】 ▸ AWS PrivateLink — VPC 내 서비스 노출, 인터넷 우회 ▸ VPC 엔드포인트 — 공급자가 생성, 회사는 엔드포인트 소비 【정답 포인트】 ▸ PrivateLink 구조 → 공급자(NLB) + 회사(엔드포인트) 양측 필요 ▸ 비공개 연결 → 인터넷 미경유, 완전 격리 ▸ 서비스 제한 → 특정 대상만 노출 가능 【오답 체크】 (A) VPC 피어링 → 양쪽 전체 네트워크 열림, 세분화 불가 (B) 가상 프라이빗 게이트웨이 → AWS 용어 아님 (C) NAT 게이트웨이 → 퍼블릭 경로, 비공개 아님 【시험 포인트】 비공개+서비스 제한+회사 시작 = PrivateLink(공급자 엔드포인트)

해설

【핵심 용어】 ▸ DMS — 마이그레이션 중 온프레미스 DB 온라인 유지 ▸ 지속적 복제 → CDC(Change Data Capture) 기반 동기화 【정답 포인트】 ▸ (A) 지속적 복제 → DMS로 마이그레이션 후 실시간 동기화 ▸ (C) DMS 복제 서버 → 온프레미스↔Aurora 지속 연결 인프라 ▸ 조합 효과 → 초기 로드 + 지속적 변경사항 동기화 【오답 체크】 (B) 백업 → 일회성, 지속 동기화 불가 (D) SCT → PostgreSQL은 호환성 높아 필수 아님 (E) EventBridge → 모니터링만, 복제 기능 없음 【시험 포인트】 온라인 마이그레이션+동기화 = DMS + 지속적 복제 작업

해설

【핵심 용어】 ▸ 대체 연락처 — Organizations에서 계정별 관리자 지정 ▸ 배포 목록 → 루트 이메일 일괄 관리 【정답 포인트】 ▸ 배포 목록 구성 → 소수 관리자에게 통합 수신 ▸ Organizations 대체 연락처 → 공식 AWS 기능 ▸ 이중 구조 → 놓침 방지 + 관리자 제한 【오답 체크】 (A) 모든 사용자 → 범위 확대, 관리자 제한 위배 (C) 단일 관리자 → 병목 위험, 확장성 낮음 (D) 동일 이메일 → 계정별 독립성 상실, Organizations 의도 위배 【시험 포인트】 루트 알림 누락 → Organizations 대체 연락처 + 배포 목록

해설

【핵심 용어】 ▸ Amazon MQ — 관리형 RabbitMQ, 높은 가용성 ▸ RDS 다중 AZ — 자동 페일오버, 운영 오버헤드 최소 【정답 포인트】 ▸ MQ 활성/대기 → RabbitMQ 자동 페일오버 ▸ App 다중 AZ Scaling → 가용성+탄력성 ▸ RDS Multi-AZ → DB 고가용성 자동 관리 【오답 체크】 (A) EC2 자체 관리 DB → 운영 오버헤드 높음 (C) EC2 RabbitMQ → MQ 관리 이점 상실 (D) 세 번째 ASG → 불필요한 복잡성, 운영 부담 【시험 포인트】 단일 AZ → 다중 AZ + 관리형 서비스(MQ, RDS)

해설

【핵심 용어】 ▸ S3 복제 — 초기→분석 버킷 자동 전송 ▸ EventBridge — 복제 이벤트 후 Lambda+SageMaker 트리거 【정답 포인트】 ▸ S3 복제 → 자동 파일 이동, Lambda 불필요 ▸ EventBridge + ObjectCreated → 복제 완료 후 워크플로우 ▸ 다중 대상 연결 → Lambda(패턴 분석) + SageMaker(파이프라인) 【오답 체크】 (A) Lambda로 복사 + S3 이벤트 → 불필요한 함수, EventBridge 미활용 (B) Lambda 복사 → 동기화 복잡, 중복 트리거 위험 (C) S3 이벤트만 → EventBridge 라우팅 이점 상실 【시험 포인트】 자동 이동+다중 액션 = S3 복제 + EventBridge

해설

【핵심 용어】 ▸ 스팟 — 변동성 워크로드, 저비용, 중단 가능 ▸ Compute Savings Plan — Fargate/Lambda 포함, 예측 가능 워크로드 【정답 포인트】 ▸ (A) 스팟 → 예측 불가 데이터 수집, 중단 허용 ▸ (C) Compute Plan → 1년 예측, Fargate+Lambda 커버 ▸ Fargate/Lambda 미보유 → EC2 Plan (E) 부적절 【오답 체크】 (B) 온디맨드 → 비용 최적 미달 (D) 1년 예약 → 예측 불가 워크로드에 낭비 (E) 부적절 【시험 포인트】 변동성+예측성 혼합 → 스팟(변동) + Savings Plan(고정)

해설

【핵심 용어】 ▸ CloudFront — 글로벌 엣지 캐싱, 정적+동적 모두 지원 ▸ 지연 시간 최소화 → 단일 리전+CDN 가장 효율적 【정답 포인트】 ▸ CloudFront 오리진 ALB → 캐시 + 동적 콘텐츠 실시간 응답 ▸ 단일 리전 → 비용 절감, 관리 간소 ▸ 글로벌 엣지 로케이션 → 자동 최적 경로 【오답 체크】 (B) 두 리전 → 동기화 복잡, 지연시간 라우팅 느림 (C) 정적/동적 분리 → 동적 콘텐츠 지연 증가 (D) 지리적 라우팅 → Route 53 지연, 엣지 우위 상실 【시험 포인트】 글로벌 지연 최소 = CloudFront(단일 오리진)

해설

【핵심 용어】 ▸ Global Accelerator — UDP 지원, 고정 IP, 엣지 라우팅 ▸ NLB — UDP 프로토콜, 저지연 【정답 포인트】 ▸ UDP 게임 → ALB 불지원, NLB 필수 ▸ Global Accelerator → 엣지 로케이션, 고정 IP 제공 ▸ EC2 → 수정 커널 실행 가능 【오답 체크】 (A) ALB → UDP 미지원, Lambda → 커널 수정 불가 (B) CloudFront → HTTP/HTTPS만, UDP 미지원 (D) API Gateway → HTTP 기반, UDP 미지원 【시험 포인트】 UDP+고정IP+엣지 = Global Accelerator + NLB

해설

【핵심 용어】 ▸ Aurora 복제본 — 읽기 전용, IOPS 격리 ▸ 읽기 부하 분산 — 프라이머리 영향 최소 【정답 포인트】 ▸ ReadIOPS 급증 → 읽기 쿼리 분리 ▸ 복제본에 보고서 → 애플리케이션 성능 보호 ▸ 비용 효율 → Redshift보다 경제적 【오답 체크】 (A) Redshift → 데이터 마이그레이션, 관리 복잡, 고비용 (C) 대형 인스턴스 → 쓰기도 증가, 비용 낭비 (D) IOPS 증설 → 문제의 근본 해결 아님 【시험 포인트】 보고서 읽기 부하 격리 = Aurora 복제본