정답 · 해설

해설

【핵심 용어】 ▸ 축소 보호(Scale-in Protection) — 처리 중 인스턴스 종료 방지 ▸ 가시성 시간 제한(Visibility Timeout) — 메시지 처리 시간 ▸ DLQ(Dead-Letter Queue) — 재시도 실패 메시지 보관소 【정답 포인트】 ▸ 30분 처리 + 1시간 가시성 제한 → 시간 제한 충분해 보임 ▸ 로그에 오류 없음 → 애플리케이션 오류 아니라 인프라 문제 ▸ Auto Scaling 축소 중 → 처리 중 인스턴스가 강제 종료될 수 있음 ▸ 종료되면 메시지 미처리 → DLQ로 이동(maxReceiveCount=1) ▸ 축소 보호 → 처리 완료까지 인스턴스 유지 【오답 체크】 (A) 종료 보호는 자동 축소를 막지 않음 (B) 1시간은 30분 처리에 충분하므로 원인 아님 (D) maxReceiveCount=0은 재시도 불가능, 문제 해결 안 됨 【시험 포인트】 Auto Scaling + SQS + 처리 중 인스턴스 종료 패턴 → 축소 보호 필수

해설

【핵심 용어】 ▸ API Gateway Private 엔드포인트 — VPC 내부 전용 액세스 ▸ VPC 엔드포인트(VPC Interface Endpoint) — VPC에서 AWS 서비스 접근 ▸ 리소스 정책 — 엔드포인트 액세스 제어 【정답 포인트】 ▸ VPC 전용 액세스 → Regional을 Private으로 변경 필수 ▸ 인증 필요 → API Gateway 인증 메커니즘 유지(Private도 지원) ▸ VPC 엔드포인트 생성 → VPC 내에서 Private 엔드포인트 접근 가능 ▸ 리소스 정책 → 추가 접근 제어 ▸ 최소 노력 → 기존 Lambda 함수 수정 불필요 【오답 체크】 (A) ALB는 Lambda 직접 호출 불가, API Gateway 인증 미사용 (B) DNS 변경만으로는 VPC 전용 액세스 보장 불가 (D) Lambda VPC 배포는 불필요한 복잡성, EC2는 관리 오버헤드 【시험 포인트】 VPC 전용 API 액세스 패턴 → API Gateway Private 엔드포인트 + VPC 엔드포인트

해설

【핵심 용어】 ▸ S3 교차 리전 복제(CRR) — 원본 동기화 ▸ Lambda@Edge — CloudFront 엣지 위치에서 요청 수정 ▸ 지역별 최적화 — 사용자 근처 콘텐츠 【정답 포인트】 ▸ (B) us-east-1 S3 버킷 + CRR → 사용자 근처 콘텐츠 로컬 저장 ▸ (D) Lambda@Edge → CloudFront에서 북미 요청을 us-east-1 오리진으로 리다이렉트 ▸ 조합 효과 → 지연 시간 최소화(로컬 오리진 + 엣지 라우팅) 【오답 체크】 (A) Global Accelerator는 S3 직접 지원 안 함, CloudFront 기반 솔루션 필요 (C) S3 Transfer Acceleration은 업로드용, 읽기 최적화 아님 (E) Global Accelerator를 CloudFront 오리진으로 사용 불가 【시험 포인트】 지역별 성능 개선 패턴 → 로컬 캐시(S3 CRR) + 엣지 라우팅(Lambda@Edge)

해설

【핵심 용어】 ▸ update-file-system — FSx 용량 자동 증설 ▸ FreeStorageCapacity 메트릭 — 여유 공간 모니터링 ▸ 자동 확장 — EventBridge + Lambda 조합 【정답 포인트】 ▸ 현재 문제 해결 → 용량 증설(즉각적 해결) ▸ 재발 방지 → 자동 모니터링 + 자동 증설 ▸ update-file-system → FSx 용량 동적 증설 지원 ▸ EventBridge 트리거 → CloudWatch 임계값 초과 시 자동 처리 ▸ 최소 운영 오버헤드 → 완전 자동화 솔루션 【오답 체크】 (A) Lustre는 HPC용, Workspaces 프로필 스토리지로 부적합 (C) Step Functions는 자동 트리거 메커니즘 약함, EventBridge 우수 (D) 프로필 분산은 복잡성 높음, 자동 확장 아님 【시험 포인트】 스토리지 용량 초과 + 자동 확장 패턴 → update-file-system + CloudWatch + EventBridge

해설

【핵심 용어】 ▸ AWS Transfer Family — FTP/SFTP 관리형 서비스 ▸ S3 이벤트 알림 → Lambda 트리거 ▸ SNS — 이벤트 기반 처리 【정답 포인트】 ▸ 핸드헬드 장치 수정 불가 → FTP 인터페이스 유지 필수 ▸ AWS Transfer Family → FTP 엔드포인트 제공(장치 호환성 유지) ▸ S3 직접 저장 → 아카이브 보장, 파일 손실 방지 ▸ SNS + Lambda → 자동 메타데이터 추가 + DB 업데이트 ▸ 확장성 → 관리형 서비스로 자동 확장 【오답 체크】 (A) ALB + Auto Scaling은 여전히 EC2 기반 FTP 관리, 메모리 문제 재현 가능 (B) EFS는 선택사항, S3 아카이브 목표 달성 못함 (D) 핸드헬드 장치 수정 불가능, 이 옵션 위반 【시험 포인트】 레거시 FTP 클라이언트 + 자동 파이프라인 패턴 → Transfer Family + S3 + Lambda

해설

【핵심 용어】 ▸ Aurora 리전 복제본(Aurora Cross-Region Replica) — 자동 DR 보조 데이터베이스 ▸ 영지 손실(Zero Data Loss) — 동기 복제 ▸ 운영 오버헤드 최소화 — 관리형 솔루션 【정답 포인트】 ▸ Aurora Replica → 자동 비동기 복제로 데이터 무결성 보장 ▸ 다중 리전 배포 → 리전 장애 시 자동 페일오버 가능 ▸ 관리형 서비스 → 수동 개입 최소화 ▸ 비용 효율적 → Replica는 읽기 리전으로 활용 가능 【오답 체크】 (B) DataSync는 파일 시스템용, RDS 데이터베이스 복제 목적 맞지 않음 (C) DMS도 가능하나 복잡도 높음, Aurora Replica보다 관리 오버헤드 크다 (D) 스냅샷 5분 주기는 비용 낭비, DR 자동화 부족 【시험 포인트】 Aurora 데이터베이스 + 다중 리전 DR 패턴 → Aurora Cross-Region Replica

해설

【핵심 용어】 ▸ AWS Glue — 관리형 ETL 서비스 ▸ 크롤러 + 분류자 → 데이터 스키마 자동 인식 ▸ 변환 작업 → PAN 마스킹, 필드 병합, JSON 변환 【정답 포인트】 ▸ 다중 피드 확장성 → Glue 크롤러로 새 피드 쉽게 추가 ▸ PAN 마스킹 + 변환 → Glue ETL 스크립트로 통합 처리 ▸ 자동 트리거 → Lambda에서 S3 이벤트로 Glue 작업 시작 ▸ 운영 최소화 → 관리형 서비스, 인프라 관리 불필요 ▸ JSON 출력 → Glue 네이티브 지원 【오답 체크】 (A) Lambda + SQS는 복잡하고 확장성 제한, 다중 피드 어려움 (B) Fargate는 불필요한 컨테이너 복잡성, 확장성 고려 미흡 (D) EMR은 과도한 인프라, 간단한 ETL에 비용/오버헤드 높음 【시험 포인트】 데이터 변환 + 확장성 + PAN 마스킹 패턴 → AWS Glue ETL + 크롤러

해설

【핵심 용어】 ▸ AWS Elastic Disaster Recovery(DRS) — 관리형 전체 재해 복구 ▸ AWS 복제 에이전트 — 에이전트 기반 복제 ▸ 연속 복제 → RTO/RPO 최소화 【정답 포인트】 ▸ 물리 서버 마이그레이션 + MySQL → DRS 최적(모든 서버 유형 지원) ▸ 에이전트 기반 → 물리 서버에서 쉽게 설치 가능 ▸ 지속적 복제 → 데이터 동기화 자동화 ▸ 자동 복구 → 정의된 시점에서 빠른 페일오버 ▸ 최소 운영 오버헤드 → 관리형 서비스, 수동 개입 최소화 【오답 체크】 (A) 테스트 인스턴스는 수동 프로세스, 자동화 부족 (C) DMS는 DB만 처리, 전체 애플리케이션 마이그레이션 불완전 (D) Storage Gateway는 온프레미스 인프라 필요, 방향 역함 【시험 포인트】 물리 서버 + 전체 재해 복구 패턴 → AWS Elastic Disaster Recovery

해설

【핵심 용어】 ▸ 교차 계정 액세스 — IAM 역할 기반 임시 자격증명 ▸ 외부 ID(External ID) — 교차 계정 신뢰 강화 ▸ 최소 권한 원칙 — 읽기 전용 정책 【정답 포인트】 ▸ 교차 계정 접근 → IAM 역할로 신뢰 관계 구성 (B) ▸ 외부 ID → 추가 보안 계층, 모범 사례 ▸ 임시 자격증명 → 장기 API 키 노출 방지 ▸ 읽기 전용 정책 → 필요한 최소 권한 부여 【오답 체크】 (A) 리소스 정책은 별도 계정 주체 지정 필요하나, 역할 기반 (B) 보안 우수 (C) API 키 공유는 보안 위험 높음, 임시 자격증명 아님 (D) IAM 사용자는 감사자의 계정이 아닌 회사 계정에 생성, 교차 계정 아님 【시험 포인트】 교차 계정 감사 액세스 패턴 → IAM 역할 + 외부 ID + 신뢰 정책

해설

【핵심 용어】 ▸ DAX(DynamoDB Accelerator) — 인메모리 캐시 ▸ 읽기 성능 최적화 → DAX 캐시 활용 ▸ 쓰기 일관성 → DynamoDB 직접 쓰기 【정답 포인트】 ▸ 지연 시간 최소화 → 읽기는 캐시(DAX), 쓰기는 DB(일관성) ▸ 3개 노드 → 고가용성 보장(HA 요구사항) ▸ 2개 노드는 고가용성 불충분(최소 3개) ▸ DAX 읽기, DB 직접 쓰기 → 캐시 일관성 최적화 【오답 체크】 (A) 2개 노드는 HA 요구사항 미충족, 단일 장애점 존재 (C) DAX 쓰기는 캐시만 업데이트하고 DB 일관성 떨어짐 (D) 단일 노드는 HA 보장 불가, 장애 시 서비스 중단 【시험 포인트】 DynamoDB 지연 시간 + 고가용성 패턴 → 3노드 DAX 읽기캐시 + DB 직접쓰기

해설

【핵심 용어】 ▸ S3 정적 웹 사이트 호스팅 — 서버리스, 비용 절감 ▸ 버스트 가능 인스턴스(T시리즈) — 변동 워크로드 최적화 ▸ 비용 최적화 — ALB 제거, 인스턴스 선택 【정답 포인트】 ▸ (B) 정적 프런트엔드 → S3 호스팅(EC2 불필요, ALB 제거 가능) ▸ (E) 점심시간만 사용 → 버스트 인스턴스(T3)로 비용 절감 ▸ 두 조합으로 → 프런트엔드 호스팅 비용+백엔드 인스턴스 비용 다중 감소 【오답 체크】 (A) 컴퓨팅 최적화는 CPU 집약적 용도, 이 경우 필요 없음 (C) Elastic Beanstalk는 추가 관리 오버헤드, 비용 절감 미흡 (D) Spot은 중단 위험, 프로덕션 백엔드 부적합 【시험 포인트】 변동 워크로드 비용 최적화 패턴 → 정적 콘텐츠(S3) + 버스트 인스턴스(T시리즈)

해설

【핵심 용어】 ▸ Compute Savings Plans — EC2/Fargate/ECS 통합 할인 ▸ Spot Instances — 피크 핸들링의 비용 효율성 ▸ Reserved Instances — 기본 로드의 예측 가능한 비용 【정답 포인트】 ▸ EKS 기본 로드 → Compute Savings Plans(Reserved보다 유연성) ▸ 피크 처리 → Spot Instances(비용 70~90% 절감) ▸ DB 기본 로드 → 1년 All Upfront(최고 할인) ▸ DB 피크 → 수동 확장(예측된 이벤트 기반) ▸ 이벤트 기반 변동성 → Spot + 수동 확장이 최적 【오답 체크】 (A) Standard Reserved는 Compute Savings보다 비용 높음, 피크 예측 불가 (B) On-Demand Capacity는 비용 높음, 읽기 복제본은 DB 간 추가 비용 (C) EC2 Instance Savings는 EC2만 대상, Fargate 미포함 【시험 포인트】 이벤트 기반 변동 워크로드 비용 최적화 → Savings Plans + Spot + All Upfront + 수동 확장

해설

【핵심 용어】 ▸ CloudFront Origin — 웹 요청이 라우팅되는 원본 서버 ▸ Origin Access Identity(OAI) — CloudFront에서만 S3 접근 허용 ▸ Cache Behavior — 경로 패턴에 따른 라우팅 규칙 【정답 포인트】 ▸ 유지보수 중 CloudFront에서 정보 메시지를 제공하려면: S3 버킷을 두 번째 원본으로 추가 (C) ▸ 정적 콘텐츠(정보 메시지)를 S3에 저장 (A) ▸ 유지보수 기간만 동작 변경하고 복원 (D) — 임시 조정으로 최소 영향도 ▸ OAI 설정으로 보안 강화(C와 함께) 【오답 체크】 (B) 새 배포 생성은 불필요 — 기존 배포에 원본 추가로 충분 (E) 새 배포 기반 경로 패턴은 복잡 — 기존 배포 수정이 더 효율적 (F) Elastic Beanstalk이 S3 제공 불가 【시험 포인트】 유지보수 시나리오 → 기존 리소스 활용(새 배포 X) → 원본 전환 구조 → OAI 보안

해설

【핵심 용어】 ▸ Lambda Alias — 특정 함수 버전을 가리키는 포인터(변경 가능) ▸ Function Version — 불변의 배포된 코드 스냅샷 ▸ ARN(Amazon Resource Name) — AWS 리소스 식별자 【정답 포인트】 ▸ Alias 사용 → 클라이언트 코드 변경 없이 함수 버전 전환 ▸ 테스트 후 별칭만 재구성 → 애플리케이션 배포 불필요 ▸ 최소 운영 오버헤드 — 한 번의 alias update로 모든 트래픽 전환 【오답 체크】 (A) 게시된 버전 수정 불가 — 불변 원칙 위반 (B) DynamoDB 추가는 복잡성 증가 — 매개변수만의 문제가 아님 (C) 코드 하드코딩 → 매번 함수 버전 재배포 필요 (원래 문제 해결 안함) 【시험 포인트】 Lambda 버전 관리 → Alias 전략 → 무중단 배포 패턴

해설

【핵심 용어】 ▸ Apex Domain — 서브도메인 없는 루트 도메인(예: example.com) ▸ CNAME — 도메인 별칭 (apex에 직접 사용 불가) ▸ AWS Global Accelerator — 정적 IP 제공, 자동 장애조치 【정답 포인트】 ▸ Apex 도메인에는 CNAME 불가 — A 레코드 필요 ▸ Global Accelerator가 정적 IP 제공 → 공개 DNS에 A 레코드 생성 ▸ 다중 리전 자동 라우팅 및 장애조치 제공 ▸ 최소 노력 — Route 53 마이그레이션 불필요 【오답 체크】 (A) Apex에 CNAME 사용 불가 (B) NLB 추가 복잡성 증가 (D) API Gateway 지연 증가, 라운드로빈은 지역 최적화 안함 【시험 포인트】 Apex 도메인 → 정적 IP 필요 → Global Accelerator vs Route 53

해설

【핵심 용어】 ▸ Lambda Layer — 코드 재사용을 위한 추가 라이브러리 패키지 ▸ Lambda Container Image — Docker 이미지를 배포 패키지로 사용 ▸ ECR — Docker 이미지 레지스트리 【정답 포인트】 ▸ 공유 라이브러리 + 함수 코드를 단일 이미지로 배포 → 관리 간소화 ▸ Docker 이미지 직접 사용 → Layer 오버헤드 제거 ▸ ECR 저장 → 버전 관리 및 배포 자동화 ▸ 코드 재사용 최적화 — 라이브러리와 함수가 함께 버전 관리 【오답 체크】 (A) S3 저장 후 Layer 사용 — Lambda Layer는 Docker 이미지 지원 안함 (53MB 제한) (B) (A) 와 동일 이유 (C) 옵션 설명 부분이 (D) 와 동일 (실제로는 다른 내용) 【시험 포인트】 Lambda 배포 패키지 → Docker 이미지 vs Zip vs Layer → 코드 재사용 전략

해설

【핵심 용어】 ▸ AWS IoT Greengrass — 온프레미스 엣지 기기에서 AWS 기능 실행 ▸ ML Model Inference — 학습된 모델로 예측 수행 ▸ Local Feedback Loop — 인터넷 없이 즉시 응답 【정답 포인트】 ▸ Greengrass는 로컬 에지에서 ML 모델 배포 가능 ▸ 인터넷 연결 불필요 — 로컬에서 완전 자체 실행 ▸ 클라우드 의존성 제거 — 네트워크 장애에 강건 ▸ 로컬 API 호출 용이 — 같은 네트워크 내 【오답 체크】 (A) 모든 데이터가 AWS로 전송 필요 → 인터넷 필수 (C) Snowball 사용 불필요 (오버스펙), 관리 복잡 (D) Monitron은 모니터링 장치 (ML 추론 목적 아님) 【시험 포인트】 온프레미스 ML 추론 → Greengrass 에지 배포 → 오프라인 요구사항

해설

【핵심 용어】 ▸ Migration Evaluator — 온프레미스 환경을 AWS 비용으로 평가 ▸ CMDB — 서버/소프트웨어 자산 중앙 관리 ▸ TCO(Total Cost of Ownership) — 마이그레이션 경제성 분석 【정답 포인트】 ▸ Migration Evaluator는 CMDB 데이터 직접 지원 ▸ 데이터 가져오기 템플릿으로 간편한 통합 ▸ 마이그레이션 비용 분석에 최적화 ▸ 비즈니스 케이스 생성 목적에 정확 부합 【오답 체크】 (A) Well-Architected Tool은 설계 검토용 (비용 분석 목적 아님) (C) 가격 목록 API는 예측 불가능하고 복잡 (D) Application Discovery Service는 에이전트 기반 (CMDB 가져오기 미지원) 【시험 포인트】 마이그레이션 준비 → 비용 분석 도구 → Migration Evaluator 선택

해설

【핵심 용어】 ▸ AWS Shield Advanced — DDoS 보호 서비스 (자동 탐지 및 완화) ▸ DDoS Attack — 분산 공격 (다양한 IP 주소) ▸ Application Layer Attack — Layer 7 공격 【정답 포인트】 ▸ Shield Advanced는 다양한 소스 IP 공격 자동 완화 ▸ WAF 규칙 수동 관리 불필요 (수백 IP 대응 어려움) ▸ 24/7 관리되는 DDoS 보호 ▸ Layer 7 공격도 포함된 종합 보호 ▸ 최소 운영 오버헤드 【오답 체크】 (A) 수백 IP 주소를 수동으로 추가 불가능 → 확장성 문제 (C) 라우팅 테이블 수정은 네트워크 영향 (애플리케이션 로직이 아님) (D) 지리 위치 기반은 정상 트래픽 차단 위험 【시험 포인트】 다중 소스 DDoS → 자동 완화 필요 → Shield Advanced 선택

해설

【핵심 용어】 ▸ Aurora Global Database — 다중 리전 읽기 복제본 (RTO 분, RPO 초) ▸ DynamoDB Global Table — 다중 마스터 복제 (RTO 분, RPO 초) ▸ RTO/RPO — 몇 분 이내의 복구 목표 【정답 포인트】 ▸ Aurora: 글로벌 데이터베이스로 리전 추가 (A) ▸ DynamoDB: 글로벌 테이블로 변환 후 리전 추가 (D) ▸ 둘 다 RTO/RPO 몇 분 충족 ▸ 동기 복제로 데이터 손실 최소화 【오답 체크】 (B) Aurora는 테이블이 아닌 DB 클러스터 단위 (C) 백업 예약은 RTO/RPO 요구사항 미충족 (복구 시간 길음) (E) Route 53 ARC는 라우팅 제어 (백업/복구 자동화 아님) 【시험 포인트】 다중 리전 데이터 계층 → 글로벌 데이터베이스 기능 선택