정답 · 해설

해설

【핵심 용어】 ▸ CloudWatch Logs — 로그 수집 및 분석 ▸ AWS X-Ray — 애플리케이션 추적 및 성능 분석 ▸ Kinesis — 스트리밍 데이터 처리 (실시간 분석용) ▸ CloudTrail — API 감시 (애플리케이션 성능 분석 아님) ▸ Performance Insights — 성능 메트릭 수집 【정답 포인트】 ▸ "웹 서버 로그 손실" → CloudWatch Logs에 Apache 로그 수집 (D) ▸ "Aurora 쿼리 성능 미흡" → CloudWatch Logs에 느린 쿼리 로그 (A) ▸ "HTTP 요청 추적 + SQL 쿼리 추적" → X-Ray SDK (B) ▸ 결합: 웹 서버 로그 (D) + DB 쿼리 로그 (A) + 분산 추적 (B) ▸ = 완전한 가시성 (요청 → 응답 → DB까지) 【오답 체크】 (C) Kinesis는 실시간 분석용 (이 경우 CloudWatch가 더 적절) (E) CloudTrail은 API 호출 추적 (애플리케이션 성능 아님) (F) Performance Insights는 메트릭만 (구체적 쿼리 분석 부족) 【시험 포인트】 애플리케이션 성능 가시성 = CloudWatch Logs (웹/DB) + X-Ray (분산 추적)

해설

【핵심 용어】 ▸ Auto Scaling Group — EC2 인스턴스 수를 자동으로 조정하는 AWS 서비스 ▸ DynamoDB Auto Scaling — 트래픽에 따라 프로비저닝된 용량을 동적으로 조정 【정답 포인트】 ▸ 최소 개발 노력 → 아키텍처 재구성(Lambda 마이그레이션)이 필요 없음 ▸ Auto Scaling Group + DynamoDB Auto Scaling 조합이 가장 간단 ▸ 기존 EC2 인스턴스 기반 아키텍처를 유지하며 자동 확장성 추가 ▸ 개발 코드 변경이 최소화됨 【오답 체크】 (A) (B) Lambda 마이그레이션은 중대한 개발 노력이 필요하고, 시험에서 '최소 개발 노력'이라는 조건을 명시적으로 위배 (D) SQS와 Lambda 추가는 불필요한 복잡성을 더하고, 읽기 성능 개선에는 기여하지 못함 【시험 포인트】 '최소 개발 노력' 키워드 → 기존 아키텍처 유지 → Auto Scaling이 정답 EC2 + ALB 기반 구조에서는 Auto Scaling이 자연스러운 확장 방식

해설

【핵심 용어】 ▸ AWS Application Discovery Service — 온프레미스 서버 인벤토리와 성능 데이터 수집 도구 ▸ Agentless Discovery — 네트워크 기반 검색 (하지만 프로세스 정보 수집 불가) ▸ Agent-based Discovery — 소프트웨어 에이전트 설치하여 상세한 메트릭 수집 【정답 포인트】 ▸ 요구사항: 프로세스 인벤토리, CPU/메모리/디스크, 네트워크 연결 매핑 ▸ Agent-based Discovery만이 모든 정보를 수집 가능 ▸ Application Discovery Service는 AWS 마이그레이션 평가 전문 도구 ▸ 비용 효율적 — 수집 데이터를 AWS에 제공하면 무료 사용 가능 【오답 체크】 (B) CloudWatch는 기본적으로 인스턴스 내 프로세스 리스트를 수집하지 못함 (C) Agentless는 IP 통신만 감지 가능, 프로세스 상세정보 불가 (D) Application Discovery Service 자체는 VPN 스캔 불필요, 에이전트 기반 수집 필요 【시험 포인트】 AWS 마이그레이션 '평가' 단계 → Application Discovery Service 선택 Agent-based vs Agentless → 프로세스 정보 필요 → Agent-based

해설

【핵심 용어】 ▸ AWS Global Accelerator — 정적 고정 IP를 제공하는 네트워크 서비스 ▸ CloudFront — 콘텐츠 캐싱 중심, IP 주소는 엣지 로케이션 범위 (변동가능) ▸ Anycast — 가장 가까운 리전으로 트래픽 자동 라우팅 【정답 포인트】 ▸ '정적 IP 주소' 요구 → Global Accelerator만 가능 ▸ Global Accelerator는 2개의 고정 anycast IP 제공 ▸ 지리적 근처성 라우팅 → Global Accelerator의 기본 기능 ▸ 다중 리전 지원 → 표준 가속기(Standard Accelerator) 【오답 체크】 (A) (C) CloudFront IP 범위는 고정이 아니며 자주 변경되어 허용 목록 유지 곤란 (A) (C) CloudFront는 콘텐츠 캐싱 서비스, NLB 뒤의 동적 콘텐츠에 부적합 (D) Custom Routing은 UDP 게임, IoT 같은 포트 기반 라우팅용 (과도함) 【시험 포인트】 '정적 IP 주소' + '다중 리전' → Global Accelerator 표준 가속기 Global Accelerator vs CloudFront 구분: IP 고정성이 핵심

해설

【핵심 용어】 ▸ STS Session Tags — 페더레이션 로그인 시 세션에 추가되는 속성 (자동으로 PrincipalTag 됨) ▸ StringNotEquals 조건 — 특정 값이 아닌 경우만 작업 허용 ▸ Resource Tags vs Principal Tags — 리소스의 태그 vs 사용자 세션의 태그 【정답 포인트】 ▸ 공통 프로덕션 계정에서 각 부서 간 격리 필요 ▸ 거부 정책(Deny)은 명시적으로 권한 거부 → 안전한 기본값 ▸ STS 세션 태그는 SAML 페더레이션에서 자동 전파 ▸ StringNotEquals 조건으로 자신의 부서 이외의 인스턴스 작업 거부 ▸ IAM 역할 정책이 아닌 거부 정책은 모든 권한을 우선 차단 【오답 체크】 (A) SCP는 조직 정책이지만 OU가 계정별로 다르면 공통 프로덕션 계정 제어 불가 (C) 허용 정책은 다른 부서 인스턴스 편집을 막을 수 없음 (요구사항 불충족) (D) 정책 관리의 운영 오버헤드가 크고, 부서별 이름 변경 시 유지보수 곤란 【시험 포인트】 공통 계정 + 부서별 격리 → STS 세션 태그 + 거부 정책 StringEquals vs StringNotEquals → NotEquals = 거부 정책 → 더 안전

해설

【핵심 용어】 ▸ AWS Service Catalog — 사전 승인된 제품을 통한 셀프 서비스 프로비저닝 ▸ TagOption Library — 필수 태그 템플릿 관리 ▸ Launch Constraints — 서비스 카탈로그 제품 시작 시 제약 조건 【정답 포인트】 ▸ B: Service Catalog 중앙 관리 + Organizations 배포 → 최소 권한 제어 ▸ D: 로컬 계정에 포트폴리오 복제 + Launch Constraints → 분산 배포 + 제약 ▸ E: TagOption Library → 태그 강제 시행 중심 도구 ▸ 세 옵션 조합: 중앙 통제 + 분산 배포 + 태그 강제 【오답 체크】 (A) S3 버킷 + IAM 정책은 버전 관리/승인 프로세스 없음 (최소 권한 미충족) (C) CloudFormationFullAccess는 최소 권한 원칙 위배, SCP는 모든 권한 거부만 가능 (F) CloudFormation Resource Tags는 태그 강제가 아니라 선택적 기능 【시험 포인트】 중앙 + 분산 + 태그 강제 → Service Catalog 기반 아키텍처 TagOption = 서비스 카탈로그 태그 관리의 핵심 도구

해설

【핵심 용어】 ▸ Partition Projection — S3 데이터를 계층적으로 분할하여 쿼리 범위 축소 ▸ Partition Pruning — Athena가 필요한 파티션만 스캔하는 최적화 ▸ S3 Select — 파일 필터링으로 스캔량 감소 【정답 포인트】 ▸ 문제: 데이터 증가하면서 Athena가 모든 데이터 스캔 → 시간 증가 ▸ 해결: 파티셔닝 구조 도입 (date/time별) → 필요한 파일만 스캔 ▸ Kinesis Firehose 파티셔닝 + Athena 파티션 쿼리 필수 ▸ 최소 운영 오버헤드 — Athena 파티션 자동 인식 【오답 체크】 (A) Lambda 통합은 운영 오버헤드 증가, 비용 상승 (B) 버킷 분리만으로는 쿼리 성능 개선 안 됨 (C) Redshift Spectrum은 과도하고 복잡성 증가 【시험 포인트】 Athena + 증가하는 데이터 → 파티셔닝 표준 솔루션 S3 계층 구조 (year/month/day) → Athena 쿼리 최적화의 핵심

해설

【핵심 용어】 ▸ AWS WAF Geo-Blocking — IP 지역 기반 차단 규칙 ▸ AWS Managed Rule Group — AWS 유지보수 IP 지오로케이션 데이터 ▸ IPSet vs Geo-Matching — 정적 IP 리스트 vs 동적 국가 기반 필터 【정답 포인트】 ▸ 최소 유지보수 → AWS 관리 국가/IP 데이터 사용 ▸ WAF Geo-Blocking 규칙은 AWS가 IP 범위 자동 업데이트 ▸ 로깅 가능 → WAF 자동 로그를 CloudWatch/S3로 전송 ▸ 간단한 구현 — 규칙 설정만으로 완료 【오답 체크】 (A) IPSet은 수동 IP 범위 관리 필요 → 유지보수 오버헤드 큼 (A) 국가별 IP 범위 변경 시 IPSet 지속 수정 필요 (C) AWS Shield는 DDoS 방어용, 지역 차단 기능 없음 (D) Security Group은 ALB 수준 제어 (WAF보다 낮은 계층), 로깅 부족 【시험 포인트】 '최소 유지보수' → AWS 관리 기능 → WAF Geo-Blocking 국가별 필터링 = WAF의 기본 기능 (IPSet 대신 국가 코드)

해설

【핵심 용어】 ▸ AWS DataSync — AWS 서비스 간 대규모 데이터 전송 (자동 검증, 병렬 처리) ▸ PrivateLink — VPC 엔드포인트를 통한 프라이빗 연결 ▸ VPC Peering — 리전 간 VPC 직접 연결 【정답 포인트】 ▸ '공개 인터넷 미사용' → VPN/PrivateLink 같은 프라이빗 채널 필수 ▸ AWS 관리 서비스 → DataSync (자동 최적화) ▸ 크로스 리전 → VPC 피어링 사용 가능 ▸ DataSync는 VPC 엔드포인트(PrivateLink) 지원 → 완전 프라이빗 【오답 체크】 (A) FSx File Gateway는 S3로 백업하는 서비스 (다른 FSx 동기화 불가) (B) VPN은 암호화되지만, DataSync는 VPN 엔드포인트 지원 불가 (복잡함) (D) Transit Gateway + Transfer Family는 과도하고 복잡 (D) Transfer Family는 SFTP/FTP 프로토콜 기반 (DataSync보다 기능 제한) 【시험 포인트】 FSx 크로스 리전 DR → DataSync + VPC 피어링 + PrivateLink 조합 DataSync = AWS 서비스 간 데이터 동기화의 표준 도구

해설

【핵심 용어】 ▸ RPO (Recovery Point Objective) — 허용 가능한 최대 데이터 손실 시간 (5분) ▸ RTO (Recovery Time Objective) — 허용 가능한 복구 시간 (10분) ▸ 크로스 리전 읽기 복제본 — 거의 실시간 동기화 【정답 포인트】 ▸ RPO 5분 < RDS 읽기 복제본 동기화 지연 (초 단위) ✓ ▸ RTO 10분 < 읽기 복제본 승격 시간 (분 단위) ✓ ▸ 가장 낮은 비용 → RDS 읽기 복제본 (Aurora 글로벌 DB보다 저렴) ▸ 10 TB 데이터 → 모든 옵션 용량 충분 【오답 체크】 (A) 스냅샷 5분 간격은 RPO 달성하지만 RTO 불가 (복사+복원 시간 과다) (C) Aurora 글로벌 DB는 비용 높음, DMS는 동기화 지연 발생 가능 (D) 같은 리전 복제본은 크로스 리전 DR 불가 【시험 포인트】 RTO < 10분 → 읽기 복제본 승격 (가장 빠름) RPO < 5분 → 거의 실시간 동기화 필요 RDS 읽기 복제본 >> Aurora 글로벌 DB (비용 관점)

해설

【핵심 용어】 ▸ OrganizationAccountAccessRole — AWS Organizations에서 자동 생성되는 역할 ▸ Role Assumption — STS AssumeRole을 통한 계정 간 권한 위임 ▸ Cross-Account Access — 다른 계정의 리소스 접근 【정답 포인트】 ▸ AWS Organizations 멤버 계정 생성 시 자동으로 OrganizationAccountAccessRole 생성 ▸ 관리 계정 사용자는 이 역할을 가정(Assume)하여 멤버 계정 접근 가능 ▸ Support1 IAM 사용자가 역할 전환하면 멤버 계정의 관리자 권한 획득 ▸ 베스트 프랙티스 — 루트 계정 대신 IAM 사용자 사용 【오답 체크】 (A) 루트 사용자 자격증명 사용은 보안 위험 (베스트 프랙티스 위배) (C) finance@example.com은 멤버 계정 루트 사용자이지만, 초기 암호는 전혀 받지 않음 (D) Support1은 관리 계정 IAM 사용자, 멤버 계정에서 직접 로그인 불가 【시험 포인트】 AWS Organizations + 새 멤버 계정 → OrganizationAccountAccessRole 즉시 사용 Role Assumption = Organizations 계정 관리의 핵심

해설

【핵심 용어】 ▸ API Gateway Caching — HTTP GET 요청 결과 캐시 ▸ Edge-Optimized Endpoint — CloudFront 엣지 로케이션에서 요청 처리 ▸ Regional Endpoint — 리전 내 처리만 지원 【정답 포인트】 ▸ 문제: 동일 쿼리 반복 → HTTP GET 응답 캐싱으로 해결 ▸ API Gateway 캐싱은 Regional/Edge-Optimized 모두 지원 ▸ Edge-Optimized = CloudFront 통합 → 글로벌 캐싱 → 더 나은 성능 ▸ 비용 절감 → 데이터베이스 쿼리 감소 → Lambda 메모리/시간 감소 【오답 체크】 (B) ElastiCache는 추가 비용 발생, API Gateway 캐싱보다 복잡 (C) 메모리 증가는 근본 원인(반복 쿼리) 해결 못함 (D) 스로틀링은 유효한 요청 거부 → 비즈니스 영향 【시험 포인트】 API Gateway 캐싱 = 중복 GET 요청 최적화의 표준 Edge-Optimized = 글로벌 배포 + CloudFront 성능 추가

해설

【핵심 용어】 ▸ AWS DMS — 온프레미스 DB를 AWS로 마이그레이션하는 전문 서비스 ▸ Change Data Capture(CDC) — 마이그레이션 후 증분 변경사항 반영 ▸ Private VIF — Direct Connect를 통한 AWS 프라이빗 네트워크 접근 【정답 포인트】 ▸ '지속적으로 업데이트되는 데이터' → CDC 필요 (Full Load + CDC) ▸ '최소 다운타임' → DMS가 온라인 마이그레이션 지원 ▸ '인터넷 미사용' → Private VIF로 Direct Connect 사용 ▸ VPC 엔드포인트 → AWS 서비스 간 프라이빗 통신 ▸ 5 TB 데이터 → DMS가 대용량 데이터 효율적 처리 【오답 체크】 (A) Snowball은 일회성 마이그레이션, 지속적 업데이트 반영 불가 (C) DataSync는 AWS 내부 서비스 간 전송, 온프레미스 DB 지원 안 함 (D) S3 File Gateway는 파일 스토리지용, 데이터베이스 마이그레이션 부적합 【시험 포인트】 온프레미스 DB → AWS DB 마이그레이션 = DMS 표준 솔루션 Full Load + CDC = 다운타임 최소화의 핵심 Direct Connect Private VIF = 프라이빗 전송 보장

해설

【핵심 용어】 ▸ EFS General Purpose — 기본 성능, 일반적인 워크로드용 ▸ EFS Max I/O — 높은 처리량, 병렬 요청 최적화 ▸ POSIX Compliance — Unix/Linux 파일 시스템 표준 【정답 포인트】 ▸ '높은 수준의 처리량' → Max I/O 성능 모드 필수 ▸ '공통 기본 파일 스토리지' → 공유 스토리지 필요 (EBS 불가) ▸ 'POSIX 호환' → EFS 지원 (Storage Gateway는 제한적) ▸ '다중 가용 영역' → EFS 자동 구간 복제 ▸ 빅 데이터 분석 = 높은 병렬 I/O → Max I/O 【오답 체크】 (A) Storage Gateway는 처리량 제한, S3 백엔드는 POSIX 완전 미지원 (B) General Purpose는 처리량 부족 (최대 7,000 파일 작업/초) (C) EBS는 단일 인스턴스만 연결 가능, 모든 노드 공유 불가 【시험 포인트】 EFS 성능 모드: General Purpose vs Max I/O '높은 처리량' + '다중 노드' → Max I/O 필수 빅 데이터 분석 = Max I/O 정답

해설

【핵심 용어】 ▸ Aurora Global Database — 다중 리전 읽기 복제본 (< 1초 지연) ▸ RTO 5분 < RPO 1분 → 기존 데이터의 최소 손실 필수 ▸ Active-Passive — 주 리전만 활성, 보조 리전은 대기 【정답 포인트】 ▸ RPO 1분 → 거의 실시간 동기화 필요 → Aurora 글로벌 DB 필수 ▸ RTO 5분 → 대상 리전 사전 배포 + 빠른 전환 ▸ 표준 Aurora MySQL = Aurora Serverless 기능 포함 ▸ Active-Passive = 재해 시 빠른 장애 조치 ▸ AWS SAM 런북은 옵션 (배포 자동화 없어도 가능) 【오답 체크】 (A) 읽기 복제본 승격은 느림 (5분 초과 가능), RPO도 1분 미만 달성 어려움 (B) 글로벌 DB만으로는 애플리케이션(API, Lambda) 배포 미비 (C) 다중 쓰기는 Aurora 글로벌 DB의 기능 아님, 비용 증가 【시험 포인트】 RPO 1분 = Aurora 글로벌 데이터베이스 필수 RTO 5분 = 사전 배포 + Active-Passive 구성 Serverless 애플리케이션 DR = 통합 솔루션 필요

해설

【핵심 용어】 ▸ DynamoDB Accelerator(DAX) — DynamoDB 전용 캐시 ▸ Scheduled Scaling — 예정된 시간에 자동 스케일링 ▸ Application Load Balancer — HTTP/HTTPS 기반 로드 분산 ▸ CloudFront — 콘텐츠 캐싱 (동적 데이터에는 부적합) 【정답 포인트】 ▸ '연 4회 예측 가능한 콘텐츠 업데이트' → 예약된 스케일링 최적 ▸ DynamoDB 캐시 필요 → DAX (Redis 자체 호스팅 대체) ▸ '자동' 스케일링 + '예약된' 스케일링 조합 (만약의 사태) ▸ ALB = 동적 콘텐츠 로드 분산 적합 ▸ Route 53 단순 라우팅 = ALB로의 직접 라우팅 【오답 체크】 (B) CloudFront는 콘텐츠 캐싱, 콘텐츠 업데이트 시 캐시 무효화 복잡 (B) 수동 확장은 자동화 불가 (예약 스케일링 미지원) (C) Memcached는 DynamoDB 전문 캐시 아님 (DAX 미지원 기능) (D) CloudFront + 수동 확장 = 신뢰성 및 자동화 미흡 【시험 포인트】 예측 가능한 부하 = 예약된 스케일링 (Scheduled Scaling) DynamoDB + 자체 Redis → DAX 로 통합 ALB + DAX = 동적 데이터 최적 아키텍처

해설

【핵심 용어】 ▸ S3 Event Notifications — 버킷 이벤트 기반 메시지 생성 ▸ Amazon SQS — 분산 애플리케이션의 메시지 큐 (비동기 처리) ▸ AWS Lambda — 이벤트 기반 서버리스 컴퓨팅 ▸ Amazon SNS — 푸시 알림 서비스 【정답 포인트】 ▸ B: S3 직접 업로드 + SQS 표준 큐 → 확장 가능한 수신 ▸ C: Lambda 함수 → SQS 메시지 기반 이미지 처리 (비용 효율) ▸ E: SNS → 모바일 앱 푸시 알림 전송 ▸ 조합: 업로드 → 큐 → 처리 → 알림 【오답 체크】 (A) Amazon MQ는 오버헤드 높음 (SQS보다 복잡/비쌈) (D) S3 Batch Operations는 대기열 기반 처리 불가 (수동 작업용) (F) SES는 이메일 서비스, 푸시 알림용이 아님 (SNS 사용) 【시험 포인트】 S3 업로드 스파이크 → SQS 큐잉 → Lambda 비동기 처리 표준 패턴 SNS = 모바일 앱 푸시 알림 표준 도구

해설

【핵심 용어】 ▸ AWS Client VPN — 클라이언트 소프트웨어 기반 VPN (개인 기기 접근) ▸ VPC Endpoint — VPC 내 AWS 서비스 프라이빗 액세스 ▸ Bastion Host — SSH 터널링 (보안상 제한적) 【정답 포인트】 ▸ '집/3개 사무실' 위치 → 다양한 네트워크 환경 필요 → Client VPN ▸ 'OpenSearch Service 분석/시각화' → 직접 액세스 필요 ▸ Client VPN = 클라이언트 설치 후 셀프 서비스 (관리 용이) ▸ VPC 내 데이터 보호 → VPC 엔드포인트 자동 지원 【오답 체크】 (B) Site-to-Site VPN은 고정 네트워크 게이트웨이 필요 (가정/사무실 모두 불편) (C) Direct Connect는 장기 계약, 기업 네트워크용 (개인 근무 부적합) (D) Bastion Host는 제한적이며 OpenSearch 직접 UI 접근 불가 【시험 포인트】 다중 원격 위치 + 프라이빗 AWS 서비스 → Client VPN 표준 솔루션 Client VPN = 개인 기기 최적화 Site-to-Site = 고정 네트워크 게이트웨이 (사무실용)

해설

【핵심 용어】 ▸ awsvpc Network Mode — 각 작업이 별도의 ENI를 가짐 (보안 그룹 적용 가능) ▸ Task IAM Role — 작업 수준의 권한 (최소 권한) ▸ Bridge Network Mode — EC2 인스턴스 수준 네트워킹 (과도한 권한) 【정답 포인트】 ▸ B: awsvpc 네트워크 모드 → 작업별 보안 그룹 + ENI 격리 ▸ E: Task IAM Role → 컨테이너 내 자격증명 안전 (비노출) ▸ 최소 권한 원칙 → 작업 단위 세분화 필수 【오답 체크】 (A) Bridge 모드는 EC2 인스턴스 수준 제어 (작업별 격리 불가) (C) EC2 인스턴스 수준 IAM은 모든 작업에 동일 권한 (최소 권한 위배) (D) 컨테이너 내 자격증명 전달은 노출 위험 (Task IAM Role 미지원) 【시험 포인트】 ECS + 최소 권한 = awsvpc 모드 + Task IAM Role Bridge = EC2 수준 (구세대), awsvpc = 작업 수준 (현대식)

해설

【핵심 용어】 ▸ VPC Lambda — 람다 함수가 VPC 내 리소스 접근 ▸ VPC Endpoint — VPC 내에서 AWS 서비스 접근 (NAT 불필요) ▸ Cross-VPC Access — VPC 피어링 또는 엔드포인트 【정답 포인트】 ▸ B: Lambda VPC 배포 (프라이빗 서브넷) → Neptune 직접 접근 가능 ▸ E: Lambda VPC 배포 + DynamoDB 엔드포인트 → VPC 내 완전 격리 ▸ NAT 게이트웨이 = DynamoDB는 지역 서비스라 불필요 (VPC 엔드포인트) 【오답 체크】 (A) 공개 서브넷은 보안 위험 (Lambda 프라이빗화 권장) (C) VPC 외부 Lambda는 Neptune 보안 그룹 정책만으로 접근 불가 (VPC 내 필수) (D) Neptune VPC 엔드포인트는 없음 (DB는 인스턴스 기반 접근) (D) VPC 외부 Lambda는 DynamoDB 접근 가능하지만 Neptune은 불가 【시험 포인트】 Serverless + VPC 리소스 → Lambda VPC 배포 필수 DynamoDB = 글로벌 서비스 → VPC 엔드포인트 사용 Neptune = VPC 인스턴스 → 같은 VPC 또는 피어링 필요