정답 · 해설

해설

【핵심 용어】 ▸ Warm Pools — 미리 초기화된 인스턴스를 대기 상태로 유지하여 즉시 사용 가능 ▸ Lifecycle Hooks — Auto Scaling 이벤트 중 사용자 정의 작업 수행 ▸ Warm-Up Time — 인스턴스가 트래픽을 처리할 준비가 완료되는 시간 【정답 포인트】 ▸ Warm Pools: 미리 초기화된 인스턴스로 즉시 제공 (사용자 데이터 스크립트 미리 실행) ▸ Lifecycle Hooks: Warm Pools에서 Running 상태로 전환할 때 스크립트 재실행 ▸ Dynamic Scaling: 피크 시간 즉시 대응 【오답 체크】 (A) Predictive Scaling는 과거 패턴 기반 (피크 시간 즉시 대응 불가) / Instance Maintenance Policy는 AWS 관리용 (B) Lifecycle Hooks만으로는 사전 초기화 미불가 (C) Predictive Scaling + Instance Maintenance는 요구사항 미충족 【시험 포인트】 ▸ 콜드 스타트 제거 패턴: Warm Pools + Lifecycle Hooks ▸ 동적 vs 예측: 피크 시간대 즉시 대응 필요 → Dynamic Scaling

해설

【핵심 용어】 ▸ AWS Schema Conversion Tool(SCT) — 이기종 DB 간 스키마/저장 프로시저 변환 분석 ▸ AWS Database Migration Service(DMS) — 실제 데이터 마이그레이션 수행 ▸ Migration Evaluator — 온프레미스 환경 규모 평가 (라이선스, 비용) 【정답 포인트】 ▸ (C) SCT: 다양한 DB(SQL Server, MySQL, Oracle) 간 스키마 호환성 분석 및 변환 ▸ (D) DMS: SCT 분석 후 실제 데이터 마이그레이션 (CDC 지원) 【오답 체크】 (A) Migration Evaluator는 규모 평가용, 저장 프로시저 분석 아님 (B) AWS Application Migration Service는 서버(EC2) 마이그레이션용, DB 분석 아님 (E) DataSync는 파일 스토리지 동기화용, 데이터베이스 마이그레이션 아님 【시험 포인트】 ▸ 이기종 DB 마이그레이션 순서: SCT(분석) → DMS(실행) ▸ 도구 선택: 목적별 명확한 구분 (평가 vs 분석 vs 마이그레이션)

해설

【핵심 용어】 ▸ Amazon EFS — VPN을 통해 온프레미스에서 마운트 가능한 NAS 대체재 ▸ AWS Snowball Edge — 대용량(>100TB) 데이터 전송에 최적 ▸ Real-time Sync — EFS가 온프레미스 NAS와 실시간 동기화 지원 【정답 포인트】 ▸ (C) EFS: 온프레미스 서버와 EC2 양쪽에 마운트 가능 (VPN 기반 NAS 대체) 실시간 콘텐츠 업데이트 지원 (Lambda 배치 작업 불필요) ▸ (D) Snowball Edge: 200TB 보관 데이터 고속 전송 (EFS는 온라인 구간 활용) 【오답 체크】 (A) Lambda 주간 배치는 실시간 업데이트 요구사항 미충족 (B) EBS Multi-Attach는 온프레미스 NAS와 연결 불가 (E) Snowcone은 용량 작음 (최대 14TB, 200TB 부적합) 【시험 포인트】 ▸ 온프레미스 NAS → EFS: VPN을 통한 마운트 + 실시간 동기화 ▸ 대용량 데이터: Snowball Edge 선택 (EFS는 온라인 프로토콜 활용)

해설

【핵심 용어】 ▸ AWS Elastic Beanstalk — Tomcat/Java 애플리케이션 배포에 최적화된 PaaS ▸ Amazon RDS for PostgreSQL — 관리형 데이터베이스 (운영 오버헤드 최소) ▸ Least Operational Overhead — 관리형 서비스 우선 【정답 포인트】 ▸ Elastic Beanstalk: JAR 파일 직접 배포 가능, Auto Scaling 내장 ▸ RDS PostgreSQL: 관리형 DB (패치, 백업, 복제 자동) ▸ CloudFront + ALB: 콘텐츠 배포 및 로드 밸런싱 ▸ 전체 관리형 솔루션으로 운영 오버헤드 최소화 【오답 체크】 (A) EC2 + EFS + Step Functions는 운영 복잡도 높음 (B) EKS는 컨테이너 오케스트레이션 오버헤드 (리팩터링도 필요) (C) Python 리팩터링은 요구사항 위반 (JAR 배포 필수) / DynamoDB는 SQL 미지원 【시험 포인트】 ▸ 운영 오버헤드 최소화: 관리형 서비스(PaaS) > 셀프 관리(IaaS) ▸ 레거시 Tomcat 애플리케이션: Elastic Beanstalk + RDS 조합이 최적

해설

【핵심 용어】 ▸ AWS IoT Core — MQTT 메시지 브로커 (확장성, 보안) ▸ Amazon DocumentDB — MongoDB 호환 관리형 DB ▸ AWS Step Functions — 장기 실행 워크플로우 조율 ▸ AWS Lambda — 서버리스 함수 【정답 포인트】 ▸ (A) Step Functions + Lambda: 120~600초 작업에 적합 (Lambda 15분 제한 내) S3 + CloudFront: 보고서 제공 (일반인 액세스) ▸ (D) AWS IoT Core + Lambda: MQTT 장치 수집 최적화 ▸ (E) DocumentDB: MongoDB 호환, 관리형, 운영 오버헤드 최소 【오답 체크】 (B) Lambda 레이어로 메시지 임시 저장은 SQS보다 부적절 (C) EKS는 운영 오버헤드 높음 (관리형 아님) (F) EC2 MongoDB는 운영 복잡도 증가 【시험 포인트】 ▸ IoT 플랫폼: AWS IoT Core (MQTT 브로커) → Lambda → DocumentDB 패턴 ▸ 보고서 생성: Step Functions (장기 실행) + S3 + CloudFront

해설

【핵심 용어】 ▸ API Gateway Usage Plan — API 키당 throttling 및 quota 제한 ▸ Throttling — 초당 요청 수 제한 ▸ Quota — 일정 기간 내 총 요청 수 제한 【정답 포인트】 ▸ 사용량 제한이 목표: 비용 제어 + 악용 방지 ▸ Usage Plan: 단일 API 키에 대한 명확한 제한 정의 ▸ 구현 간단: Lambda 함수 수정 불필요 ▸ 비용 효율적: WAF 구독 없음 (Usage Plan은 기본 기능) 【오답 체크】 (A) SQS는 사용량 제한이 아닌 비동기 처리 (여전히 초과 비용 가능) (B) Provisioned Concurrency는 비용 증가 (피크 시간 고정 비용) (C) WAF의 rate-based 규칙은 정교하지만, 실제 요청 수 제한 아님 (차단만 함) 【시험 포인트】 ▸ API Gateway 비용 제어: Usage Plan + Throttling이 표준 ▸ 외부 개발 팀 제어: API 키 + Usage Plan 조합

해설

【핵심 용어】 ▸ Mountpoint for Amazon S3 — S3 버킷을 로컬 파일 시스템처럼 마운트 ▸ Real-time Access — 매번 다운로드 없이 실시간 최신 파일 접근 ▸ Cost-Effective — 스토리지 비용 최소화 【정답 포인트】 ▸ 문제: 인스턴스 시작 시만 다운로드하므로 오래된 가격 사용 ▸ 해결책: Mountpoint for S3로 항상 최신 파일에 접근 ▸ 비용: 다운로드 매번 불필요, S3 액세스만 비용 발생 【오답 체크】 (A) DynamoDB: 대규모 스캔/조회에는 적합하지만 가격 책정 파일 동기화 복잡 (B) EFS: 멀티파트 업로드 스크립트 필요 (운영 복잡도 증가) (D) EBS Multi-Attach: EC2 간 공유만 가능 (시작 시 업데이트 여전히 필요) 【시험 포인트】 ▸ S3 실시간 액세스: Mountpoint가 최신 솔루션 ▸ 가격 책정 데이터: 주기적 업데이트 + 즉시 반영 → Mountpoint 최적

해설

【핵심 용어】 ▸ AWS Service Catalog — 승인된 제품에 대한 제한된 셀프 서비스 배포 ▸ Launch Constraint — 제품 배포 시 사용할 IAM 역할 ▸ Least Privilege — 최소 권한 원칙 【정답 포인트】 ▸ Service Catalog: 관리자가 제품 정의, 사용자는 Service Catalog API만 호출 ▸ Launch Constraint: 제품 배포 시 미리 정의된 역할 자동 사용 ▸ 사용자는 과도한 권한 없이 승인된 제품만 배포 가능 【오답 체크】 (A) S3 + CloudFormation 직접 사용: 사용자가 CloudFormation API 호출 권한 필요 (과도한 권한) (C) 조건부 권한도 여전히 CloudFormation 호출 가능 (리스크) (D) Elastic Beanstalk는 CloudFormation 템플릿 기반 환경에 맞지 않음 【시험 포인트】 ▸ 권한 제어 + 셀프 서비스: Service Catalog 필수 ▸ Launch Constraint: 사용자 권한과 독립적인 배포 역할 지정

해설

【핵심 용어】 ▸ CloudFormation — IaC를 통한 리전 간 일관된 배포 ▸ DynamoDB Streams — 글로벌 테이블 전제 조건 ▸ Latency-based Routing — 사용자 근처의 리전으로 자동 라우팅 【정답 포인트】 ▸ (A) CloudFormation: Region 매개변수로 두 번째 리전에 동일 인프라 배포 ▸ (D) Latency-based Routing: 사용자가 지연 시간 최소인 리전으로 자동 라우팅 ▸ (E) DynamoDB Global Table: Streams 활성화 후 기존 테이블에서 글로벌화 (재생성 불필요) 【오답 체크】 (B) 수동 콘솔 작업은 오류 가능성 + 관리 오버헤드 증가 (C) Weighted Routing은 지역 간 균등 분배 (지연 시간 고려 안 함) (F) 기존 테이블 재생성은 불필요 (E로 충분) 【시험 포인트】 ▸ 다중 리전 재해 복구: CloudFormation + DynamoDB Global Table 패턴 ▸ Route 53 라우팅 정책: Latency-based가 사용자 경험 최적화

해설

【핵심 용어】 ▸ IAM Identity Center Permission Set — 조건부 S3 버킷 접두사 액세스 제어 ▸ ${aws:PrincipalTag/userName} — 사용자별 폴더 자동 제한 ▸ CloudTrail Data Events — S3 객체 액세스 기록 【정답 포인트】 ▸ (A) Identity Center 권한 집합: 사용자 태그 기반 S3 접두사 제한 (사용자 간 격리) ▸ (C) CloudTrail 데이터 이벤트: S3 객체 액세스 기록 (GET/PUT 추적) Athena: CloudTrail 로그 쿼리 → 월간 접근 보고서 생성 【오답 체크】 (B) 역할 기반 접근: 접두사 제한 없음 (사용자 간 격리 실패) (D) 관리 이벤트는 S3 구성 변경만 기록 (객체 액세스 미추적) (E) EMRFS는 Hadoop 파일 시스템 (S3 접근 로깅용 아님) 【시험 포인트】 ▸ 다중 사용자 S3 격리: Identity Center 권한 집합 + 태그 기반 조건 ▸ 액세스 감시: CloudTrail 데이터 이벤트 + Athena 분석

해설

【핵심 용어】 ▸ AWS Fargate — 서버리스 컨테이너 오케스트레이션 ▸ AWS Lambda — 이벤트 기반 함수 (컨테이너 선택 논리) ▸ S3 Event Notification — EFS 폴링 대체 ▸ Lambda 함수 제한 — 15분 (2시간 작업 불가) 【정답 포인트】 ▸ Fargate: 2시간 컨테이너 작업에 적합 (Lambda 15분 제한 초과) ▸ Lambda: 컨테이너 선택 논리만 실행 (빠름) ▸ S3: EFS 폴링 제거 (이벤트 기반으로 전환) ▸ 조합: Lambda(선택) → Fargate(처리) → S3(쓰기) 【오답 체크】 (A) EventBridge는 EFS 파일 추가 감지 불가 (B) EFS는 EFS 이벤트 알림 미지원 (S3 이벤트 있음) (D) Lambda 15분 제한 (2시간 작업 불가) 【시험 포인트】 ▸ 장기 실행 컨테이너: Fargate (제한 없음) ▸ 단기 로직: Lambda (이벤트 트리거) ▸ EFS → S3 전환: 이벤트 기반 아키텍처 구현

해설

【핵심 용어】 ▸ AWS Storage Gateway File Gateway — 온프레미스 NAS를 S3로 투명하게 연결 ▸ Amazon Rekognition — 비디오 분석, 얼굴 인식 ▸ AWS Direct Connect — 고속 온프레미스-AWS 연결 【정답 포인트】 ▸ File Gateway: MAM이 기존처럼 파일 공유 접근 (투명한 마이그레이션) ▸ Direct Connect: 온프레미스-S3 고속 전송 ▸ Rekognition: 파일 게이트웨이 지원 S3에서 비디오 분석 ▸ Lambda: 메타데이터 추출 및 MAM 업데이트 (최소 운영) 【오답 체크】 (B) Tape Gateway: 테이프 아카이브 용 (비디오 스트림 처리 적합하지 않음) (C) Kinesis Video Streams: 실시간 스트리밍용 (배치 보관 데이터 부적합) (D) EC2 + OpenCV: 운영 오버헤드 높음, 직접 처리 【시험 포인트】 ▸ 30TB 보관 데이터 + MAM 연계: File Gateway + Rekognition 패턴 ▸ 최소 운영 + 투명한 마이그레이션: Storage Gateway 필수

해설

【핵심 용어】 ▸ Reserved Instances (RI) — EC2 특정 인스턴스 타입/리전 할인 ▸ Compute Savings Plans — EC2, Lambda, Fargate 유연한 할인 ▸ All Upfront vs No Upfront — 결제 방식에 따른 할인율 (All Upfront 최대) 【정답 포인트】 ▸ 기존 RI 만료: 동일 조건 3년 RI All Upfront 갱신 (최대 할인) ▸ 새로운 서버리스: Compute Savings Plan (EC2 외 Lambda/Fargate 포함) ▸ 조직 차원: 관리 계정에서 구매 (모든 구성원 계정에 적용 가능) ▸ All Upfront: No Upfront보다 20~30% 더 할인 【오답 체크】 (B) 1년은 3년보다 할인 낮음 / 구성원 계정 개별 구매는 할인 축약 (C) No Upfront는 All Upfront보다 할인 낮음 (D) EC2 Instance Plan은 Lambda/Fargate 미포함 (서버리스 미커버) 【시험 포인트】 ▸ 비용 최적화 순서: RI 갱신(이미 사용 중) → 추가 컴퓨팅에 Savings Plan ▸ 조직 구매: 관리 계정에서 전체 할인 극대화

해설

【핵심 용어】 ▸ S3 Multi-Region Access Points — 여러 리전에 걸친 S3 자동 라우팅 ▸ AWS PrivateLink — VPC 내 AWS 서비스 접근 (공개 인터넷 노출 제거) ▸ AWS Direct Connect — 온프레미스-AWS 전용 네트워크 연결 【정답 포인트】 ▸ (A) S3 Multi-Region Access Points: 지리적으로 가장 가까운 리전으로 자동 라우팅 ▸ (E) PrivateLink + Direct Connect: 온프레미스에서 공개 인터넷 없이 접근 ▸ 조합: Multi-Region AP(성능 + 신뢰성) + PrivateLink+Direct Connect(보안) 【오답 체크】 (B) CRR: 복제만 하고 라우팅은 자동 아님 (C) Lambda: 리전 라우팅 추적은 성능/신뢰성 개선 아님 (D) Site-to-Site VPN: 공개 인터넷 사용 (요구사항 위반) 【시험 포인트】 ▸ 다중 리전 성능: S3 Multi-Region Access Points 필수 ▸ 프라이빗 접근: PrivateLink + Direct Connect 조합

해설

【핵심 용어】 ▸ AWS Application Migration Service (MGN) — VM 마이그레이션을 위한 에이전트리스 서비스 ▸ AWS Snowcone — 오프라인 데이터 전송용 엣지 디바이스 ▸ FSx for Windows File Server — Windows 네이티브 공유 파일 시스템 【정답 포인트】 ▸ 빠른 마이그레이션 + 100GB+ 파일 공유 → Snowcone의 오프라인 전송이 네트워크 대역폭 제약을 우회 ▸ agentless 배포 → 각 VM에 에이전트 설치 불필요 (규정 준수 팀의 변경 승인 최소화) ▸ FSx for Windows → Windows 기반 파일 공유의 정규 호스팅 솔루션 ▸ MGN + Snowcone 조합 → 가장 빠른 대규모 마이그레이션 경로 【오답 체크】 (A) EFS 사용 → Windows 파일 공유와 호환성 문제 발생, EFS는 Linux/POSIX 시스템용 (B) Discovery Service만 사용 → 실제 마이그레이션 단계 누락, 포트폴리오 검토만으로는 불충분 (D) 각 VM에 에이전트 설치 → 규정 준수 팀의 수백 개 변경 요청 필요, 최소 시간 목표 미달성 【시험 포인트】 대용량 + 빠른 마이그레이션 시나리오 → Snowcone 오프라인 전송 패턴 인식 규정 준수 제약(변경 승인 필요) → agentless 배포 선택이 핵심

해설

【핵심 용어】 ▸ CloudTrail Lake — SQL 기반 쿼리 가능한 통합 로깅 및 분석 서비스 ▸ 위임된 관리자 계정 — Organizations에서 중앙 집중식 관리 권한 부여 ▸ CloudTrail 관리 이벤트 — 계정의 API 호출 및 리소스 변경 기록 【정답 포인트】 ▸ SQL 기반 조회 필요 → CloudTrail Lake의 핵심 기능 ▸ 중앙 위치에서 조회 → 위임된 관리자 계정의 단일 데이터 스토어 활용 ▸ 조직의 모든 계정 자동 수집 → Lake의 조직 통합 기능 ▸ 관리 오버헤드 최소 → 자동 수집 및 통합 【오답 체크】 (A) CloudWatch Logs Insights → SQL이 아닌 정규식 기반 쿼리, 조회 제한적 (C) trail 기반 쿼리 → 이벤트 기록 페이지는 필터만 지원, SQL 조회 불가능 (D) StackSets로 각각 배포 → 관리 오버헤드 증가, 조직 통합 이점 상실 【시험 포인트】 다중 계정 + SQL 쿼리 → CloudTrail Lake 최적 솔루션 위임된 관리자 계정 활용이 중앙화 핵심

해설

【핵심 용어】 ▸ API Gateway Lambda authorizer — OAuth 토큰 검증을 위한 커스텀 권한 부여자 ▸ OAuth 토큰 — 제3자 ID 제공자 발급 ▸ Authorization 헤더 — API 요청 시 토큰 전달 방식 【정답 포인트】 ▸ 제3자 ID 제공자 기존 활용 → OAuth 토큰 그대로 사용 가능 ▸ Lambda authorizer → 커스텀 토큰 검증 로직 구현 (유연함) ▸ API Gateway와 직접 통합 → 인프라 최소화 ▸ 웹 애플리케이션이 토큰 요청 및 전달 → 표준 OAuth 2.0 흐름 【오답 체크】 (B) Directory Service 사용 → LDAP/Active Directory 기반 (OAuth 제공자 아님), SAML 오버엔지니어링 (C) IAM Identity Center → 제3자 제공자와 완전한 기본 통합 불가, STS 토큰은 AWS 전용 (D) IAM 사용자 기반 → AWS 계정 기반 권한 관리 (제3자 OAuth와 맞지 않음) 【시험 포인트】 제3자 OAuth 제공자 → Lambda authorizer 커스텀 검증 패턴 API Gateway + Lambda authorizer = 유연한 토큰 검증 솔루션

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 — 암호화되지 않은 EBS 자동 탐지 ▸ Systems Manager Automation runbook — 암호화된 볼륨으로 자동 수정 ▸ EBS 암호화 설정 — 향후 생성 방지 ▸ 자동 수정 — 기존 비규정 리소스 대응 【정답 포인트】 ▸ 두 가지 요구사항 동시 충족 필요: 1) 기존 암호화되지 않은 볼륨 → Config + Automation runbook으로 자동 수정 2) 향후 미암호화 방지 → 계정 설정으로 신규 볼륨 강제 암호화 ▸ Config 규칙 + Automation = 기존 리소스 치유 ▸ 계정 설정 = 향후 생성 방지 (정책적 보호) 【오답 체크】 (A) KMS 키 정책만 사용 → 암호화 강제는 하지만 기존 볼륨 자동 수정 불가 (B) Fleet Manager + SCP → SCP는 거부만 하고 자동 수정 불가, 수동 개입 필요 (C) 계정 설정만 → 기존 암호화되지 않은 볼륨에 대한 자동 수정 없음 【시험 포인트】 "기존 + 향후" 이중 요구사항 → Config Automation + 계정 설정 조합 AWS Config 자동 수정 = 규정 준수 자동화 핵심 패턴

해설

【핵심 용어】 ▸ AWS/Usage 메트릭 — Service Quotas 모니터링을 위한 CloudWatch 메트릭 네임스페이스 ▸ SERVICE_QUOTA 함수 — CloudWatch에서 할당량 값 조회 ▸ ECS Fargate 작업 할당량 — 계정당 동시 실행 작업 제한 【정답 포인트】 ▸ AWS/Usage 메트릭 네임스페이스 — 서비스 할당량 모니터링 표준 ▸ SERVICE_QUOTA() 함수 — CloudWatch 수학식에서 할당량 값 자동 조회 ▸ metric/SERVICE_QUOTA(metric)*100 > 80 — 할당량 대비 사용률 비율 계산 ▸ CloudWatch 경보 → SNS 알림 — 표준 모니터링 패턴 【오답 체크】 (A) Sample Count 사용 → ECS 서비스 샘플 수는 할당량과 직접 관계 없음 (C) Lambda 폴링 → 불필요한 복잡성, CloudWatch 네이티브 솔루션이 더 효율적 (D) AWS Config 규칙 — Config는 리소스 상태 평가용, 동적 메트릭 임계값 처리 미흡 【시험 포인트】 Service Quotas 모니터링 → AWS/Usage + SERVICE_QUOTA 함수 패턴 CloudWatch 메트릭 수학 = 할당량 추적 표준 솔루션

해설

【핵심 용어】 ▸ Amazon Inspector Lambda scanning — CVE 및 코드 취약점 자동 탐지 ▸ Lambda 표준 스캔 — 배포 패키지의 CVE 탐지 ▸ Lambda 코드 스캔 — 소스 코드의 보안 취약점 탐지 ▸ InspectorCodeExclusion 태그 — 스캔 제외 대상 명시 【정답 포인트】 ▸ A) Inspector 활성화 — CVE 스캔 기반 활성화 ▸ B) Lambda 표준 + 코드 스캔 — CVE(표준) + 취약점(코드) 모두 커버 ▸ E) InspectorCodeExclusion 태그 — 선택적 스캔 구현 ("모든 함수가 아닌 선택된 함수만") 【오답 체크】 (C) GuardDuty Lambda Protection — CVE 및 코드 취약점 스캔 아님, 런타임 위협 탐지만 수행 (D) Lambda 함수 모니터 설정 — 이러한 설정 옵션 없음, Inspector 스캔은 계정/태그 수준에서 관리 (F) S3 버킷 스캔 — Inspector는 배포된 Lambda 함수를 스캔하지 S3 파일을 직접 스캔하지 않음 【시험 포인트】 Lambda CVE + 코드 취약점 → Inspector Lambda 표준 + 코드 스캔 선택적 스캔 → InspectorCodeExclusion 태그 기반 제외 다중 선택 시나리오 = 3가지 요구사항 분리 분석