정답 · 해설

해설

【핵심 용어】 ▸ Reserved Capacity — 평균 부하를 저비용으로 커버, 장기 약정 할인 ▸ Application Auto Scaling — 피크 시간만 동적 확장, 온디맨드 가격 적용 ▸ DynamoDB Accelerator(DAX) — 캐시 계층으로 읽기 성능 향상, RCU 감소는 미미 【정답 포인트】 ▸ 예측 가능한 피크(주 1회) + 명확한 평균 부하 → Reserved + Auto Scaling 조합 ▸ Reserved: 평균 부하 커버(주 5일) ▸ Auto Scaling: 피크 4시간만 추가 용량(비용 최소화) 【오답 체크】 (B) 온디맨드 모드는 모든 시간을 온디맨드 요금으로 계산 → 예약보다 비쌈 (C) DAX는 읽기 캐시이고, 문제는 쓰기가 많음 → 효과 제한적 (D) DAX + 온디맨드 모드 = 불필요한 비용 증가 【시험 포인트】 예측 가능한 워크로드 패턴 → Reserved + 동적 스케일링 조합이 최적

해설

【핵심 용어】 ▸ Amazon SQS — 비동기 작업 큐, 자동 스케일 가능 ▸ EC2 Auto Scaling — 큐 길이 기반 동적 확장/축소 ▸ Amazon S3 — 처리 결과 저장(EFS보다 저비용) ▸ Lambda — 1시간 처리 제한(15분 max timeout) 【정답 포인트】 ▸ "1시간 처리" → Lambda 불가능(timeout 15분) ▸ "업무시간 높음/후 감소" → Auto Scaling EC2 필수 ▸ "비용 효과" → SQS + Auto Scaling(필요시만 비용) ▸ 저장소: S3(고가용성, 저비용) 【오답 체크】 (A) Lambda의 15분 제한으로 1시간 작업 처리 불가능 (B) EC2 수동 생성 → 느린 응답, Auto Scaling 미활용 (C) Lambda timeout 초과 + MQ는 SQS보다 복잡하고 비쌈 + EFS는 높은 비용 【시험 포인트】 장시간 배치 작업 + 변동적 부하 → EC2 Auto Scaling + SQS 조합

해설

【핵심 용어】 ▸ UltraWarm — OpenSearch 웜 데이터 저장소(뜨거운 데이터 노드보다 저비용) ▸ Cold Storage — UltraWarm보다 더 저렴한 저장소(읽기 느림) ▸ S3 Glacier Deep Archive — 장기 보관용 최저가 스토리지 【정답 포인트】 ▸ "1개월 분석 후 삭제" → 데이터 노드 축소(2개) + UltraWarm 활용 ▸ "규정 준수 보관" → 입력 데이터 Glacier Deep Archive로 이전 ▸ 인덱스 자동 전환 → 접수 시 UltraWarm 이동(운영 간편) 【오답 체크】 (A) UltraWarm만으로 부족, 데이터 노드 축소 미실시 → 비용 절감 불충분 (C) Cold Storage는 읽기 불가능 + 입력 데이터 삭제(규정 위반) (D) Instance-backed 노드는 여전히 비싼 상태 유지 + 스토리지 계층화 부재 【시험 포인트】 OpenSearch 계층화 저장소 → 핫(데이터노드) → 웜(UltraWarm) → 콜드(Cold) → 아카이브(Glacier)

해설

【핵심 용어】 ▸ Service Control Policy(SCP) — 조직 수준 권한 제어, 거부(Deny) 정책으로 작업 차단 ▸ aws:SourceIp — IP 주소 기반 조건 키 ▸ ec2:AuthorizeSecurityGroupIngress — 보안 그룹 인바운드 규칙 추가 작업 【정답 포인트】 ▸ "0.0.0.0/0 생성 능력 제거" → Deny 정책 필요 ▸ "운영 오버헤드 최소" → SCP로 사전 차단(Lambda 자동화 불필요) ▸ Deny 정책: ec2:AuthorizeSecurityGroupIngress를 0.0.0.0/0 조건에서 거부 【오답 체크】 (A) Lambda로 사후 제거 → 여전히 생성되고, 수동 정리 필요 → 오버헤드 증가 (B) AWS Config는 규정 준수 검사이지, 생성 능력 제거 불가 (C) "Allow when NOT 0.0.0.0/0" → 역설적 로직, 혼란 야기 【시험 포인트】 조직 수준 접근 제어 → SCP Deny 정책으로 근본 차단

해설

【핵심 용어】 ▸ Lambda Function URL — 단순 HTTP 엔드포인트, 각 함수마다 별도 URL ▸ API Gateway HTTP API — 중앙 라우팅, 여러 Lambda 함수 관리 용이 ▸ App Runner — 컨테이너 관리형 서비스(여기서는 오버킬) ▸ ECS + Fargate — 컨테이너 오케스트레이션(운영 오버헤드 높음) 【정답 포인트】 ▸ "여러 웹훅" → 중앙 라우팅 필요 ▸ "운영 오버헤드 최소" → API Gateway가 모든 웹훅을 하나의 엔드포인트로 관리 ▸ HTTP API가 REST API보다 간단하고 저비용 【오답 체크】 (A) 웹훅마다 URL 관리 → 많은 엔드포인트 유지 필요 → 오버헤드 증가 (C) App Runner + ALB = 여전히 인스턴스 수준 관리 (D) ECS/Fargate + 컨테이너 빌드 → 가장 복잡한 운영 【시험 포인트】 다중 웹훅 통합 → API Gateway로 중앙 라우팅하는 것이 서버리스 베스트 프랙티스

해설

【핵심 용어】 ▸ AWS Application Discovery Agent — 에이전트 기반 수집(CPU, RAM, 프로세스, OS 정보 포함) ▸ Agentless Discovery Connector — 에이전트 없음(VM 성능만) ▸ Data Exploration — Migration Hub의 수집 데이터를 S3로 자동 내보내기 ▸ Amazon Athena — S3 데이터에 대한 SQL 쿼리 【정답 포인트】 ▸ "CPU, RAM, OS, 프로세스" → Application Discovery Agent 필요 ▸ "쿼리 및 분석" → S3 + Athena(표준 분석 도구) ▸ Data Exploration → 수집 데이터를 S3로 자동 내보내기 【오답 체크】 (A) Agentless는 성능만 수집 → OS, 프로세스 정보 누락 (B) 수동 임포트 → 대규모(1000개) 서버에 부적합 (C) put-resource-attributes는 대량 자동화에 부적합 + 콘솔 쿼리 확장성 제한 【시험 포인트】 대규모 마이그레이션 발견 → Agent + Data Exploration + Athena 표준 패턴

해설

【핵심 용어】 ▸ NAT Gateway — 프라이빗 인스턴스의 아웃바운드 트래픽을 공개 IP로 변환 ▸ Elastic IP — NAT 게이트웨이에 할당되는 정적 공개 IP ▸ Egress-only IGW — IPv6 아웃바운드만(IPv4 아님) ▸ Internet Gateway — Elastic IP 직접 연결 불가능 【정답 포인트】 ▸ "단일 공개 IP" + "외부 화이트리스트" → NAT Gateway + Elastic IP ▸ Lambda가 VPC 프라이빗 서브넷에 있음 → NAT 게이트웨이를 통한 아웃바운드 ▸ VPC 설정으로 NAT 게이트웨이 경로 활성화 【오답 체크】 (B) Egress-only IGW는 IPv6만 지원(문제는 IPv4) (C) IGW에 Elastic IP 직접 연결 불가능 + Lambda가 프라이빗 서브넷에서 IGW 접근 불가 (D) Lambda가 프라이빗 서브넷에서 퍼블릭 라우팅 테이블 사용 불가 【시험 포인트】 VPC 프라이빗 서브넷 → 공개 IP 고정 필요 → NAT Gateway + Elastic IP

해설

【핵심 용어】 ▸ RDS Proxy — 연결 풀링으로 데이터베이스 연결 수 제한(대규모 Lambda 부하 해결) ▸ Lambda Provisioned Concurrency — 웜 Lambda 시작(콜드 스타트 제거) ▸ Connection Pooling — 재사용 가능한 연결 집합으로 관리 ▸ Reader Endpoint — 읽기 복제본으로 자동 분산 【정답 포인트】 ▸ "많은 수의 DB 연결 열기" → RDS Proxy (B) ▸ "높은 부하" + "읽기만" → Reader Endpoint (B) ▸ Lambda 초기화 최적화 → 이벤트 핸들러 외부에서 연결 생성 (D) 【오답 체크】 (A) 클러스터 엔드포인트는 쓰기용, 읽기 성능 최적화 아님 (C) Provisioned Concurrency는 콜드 스타트 문제일 때만 필요(여기는 연결 풀 부족) (E) 엣지 최적화 엔드포인트는 지역별 성능 차이 없음(모두 가까운 리전) 【시험 포인트】 Lambda + Aurora 높은 동시성 → RDS Proxy + 연결 초기화 외부 이동

해설

【핵심 용어】 ▸ End-to-End Encryption — 클라이언트 → ALB(TLS) → 서버(TLS) ▸ ACM Certificate — AWS가 관리하는 무료 인증서(ALB용) ▸ 타사 인증서 — 서버에 설치 필요(자체 서명) ▸ ALB 리스너(443) → 백엔드(443): TLS 재암호화 【정답 포인트】 ▸ "종단 간 암호화" → 클라이언트-ALB-서버 모두 TLS ▸ ALB: ACM 인증서(무료) ▸ 서버: 타사 인증서(자체 서명 또는 프라이빗) ▸ 포트 443 → 443 설정 【오답 체크】 (A) ACM 인증서 내보내기 불가능(AWS 관리형, 개인키 미접근) (B) CloudFront는 클라이언트-CF 암호화만(CF-서버는 선택사항, 종단간 아님) (D) NLB는 레이어 4(TLS 종료 어려움) + 타사 인증서 부담 증가 【시험 포인트】 ALB + 종단간 암호화 → ACM(ALB) + 타사 인증서(백엔드) 조합

해설

【핵심 용어】 ▸ AWS DMS — 지속적 복제로 가동중단 없는 마이그레이션 ▸ Aurora Replica — 읽기 전용 복제본(집계 작업 분리) ▸ RDS Proxy — Lambda 연결 풀링 ▸ ALB + Lambda — 서버리스 수집, 유연한 스케일링 【정답 포인트】 ▸ "로딩 문제" → 읽기 부하를 복제본으로 분리 (C) ▸ "지속적 복제" → DMS(온라인 마이그레이션) (C) ▸ "중단 없음" → DMS 동기화 + DNS 전환 (C) ▸ "유연성" → Lambda + ALB (C, NLB 아님) 【오답 체크】 (A) NLB는 ALB보다 복잡 + 복제 대신 DMS 미사용(동기화 지연) (B) EC2 Auto Scaling은 Lambda/RDS Proxy 조합보다 무거움 (D) Kinesis는 스트리밍용, 배치 로딩에 부적합 【시험 포인트】 가동중단 없는 마이그레이션 → DMS + Aurora Replica + Lambda/RDS Proxy

해설

【핵심 용어】 ▸ SSE-KMS — AWS KMS 관리형 키로 암호화(고객 관리 가능) ▸ SSE-S3 — AWS 관리형 키(고객 통제 불가) ▸ 고객 관리형 키 — CMK(Customer Master Key, 고객이 관리) ▸ 기존 객체 재암호화 — 새 암호화 적용 필요 【정답 포인트】 ▸ "보안 팀 관리 키" → SSE-KMS (B) ▸ "미래 객체" → 기본 암호화 설정 (B) ▸ "현재 객체" → 모두 다시 업로드 필수 (B) ▸ "암호화되지 않은 요청 거부" → 버킷 정책 (B) 【오답 체크】 (A) SSE-S3는 AWS 관리형 → 고객 통제 불가(요구사항 불만족) (C) 정책으로 "자동 암호화" 불가(정책은 거부만 가능) (D) AES-256도 AWS 관리(고객 관리 아님) + 버킷 정책은 엔티티에 첨부 불가 【시험 포인트】 고객 관리형 키 + 기존 객체 → SSE-KMS + 재업로드 필수

해설

【핵심 용어】 ▸ Origin Group — CloudFront에서 여러 오리진을 관리하는 기능(페일오버 포함) ▸ CloudFront — 글로벌 캐싱 + 자동 장애 조치(별도 Route 53 설정 불필요) ▸ Multi-Region Deployment — 다른 리전에 백업 인프라 【정답 포인트】 ▸ "고가용성" → 다중 리전 배포 (B) ▸ "CloudFront는 유지" → 오리진 그룹으로 확장 (B) ▸ "ALB 수준" → 2개 리전의 ALB를 오리진으로 (B) ▸ "자동 장애 조치" → Origin Group으로 자동 처리 (B) 【오답 체크】 (A) CloudFront 여러 개 + Route 53 페일오버 = 복잡, CloudFront의 기본 기능 미활용 (C) 동일 리전 ALB → 다중 리전 고가용성 아님 (D) CloudFront 2개 + Global Accelerator = 오버킬, 비용 증가, Route 53 설정 필요 【시험 포인트】 CloudFront 고가용성 → Origin Group(동일 CF, 다중 오리진)

해설

【핵심 용어】 ▸ VPC Prefix List — IP 범위 목록을 관리하는 AWS 리소스 ▸ AWS Resource Access Manager(RAM) — 조직 계정 간 리소스 공유 ▸ Security Group Rules — 접두사 목록 ID로 참조 가능(동적 업데이트) 【정답 포인트】 ▸ "중앙 관리" + "다중 계정" → Prefix List + RAM (C) ▸ "개발자 참조" → 보안 그룹에서 prefix list ID 사용 ▸ "IP 범위 변경" → Prefix List 수정 시 자동 적용 ▸ "운영 오버헤드 최소" → 자동 동기화 (C) 【오답 체크】 (A) SNS + Lambda → 수동 트리거 필요, 항상 최신 상태 보장 불가 (B) AWS Config는 규정 준수 검사이지, IP 범위 관리 도구 아님 (D) 교차 계정 보안 그룹 참조는 Transit Gateway 활용 필요, prefix list보다 제한적 【시험 포인트】 조직 수준 IP 관리 → VPC Prefix List + RAM 조합

해설

【핵심 용어】 ▸ AWS Compute Optimizer — 권장 메모리, 비용 분석 ▸ ExportLambdaFunctionRecommendations — 권장사항을 CSV로 자동 내보내기 ▸ EventBridge — 정기적 Lambda 함수 실행 스케줄링 【정답 포인트】 ▸ "권장 메모리 + 가격 차이" → Compute Optimizer (B) ▸ "자동 CSV 내보내기" → ExportLambdaFunctionRecommendations (B) ▸ "2주마다 자동" → EventBridge + Lambda (B) ▸ "개발 시간 최소" → 기존 API 활용(CloudWatch 로그 파싱 아님) 【오답 체크】 (A) CloudWatch 로그 수동 파싱 → 개발 시간 많이 필요 (C) 수동 예약(콘솔) → 자동화 부족, 개발 필요 (D) Business Support + Trusted Advisor → 비용 증가, Compute Optimizer는 더 직접적 【시험 포인트】 Lambda 비용 최적화 보고서 → Compute Optimizer API + EventBridge 자동화

해설

【핵심 용어】 ▸ Cost Allocation Tags — 사용자 정의 태그로 비용 추적 ▸ Cost Category — 청구 시스템 수준의 비용 그룹화 ▸ Cost Explorer — 비용 분석 및 비교/예측 도구 ▸ AWS-generated Tags — AWS가 자동 생성(제한적) 【정답 포인트】 ▸ "팀 리소스 태그" → 사용자 정의 비용 할당 태그 (A) ▸ "월별 비용 귀속" → Cost Category (C) 추가 세분화 ▸ "12개월 비교 + 예측" → Cost Explorer(F) 【오답 체크】 (B) AWS-generated 태그는 자동 태그만(팀/앱 사용자 정의 불가) (D) IAM 액세스는 보고서 생성과 무관 (E) 예산은 비용 추적 아님(알림만) 【시험 포인트】 비용 할당 + 분석 → 사용자 정의 태그 + Cost Category + Cost Explorer

해설

【핵심 용어】 ▸ BYOIP(Bring Your Own IP) — 고객 소유 IP 블록을 AWS에 등록 ▸ NAT Gateway — Elastic IP와 연결되어 아웃바운드 출발지 IP 제공 ▸ Elastic IP — NAT 게이트웨이에 할당 가능한 정적 공개 IP 【정답 포인트】 ▸ "프라이빗 서브넷 EC2" → NAT 게이트웨이를 통한 아웃바운드 (B) ▸ "단일 CIDR 화이트리스트" → NAT 게이트웨이의 Elastic IP (B) ▸ "BYOIP 등록" → AWS 계정에 IP 블록 등록 (B) ▸ "Elastic IP 생성 및 할당" → NAT 게이트웨이에 (B) 【오답 체크】 (A) VPC 연결(routing)만으로는 Elastic IP 미할당 → 동적 IP 사용 (C) ALB는 공개 IP 직접 할당 불가(ALB가 아닌 NAT 게이트웨이) (D) Global Accelerator는 클라이언트 수신 최적화이지, 아웃바운드 NAT 아님 【시험 포인트】 프라이빗 인스턴스 + 고객 IP 화이트리스트 → BYOIP + NAT Gateway + Elastic IP

해설

【핵심 용어】 ▸ Service Control Policy(SCP) — 조직 수준 권한 제어(상한선 설정) ▸ IAM Policy — 개별 엔티티의 실제 권한(일반 권한) ▸ 권한 교집합 — SCP(Allow) AND IAM Policy = 최종 권한 【정답 포인트】 ▸ SCP는 "제한 정책"(상한선, 이 경우 S3 거부) ▸ SCP를 수정하면 모든 사용자에게 영향 ▸ 문제의 SCP가 s3:CreateBucket을 거부 중 → IAM 권한 추가 필수 ▸ "IAM 엔티티에 권한 추가" = SCP 변경 없이 사용자 권한 부여 【오답 체크】 (A) SCP를 수정하면 정책의 의도(거부) 무효화 → 관리자 실수 (B) OU 제거/SCP 직접 연결 → 상황 악화 (D) SCP 제거 → 조직 보안 정책 위배 【시험 포인트】 SCP 문제 해결 → SCP는 상한선, 개별 IAM 권한으로 해결

해설

【핵심 용어】 ▸ Systems Manager Session Manager — SSH 키 없이 안전하게 EC2 인스턴스에 접근할 수 있는 서비스 ▸ IAM Role — EC2가 AWS 서비스에 접근할 수 있는 권한을 부여 【정답 포인트】 ▸ 'SSH 키 페어 없음' + '서비스 중단 불가' → Session Manager가 최적 ▸ Session Manager는 Systems Manager 에이전트를 통해 SSH 없이 접근 ▸ 실행 중인 인스턴스에 직접 역할 연결 가능 ▸ 다운타임 없이 즉시 데이터 백업 가능 【오답 체크】 (B) (D) 새 인스턴스 생성 필요 → 레이턴시 증가, 복잡한 프로세스 (C) DLM은 스냅샷 자동화용, S3로의 직접 복사는 미지원 【시험 포인트】 SSH 없이 인스턴스 접근 → Session Manager 현재 인스턴스 유지 → 재부팅/새 인스턴스 생성 안 함

해설

【핵심 용어】 ▸ 크로스 계정 복사 — 다른 AWS 계정 간 S3 데이터 이전 ▸ 버킷 정책 vs IAM 정책 — 소스와 대상 각각의 권한 명시 【정답 포인트】 ▸ (B) 소스 버킷 정책 필수 — 대상 계정 사용자 Read 권한 ▸ (D) 대상 계정 IAM 정책 필수 — 소스 Read + 대상 Write 권한 ▸ (F) 대상 계정에서 명령 실행 — 대상 계정 자격증명 사용 ▸ CLI 실행 위치 = 권한 있는 사용자의 계정 【오답 체크】 (A) 정책을 대상에 연결하면 아키텍처 모순 발생 (C) 소스 계정이 아닌 대상 계정 사용자 필요 (E) 소스 계정에서 대상 쓰기 권한 없음 【시험 포인트】 크로스 계정 S3 복사 → 소스 정책(읽기 허용) + 대상 정책(쓰기 허용) 실행 계정 결정 중요 → 권한 있는 쪽에서 sync 실행

해설

【핵심 용어】 ▸ Lambda Alias — 함수 버전을 가리키는 별칭, 트래픽 가중치 설정 가능 ▸ Canary 릴리스 — 신버전으로 소수 트래픽 먼저 라우팅, 점진적 확대 ▸ Routing Config — 별칭의 트래픽 분산 비율 설정 【정답 포인트】 ▸ Lambda Alias + routing-config 조합이 Canary 배포의 표준 ▸ 새 버전:구 버전 트래픽 비율을 동적으로 조정 가능 ▸ CloudFormation과 독립적으로 운영 가능 ▸ 문제 발생 시 즉시 롤백 간단 【오답 체크】 (B) 전체 스택 배포는 리스크 큼, Canary 아님 (C) update-function-configuration은 구성 변경용, routing-config 미지원 (D) CodeDeploy는 EC2/온프레미스 배포용, Lambda 전용 아님 【시험 포인트】 Canary 릴리스 → Lambda Alias + routing-config 버전 vs 별칭 구분 → 별칭이 트래픽 분산 담당