정답 · 해설

해설

【핵심 용어】 ▸ AWS Secrets Manager — 민감정보 저장 + 자동 로테이션 기본 제공(Parameter Store는 자동 로테이션 미지원) ▸ Lambda Layer — 공통 로직(비밀 조회) 패키징, 수천 함수가 재사용 ▸ Parameter Store — 구성/비밀 저장 가능하나 내장 자동 로테이션 없음 【정답 포인트】 ▸ (C) Secrets Manager에 민감정보 저장 → 자동 로테이션 요건 충족 ▸ (B) 비밀 조회 로직을 Lambda Layer로 만들어 수천 함수가 공유 → 최소 운영 오버헤드 【오답 체크】 (A) Lambda@Edge HTTP 보안 헤더는 CloudFront용, 비밀 관리·로테이션과 무관. (D) Parameter Store는 자동 로테이션 미지원 → "자동 로테이션" 요건 불충족. (E) 전용 처리량 소비자로 환경변수 생성은 스트림 소비 개념, 요건과 무관하고 과설계. 【시험 포인트】 "자동 로테이션 = Secrets Manager", "다수 함수 공통 조회 = Lambda Layer".

해설

【핵심 용어】 ▸ AWS Compute Optimizer — EC2·Auto Scaling group·EBS 볼륨에 대한 라이트사이징/비용 권장 제공 ▸ Cost and Usage Report — 상세 비용 청구 데이터, 리소스 라이트사이징 권장은 아님 ▸ CloudWatch 청구 경보 — 비용 임계 알림용, 최적화 권장 아님 【정답 포인트】 ▸ "EC2 + ASG + EBS 비용 최적화" + "운영 효율 최대" → Compute Optimizer가 세 리소스 권장을 단일 서비스로 제공 【오답 체크】 (A) CUR은 청구 데이터일 뿐 최적화 "권장"을 생성하지 않음. (B) CloudWatch 청구 경보는 비용 알림이지 라이트사이징 권장이 아님. (D) Compute Optimizer + CUR 혼용은 불필요, Compute Optimizer 하나로 세 리소스 모두 커버 → 효율↓. 【시험 포인트】 "EC2/ASG/EBS 라이트사이징 권장" = Compute Optimizer 단일 서비스.

해설

【핵심 용어】 ▸ Amazon EFS — 다중 AZ EC2에서 동시 마운트 가능한 공유 파일 시스템, VPC 내 유지 ▸ EBS — 단일 인스턴스/단일 AZ 블록 스토리지(멀티 어태치도 동일 AZ 한정) ▸ S3 — 객체 스토리지, POSIX 파일 공유 마운트에 부적합 【정답 포인트】 ▸ "여러 AZ EC2 간 데이터 공유" + "VPC 내 유지" + "고성능" → 다중 AZ 동시 마운트 EFS 【오답 체크】 (A) S3 API 호출은 파일 공유 볼륨이 아니며 애플리케이션 변경 필요. (B) S3를 마운트 볼륨처럼 쓰는 구성은 표준 공유 파일 시스템 아님. (C) EBS는 다중 AZ 동시 공유 불가 → 요건 미충족. 【시험 포인트】 "다중 AZ EC2 공유 파일 + VPC 내" → EFS. 블록(EBS)은 AZ 한정, S3는 객체.

해설

【핵심 용어】 ▸ RDS Read Replica — 읽기 부하 분산용 복제본, 부하에 맞춰 인스턴스 크기 조정 가능 ▸ 라이트사이징 — 사용률에 맞춰 인스턴스 크기를 줄여 비용 최적화, 여유는 남김 ▸ CPU 사용률 지표 — Primary 60% 유지(적정), 리플리카 25%(과대 프로비저닝) 【정답 포인트】 ▸ 리플리카 상시 25% → 과대, 더 작은 인스턴스로 다운사이징(향후 성장분 여유 유지) ▸ Primary는 여전히 60%로 적정 → 변경하지 않음 【오답 체크】 (A) 리플리카 삭제는 25% 읽기 부하를 Primary로 몰아 성능·성장 여유 훼손. (C) 리플리카 확대 + Primary 축소는 사용률(각 25%/60%) 판단과 정반대. (D) 리플리카 삭제 + Primary 확대는 불필요한 비용 증가. 【시험 포인트】 사용률이 낮은 인스턴스는 "삭제"가 아니라 "다운사이징", 적정 사용률은 유지.

해설

【핵심 용어】 ▸ Reserved Instance (RDS) — 장기 예약으로 최대 할인, 3년 All Upfront가 최대 절감 ▸ EC2 Instance Savings Plan — 특정 인스턴스 패밀리 약정, 3년 All Upfront가 최대 절감 ▸ 약정 기간/선결제 — 기간 길고 선결제 클수록 시간당 단가 최저 【정답 포인트】 ▸ "장기 실행 워크로드" + "가장 비용 효율" → 3년 All Upfront가 RDS RI·EC2 Savings Plan 모두 최대 할인 【오답 체크】 (A) 온디맨드 RDS + 1년 No Upfront는 할인 폭이 가장 작음. (B) 1년 No Upfront 조합은 3년 All Upfront보다 절감률 낮음. (C) 1년 Partial Upfront도 3년 All Upfront보다 단가 높음. 【시험 포인트】 "장기 워크로드 최대 절감" = 3년 + All Upfront(RI/Savings Plan).

해설

【핵심 용어】 ▸ IRSA (IAM Roles for Service Accounts) — K8s 서비스 어카운트에 IAM 역할을 세분 매핑 ▸ OIDC 자격 증명 공급자 — EKS 클러스터의 OIDC와 IAM 역할 간 신뢰 관계 설정 필요 ▸ 서비스 어카운트 어노테이션 — IAM 역할 ARN을 SA에 주석으로 연결 【정답 포인트】 ▸ (E) IAM 역할과 OIDC 공급자 간 신뢰 관계 설정 → IRSA의 전제 ▸ (D) 필요한 권한의 IAM 역할 정의 후 서비스 어카운트에 역할 ARN 어노테이트 → SA가 역할 사용 【오답 체크】 (A) 노드 IAM 역할에 정책 부착은 노드 전체 공유 권한 → 파드/SA별 세분화 아님(IRSA 원칙 위배). (B) 네트워크 정책은 트래픽 제어일 뿐 IAM 권한 부여와 무관. (C) 클러스터 역할에 모든 SA 권한 몰아넣기는 세분 권한 원칙에 반함. 【시험 포인트】 IRSA = "OIDC 신뢰 관계 + 서비스 어카운트에 IAM 역할 ARN 어노테이션".

해설

【핵심 용어】 ▸ SSE-KMS (AWS 관리형 키) — 매년 자동 키 로테이션, KMS API 호출이 CloudTrail에 기록 ▸ AWS 관리형 KMS 키 — 별도 키 저장 비용 없음(고객 관리형 대비 저렴) ▸ SSE-S3 — 로테이션은 되나 CloudTrail로 키 사용·로테이션 추적 불가 【정답 포인트】 ▸ "매년 자동 로테이션" + "CloudTrail 추적" + "키 비용 최소" → SSE-KMS(AWS 관리형 키) ▸ AWS 관리형 키는 연 1회 자동 로테이션 + KMS 호출 CloudTrail 로깅 + 키 요금 없음 【오답 체크】 (A) SSE-C는 키를 고객이 직접 관리·전달 → 자동 로테이션·CloudTrail 추적 부재. (B) SSE-S3는 KMS 미사용 → CloudTrail로 키 로테이션 추적 불가. (D) 고객 관리형 KMS 키는 월별 키 비용 발생 → "비용 최소" 요건에 불리. 【시험 포인트】 "자동 연간 로테이션 + CloudTrail 추적 + 비용 최소" → SSE-KMS with AWS 관리형 키.

해설

【핵심 용어】 ▸ Cost Allocation Tags — 리소스에 태그 지정 후 활성화하면 비용을 태그별로 분류 ▸ Cost Explorer — 태그 기준 비용 분석·보고서, 정기 리포트 생성 가능 ▸ CUR / Budgets — 원시 청구 데이터·예산 알림용, 앱별 분석엔 수작업 필요 【정답 포인트】 ▸ "앱별 비용 분류" + "정기 보고서" + "비용 효율" → 앱 이름 태그 + 비용 할당 태그 활성화 + Cost Explorer 【오답 체크】 (A) Budgets CSV 다운로드 후 수동 조회는 정기 리포트·앱별 분류 자동화 아님. (B) CUR을 RDS에 적재하고 SQL 조회는 인프라 비용·운영 부담 과다. (D) 태그 후 청구서 수동 다운로드·조회는 수작업, 정기 리포트 자동화 아님. 【시험 포인트】 "앱별 비용 분류 + 리포트" = 비용 할당 태그 + Cost Explorer.

해설

【핵심 용어】 ▸ Auto Scaling group(다중 AZ) — 여러 AZ에 EC2 분산으로 확장성·복원력 ▸ Multi-AZ RDS — DB 계층 고가용성(자동 페일오버) ▸ Amazon CloudFront — 정적 자산을 엣지에서 배포해 성능·복원력 향상 【정답 포인트】 ▸ "견고·복원력 아키텍처" → 멀티 AZ ASG(웹) + Multi-AZ RDS(DB) + CloudFront(정적 자산)의 삼중 이중화 【오답 체크】 (A) 단일 AZ EC2 + 단일 AZ RDS는 AZ 장애 시 전면 중단 → 복원력 없음. (C) 단일 AZ EC2 + EC2에서 정적 자산 서빙은 확장성·복원력 부족. (D) 정적 자산을 EFS One Zone-IA에 두면 단일 AZ 의존 → 복원력 저하. 【시험 포인트】 복원력 3요소: "멀티 AZ ASG + Multi-AZ RDS + CloudFront(정적)".

해설

【핵심 용어】 ▸ Gateway Load Balancer (GWLB) — 서드파티 보안 어플라이언스를 투명하게 인라인 삽입, GENEVE 사용 ▸ GWLB Endpoint (GWLBe) — 애플리케이션 계정에서 트래픽을 GWLB로 보내는 인터페이스 엔드포인트 ▸ 중앙 인스펙션 — 네트워킹 계정에 어플라이언스 집중 배치 【정답 포인트】 ▸ "보안 어플라이언스로 계정 간 상호작용 인스펙션" → 네트워킹 계정 GWLB + 앱 계정 GWLB 엔드포인트로 트래픽 우회 검사 【오답 체크】 (A) NLB + 인터페이스 VPC 엔드포인트는 어플라이언스 투명 인스펙션 삽입 모델 아님. (B) 앱 계정 ALB로 직접 보내는 방식은 중앙 인스펙션 아키텍처가 아님. (D) 인터페이스 VPC 엔드포인트만으로는 트래픽을 어플라이언스로 인라인 검사할 수 없음. 【시험 포인트】 "서드파티 보안 어플라이언스 인라인 트래픽 인스펙션" = GWLB + GWLB 엔드포인트.

해설

【핵심 용어】 ▸ Aurora Custom Endpoint — 지정한 replica 집합으로 연결을 분산, 특정 스펙 노드 그룹화 가능 ▸ Reader Endpoint — 모든 리더에 자동 분산(특정 3개만 지정 불가) ▸ Instance Endpoint — 개별 인스턴스 직접 연결(자동 분산 없음) 【정답 포인트】 ▸ "특정 3개 리플리카(다른 스펙)에 자동 분산" → 해당 3개를 묶는 커스텀 엔드포인트 생성·사용 【오답 체크】 (B) 3노드 클론 + reader endpoint는 별도 클러스터 복제로 과설계, 요건과 무관. (C) 인스턴스 엔드포인트는 개별 연결이라 3개에 자동 분산 안 됨. (D) reader endpoint는 전체 리더에 분산 → 특정 3개만 지정 불가. 【시험 포인트】 "특정 리플리카 하위 집합에 부하 분산" = Aurora 커스텀 엔드포인트.

해설

【핵심 용어】 ▸ AWS Secrets Manager — DB 자격증명 저장 + RDS 통합 자동 로테이션 기본 제공 ▸ Lambda 통합 — 함수가 런타임에 Secrets Manager에서 자격증명 조회 ▸ Parameter Store — 자동 로테이션 내장 없음(별도 구현 필요) 【정답 포인트】 ▸ "자격증명 안전 관리" + "자동 로테이션" + "최소 운영 오버헤드" → Secrets Manager 저장 + 30일 자동 로테이션 【오답 체크】 (A) Parameter Store는 자동 로테이션 미지원 → 요건 불충족. (C) 암호화 환경변수 + 커스텀 로테이션 함수 직접 작성은 운영 부담↑. (D) KMS는 암호화 키 관리용이지 DB 자격증명 저장·로테이션 서비스가 아님. 【시험 포인트】 "DB 자격증명 자동 로테이션, 최소 오버헤드" = Secrets Manager.

해설

【핵심 용어】 ▸ AWS DMS Serverless — 부하에 따라 복제 용량을 자동 프로비저닝/스케일, 필요한 만큼만 할당 ▸ DMS 복제 인스턴스 — 고정 용량 프로비저닝(수요 변동에 낭비 가능) ▸ 온고잉 복제(CDC) — 변경 데이터 지속 복제 【정답 포인트】 ▸ "하루 종일 변동하는 데이터량" + "필요 용량만 할당" → 용량을 자동 산정·프로비저닝하는 DMS Serverless 【오답 체크】 (A) Multi-AZ는 가용성 향상일 뿐 용량 자동 조정과 무관. (C) EC2 Auto Scaling으로 DMS 인스턴스 스케일은 DMS 관리형 방식이 아님. (D) ECS Fargate로 DMS 용량 프로비저닝은 지원 방식이 아니며 과설계. 【시험 포인트】 "수요 변동 + 필요 용량만 자동 할당" = DMS Serverless.

해설

【핵심 용어】 ▸ AWS PrivateLink — VPC와 서드파티 SaaS(AWS 호스팅) 간 프라이빗 연결, 인터넷 노출 최소 ▸ VPC 인터페이스 엔드포인트 — SaaS 엔드포인트 서비스로의 프라이빗 접속 ▸ Site-to-Site VPN / Transit Gateway — 네트워크 연결용, SaaS 프라이빗 접속 표준 아님 【정답 포인트】 ▸ "AWS 호스팅 SaaS로 안전·프라이빗 연결" + "인터넷 노출 최소" → PrivateLink로 VPC-SaaS 프라이빗 연결 【오답 체크】 (A) Site-to-Site VPN은 온프렘 연결용, SaaS 프라이빗 접속 모델 아님. (B) Transit Gateway는 VPC/온프렘 라우팅 허브, SaaS 프라이빗 접속 표준이 아님. (C) "아웃바운드만 허용하고 SaaS의 연결을 막는다"는 설명이 불완전·부정확한 구성 → 표준 PrivateLink 사용(D)이 정답. 【시험 포인트】 "AWS 상의 SaaS에 프라이빗·최소 노출 접속" = AWS PrivateLink.

해설

【핵심 용어】 ▸ AWS Site-to-Site VPN — IPsec으로 네트워크 계층 트래픽 암호화, 온프렘-VPC 연결 ▸ Security Group / Network ACL — 필요한 트래픽만 허용해 무제한 접근 차단 ▸ Direct Connect — 전용 회선이나 기본적으로 암호화 미제공 【정답 포인트】 ▸ "네트워크 계층 암호화" → IPsec 기반 Site-to-Site VPN ▸ "무제한 접근 방지 보안 통제" → 보안 그룹·NACL로 필요한 트래픽만 허용 【오답 체크】 (A) Direct Connect는 기본 암호화가 없음 → "전 구간 암호화" 요건 불충족. (B) IAM 정책은 콘솔·API 접근 제어일 뿐 네트워크 트래픽 암호화가 아님. (D) Transit Gateway 자체는 암호화 제공 서비스가 아님(연결 허브) → 암호화 요건 미충족. 【시험 포인트】 "온프렘-VPC 트래픽 암호화 + 접근 통제" = Site-to-Site VPN(IPsec) + SG/NACL.

해설

【핵심 용어】 ▸ AWS Secrets Manager — 자격증명 저장 + Lambda 기반 자동 로테이션, 애플리케이션은 SDK로 조회 ▸ RDS for MySQL 통합 로테이션 — Secrets Manager가 로테이션 Lambda로 자격증명 교체 ▸ 최소 프로그래밍 — 임베디드 자격증명을 Secrets Manager 조회로 대체 【정답 포인트】 ▸ "임베디드 자격증명 보안 강화" + "최소 프로그래밍" → Secrets Manager 저장 + Lambda 로테이션 스케줄 【오답 체크】 (A) KMS는 키 관리용, DB 자격증명 저장·로테이션 서비스가 아님. (B) 로컬 암호화 저장 + cron 로테이션은 관리형이 아니고 보안·운영 취약. (D) Parameter Store의 RDS 자체 로테이션 스케줄이라는 기능은 존재하지 않음 → 부정확. 【시험 포인트】 "DB 자격증명 자동 로테이션 + 최소 코드 변경" = Secrets Manager.

해설

【핵심 용어】 ▸ Amazon Athena — S3 데이터를 SQL로 직접 조회하는 서버리스 쿼리(신규/기존 데이터 모두) ▸ S3 Cross-Region Replication (CRR) — 다른 리전으로 자동 복제 ▸ SSE-S3 — S3 관리형 키 암호화, 키 관리 오버헤드 최소 【정답 포인트】 ▸ "서버리스 SQL 분석" → Athena ▸ "기존 버킷 그대로 + 최소 오버헤드" → 기존 S3에 CRR 구성 + SSE-S3 암호화(새 버킷·이전 불필요) 【오답 체크】 (A) 새 버킷 생성 후 데이터 재적재 + SSE-KMS 멀티리전 키는 불필요한 마이그레이션·오버헤드↑. (B) RDS는 서버리스가 아니며 S3 SQL 조회 도구도 아님. (D) RDS 사용 + 서버리스 아님 → 요건 불충족. 【시험 포인트】 "서버리스 S3 SQL = Athena", "최소 오버헤드 = 기존 버킷 CRR + SSE-S3".

해설

【핵심 용어】 ▸ S3 Glacier Deep Archive — 최저 비용 아카이브, 연 2회 모델 학습용 원본 이미지에 적합 ▸ S3 Standard — 언제든 다운로드하는 프리미엄 생성 이미지(즉시·빈번 접근)에 적합 ▸ S3 Standard-IA — 6시간마다 접근하는 비프리미엄 생성 이미지(간헐 접근)에 적합 【정답 포인트】 ▸ 업로드 원본: 연 2회만 사용 → Glacier Deep Archive(최저 비용) ▸ 프리미엄 생성물: 언제든 다운로드 → S3 Standard ▸ 비프리미엄 생성물: 6시간마다 접근 → Standard-IA 【오답 체크】 (B) 모든 생성물을 Glacier Flexible Retrieval에 두면 프리미엄 즉시 접근·검색 지연·검색 비용 문제. (C) 원본을 One Zone-IA에 두면 연 2회 학습 대비 저장비가 Deep Archive보다 높음. (D) One Zone-IA 원본 + Glacier 생성물은 접근 패턴별 최적 계층 매칭 실패. 【시험 포인트】 접근 빈도별 매칭: "거의 안 씀=Deep Archive, 상시=Standard, 간헐=Standard-IA".

해설

【핵심 용어】 ▸ Amazon SQS — 비동기 요청/배치를 버퍼링, 불규칙 트래픽 흡수·디커플링 ▸ Amazon ECS Auto Scaling — 큐 길이 기반으로 클러스터·서비스 스케일, 1GB 모델 메모리 상주에 적합 ▸ Lambda 한계 — 15분 실행·메모리 제한으로 대형 모델 상주·긴 배치에 부적합 【정답 포인트】 ▸ "비동기 API + 요청/배치" + "불규칙·수일 미사용" + "1GB 모델 상주" → SQS 버퍼 + ECS(큐 깊이 기반 스케일) 【오답 체크】 (A) NLB로 Lambda 호출 + 1GB 모델 상주는 Lambda 특성상 콜드스타트·메모리 부담 큼. (B) ALB→ECS는 비동기 배치 큐 디커플링 모델이 아님. (C) Lambda의 vCPU를 큐 크기로 조정한다는 스케일 방식은 실제 존재하지 않음 → 부정확. 【시험 포인트】 "비동기 배치 + 대형 모델 상주 + 불규칙" = SQS + ECS(큐 기반 오토스케일).

해설

【핵심 용어】 ▸ Aurora Global Database — 리전 간 저지연 복제, DR 리전에 읽기/승격 가능 클러스터 유지 ▸ 웜 스탠바이(Warm Standby) — DR 인프라를 최소 용량으로 상시 가동, RTO 수십 분 달성 ▸ Route 53 active-passive 페일오버 — 장애 시 DR 엔드포인트로 전환 【정답 포인트】 ▸ "RTO 30분" + "평상시 고객 트래픽 불필요" → DR 리전 ALB+ASG를 최소 용량으로 두고 Aurora Global DB + Route 53 액티브-패시브 【오답 체크】 (B) active-active는 상시 양쪽 서비스 → "평상시 트래픽 불필요" 대비 과도·비용↑. (C) AWS Backup 복원 + active-active + 백업에서 클러스터 재생성은 RTO·복잡도 불리. (D) ASG 희망 용량 0은 인스턴스 기동 시간이 추가되어 30분 RTO 위험, A(최소 용량 상시)가 더 안정적. 【시험 포인트】 "RTO 30분 + 평상시 미사용" = 웜 스탠바이(최소 용량) + Aurora Global DB + 액티브-패시브.