정답 · 해설

해설

【핵심 용어】 ▸ EC2 On-Demand — 중단 불가한 단기 배치 작업에 적합(Spot은 중단 위험) ▸ S3 Standard → Glacier Deep Archive — 30일 접근 후 2년 보관은 최저비용 아카이브로 전환 ▸ 수명주기 만료(expiration) — 2년 후 자동 삭제 【정답 포인트】 ▸ "중단 불가 단기 배치" → On-Demand(Spot 배제) ▸ "30일 접근 후 2년 보관" → S3 Standard 후 30일 뒤 Glacier Deep Archive, 2년 뒤 삭제 → 최저 비용 【오답 체크】 (A) Spot은 중단 가능 → "중단 불가" 요건 위배. Glacier Instant Retrieval도 Deep Archive보다 비쌈. (B) On-Demand는 맞으나 데이터를 처음부터 Glacier Instant에 두는 것은 30일 접근 패턴에 비효율. (C) Spot 사용으로 "중단 불가" 위배. 【시험 포인트】 "중단 불가 = On-Demand", "장기 보관 최저비용 = Glacier Deep Archive".

해설

【핵심 용어】 ▸ AWS Direct Connect — 전용 회선으로 단자릿수(single-digit) ms 저지연 하이브리드 연결 ▸ Transit VIF + Direct Connect Gateway — DX를 Transit Gateway와 연결하는 경로 ▸ Direct Connect Gateway ↔ Transit Gateway 연결 — 다중 VPC를 DX로 통합 【정답 포인트】 ▸ (D) Direct Connect 연결 + Transit VIF를 DX 게이트웨이로 → 저지연 전용 경로 확보 ▸ (B) DX 게이트웨이를 VPC 연결 Transit Gateway와 연동 → 다중 VPC 통합 라우팅 【오답 체크】 (A) 각 VPC에 Site-to-Site VPN은 인터넷 경유로 단자릿수 지연 보장 못 함. (C) VPN을 DX 게이트웨이에 연결하는 구성은 저지연 요건에 부합하지 않고 목적과 어긋남. (E) VPN을 Transit Gateway에 연결도 인터넷 기반 → 저지연 미보장. 【시험 포인트】 "단자릿수 저지연 하이브리드" = Direct Connect(Transit VIF) + DX Gateway↔Transit Gateway.

해설

【핵심 용어】 ▸ Amazon RDS Proxy — 연결 풀링·관리로 Multi-AZ 페일오버 시간 단축, 애플리케이션 타임아웃 완화 ▸ Multi-AZ 페일오버 — DNS 전환 지연으로 앱 타임아웃 발생 가능 ▸ 연결 재사용 — Proxy가 페일오버 중 연결을 유지·재라우팅 【정답 포인트】 ▸ "페일오버 시 앱 타임아웃" + "페일오버 시간 단축" → RDS Proxy가 연결을 관리해 페일오버 전환을 빠르게 처리 【오답 체크】 (B) 리드 리플리카는 읽기 확장용, 쓰기 페일오버 시간 단축과 무관. (C) Performance Insights는 모니터링 도구, 페일오버 시간 개선 아님. (D) 스냅샷 교차 리전 복사는 백업/DR용, 페일오버 시간 단축과 무관. 【시험 포인트】 "Multi-AZ 페일오버 타임아웃 완화" = RDS Proxy.

해설

【핵심 용어】 ▸ Amazon EventBridge (스케줄 규칙) — 정해진 시간에 Lambda 호출로 RDS 시작/중지 자동화 ▸ AWS Lambda — RDS start/stop API 호출 ▸ 태그 기반 대상 선별 — 개발 리소스 태그로 대상 필터 【정답 포인트】 ▸ "업무 시간에만 스케줄로 시작/중지" + "최소 운영 오버헤드" → EventBridge 스케줄 규칙이 Lambda로 RDS 시작·중지 【오답 체크】 (A) CloudWatch 알람은 임계 기반 알림용, 시간 스케줄 트리거로 부적합. (B) Trusted Advisor는 권장 리포트 도구, 시작/중지 스케줄러가 아님. (C) State Manager는 구성 상태 유지용이며 시작/중지 시간 스케줄에는 EventBridge가 더 직접적. 【시험 포인트】 "시간 기반 정기 시작/중지" = EventBridge 스케줄 규칙 + Lambda.

해설

【핵심 용어】 ▸ S3 Requester Pays — 요청자가 데이터 전송·요청 비용 부담, 버킷 소유자 비용 최소화 ▸ 교차 계정 접근 — 마케팅사 계정에 버킷 접근 권한 부여됨 ▸ 데이터 전송 비용 — 다운로드 요청 측이 부담하도록 전환 【정답 포인트】 ▸ "타 계정이 데이터 요청 시 전송 비용 최소화" → Requester Pays로 요청자(마케팅사)가 비용 부담 【오답 체크】 (B) CRR은 복제 비용·스토리지 이중 발생 → 소유자 비용 증가. (C) RAM 공유는 리소스 공유일 뿐 데이터 전송 비용 부담 이전과 무관. (D) Intelligent-Tiering + 동기화는 전송 비용 부담 이전 기능이 아님. 【시험 포인트】 "타 계정 다운로드 비용을 소유자가 안 내려면" = S3 Requester Pays.

해설

【핵심 용어】 ▸ AWS WAF Rate-based Rule — 지정 임계 초과 요청 IP를 차단해 L7 DDoS/과다요청 완화 ▸ WAF 연결 대상 — ALB, CloudFront, API Gateway (Global Accelerator에는 직접 연결 불가) ▸ ALB에 web ACL 연결 — 트래픽 진입점(ALB)에서 rate 제한 적용 【정답 포인트】 ▸ "DDoS 완화" + "최소 구현 노력" → ALB에 WAF web ACL(rate-based rule) 연결, 진입점에서 과다요청 차단 【오답 체크】 (A) WAF는 Global Accelerator에 직접 연결 불가 → 구성 불성립. (B) Lambda로 ALB 지표 읽어 NACL 갱신은 커스텀 개발 부담 큼. (D) Global Accelerator 앞에 CloudFront 추가는 아키텍처 대폭 변경 → 최소 노력 아님. 【시험 포인트】 "L7 과다요청/DDoS 완화, 최소 노력" = ALB에 WAF rate-based rule. WAF는 GA에 못 붙음.

해설

【핵심 용어】 ▸ AWS Glue + DynamoDB export connector — DynamoDB를 S3로 내보내 처리, 테이블 RCU 소비 없음 ▸ 프로비저닝 처리량 보호 — export는 테이블 읽기 용량에 영향 최소 ▸ 일 단위 배치 메트릭 계산 — 정기 스케줄 ETL 【정답 포인트】 ▸ "테이블 R/W 용량에 최소 영향" + "일 단위 메트릭" → Glue DynamoDB export 커넥터(테이블 직접 스캔 대신 내보내기 기반) 【오답 체크】 (A) Athena DynamoDB 커넥터는 테이블을 직접 스캔 → 프로비저닝 읽기 용량 소비. (C) Redshift COPY는 DynamoDB 스캔 기반 → 읽기 용량 소비. (D) EMR Hive 외부 테이블 스캔도 테이블 RCU 소비 → "최소 영향" 위배. 【시험 포인트】 "프로비저닝 용량 영향 최소로 DynamoDB 분석" = Glue export connector(S3 export 기반).

해설

【핵심 용어】 ▸ Amazon SQS — 작업 항목을 내구성 있게 저장, 느슨한 결합(loosely coupled) 제공 ▸ Auto Scaling — 큐의 항목 수(ApproximateNumberOfMessages) 기반으로 EC2 증감 ▸ 병렬 처리 — 큐 소비자 인스턴스를 수요에 맞춰 확장 【정답 포인트】 ▸ "느슨한 결합 + 내구성 저장 + 작업 수 기반 병렬 확장" → SQS 큐 + 큐 항목 수 기반 ASG 스케일링 【오답 체크】 (A) SNS는 메시지 저장(내구 큐)이 아니라 푸시 알림 + CPU 기반 스케일은 작업량과 무관. (B) SQS는 맞으나 네트워크 사용량 기준 스케일은 작업 수 반영이 부정확. (D) SNS는 작업 항목 내구 저장에 부적합, 발행 메시지 수 기반 스케일도 부적절. 【시험 포인트】 "작업 큐 병렬 처리 스케일" = SQS + 큐 depth 기반 Auto Scaling.

해설

【핵심 용어】 ▸ Amazon ECS + AWS Fargate — 서버리스 컨테이너로 모듈형·확장 아키텍처, 최소 운영 오버헤드 ▸ Amazon RDS (Multi-AZ) — 구조적 스키마 유지가 필요한 제품 데이터에 적합 + 고가용성 ▸ Amazon S3 — 제품 이미지 저장용 객체 스토리지 【정답 포인트】 ▸ "모듈형·확장 + 구조적 스키마 유지 + 최소 오버헤드" → ECS Fargate + RDS Multi-AZ + S3(이미지) 【오답 체크】 (A) EC2 ASG 컨테이너 운영은 Fargate보다 운영 부담↑, 이미지를 RDS에 저장은 부적합. (B) DynamoDB는 구조적 스키마 유지 요건과 어긋나고 이미지 저장에도 부적합. (C) EKS on EC2는 운영 오버헤드↑, 이미지를 Glacier Deep Archive에 두면 접근 지연. 【시험 포인트】 "모듈형 + 스키마 유지 + 최소 운영" = Fargate + RDS + S3(이미지는 S3).

해설

【핵심 용어】 ▸ 클라이언트 측 암호화(Client-Side Encryption) — S3에 저장하기 "전에" 클라이언트에서 암호화 ▸ 고객 관리형 키(customer managed keys) — 클라이언트 암호화 키를 고객이 통제 ▸ 서버 측 암호화(SSE) — S3가 수신 후 암호화(저장 전 클라이언트 암호화 아님) 【정답 포인트】 ▸ "S3에 저장하기 전에 데이터 암호화" → 클라이언트 측 암호화(고객 관리형 키)로 전송 전 암호화 【오답 체크】 (B) SSE-KMS는 서버(S3) 수신 후 암호화 → "저장 전 암호화" 요건 불충족. (C) SSE-C도 서버 측 암호화(키만 고객 제공) → 저장 전 클라이언트 암호화 아님. (D) "클라이언트 암호화 + S3 관리형 키"는 성립하지 않는 조합(관리형 키는 서버 측 개념). 【시험 포인트】 "업로드 전(저장 전) 암호화" = 클라이언트 측 암호화. SSE-*는 모두 서버 측.

해설

【핵심 용어】 ▸ EMR Runtime Roles — 잡 제출 시 팀별 IAM 역할을 적용, 잡별 세분 권한 부여 ▸ EMR 런타임 역할 격리 — 워크로드가 EC2 인스턴스 프로파일(IMDS) 권한 대신 런타임 역할 사용 ▸ 인스턴스 프로파일 — 노드 전체 공유 권한이라 팀별 격리·IMDS 우회에 부적합 【정답 포인트】 ▸ "팀별 필요한 서비스만 접근" + "워크로드가 IMDSv2(인스턴스 자격증명) 접근 못 하게" → EMR 런타임 역할 사용 【오답 체크】 (A) 인터페이스 VPC 엔드포인트는 네트워크 경로 제어일 뿐 팀별 IAM 권한 격리·IMDS 차단이 아님. (C) EC2 인스턴스 프로파일은 노드 공유 권한 → 팀별 격리·IMDS 회피 불가. (D) EnableApplicationScopedIAMRole=false 설정은 오히려 애플리케이션 범위 역할을 비활성화 → 요건과 반대. 【시험 포인트】 "EMR 팀별 세분 권한 + 인스턴스 자격증명(IMDS) 차단" = EMR Runtime Roles.

해설

【핵심 용어】 ▸ AWS App2Container (A2C) — 기존 .NET/Java 앱을 컨테이너로 변환하는 마이그레이션 도구 ▸ Amazon ECS on AWS Fargate — 서버리스 컨테이너, 운영 유지관리 최소 ▸ CloudWatch 지표 기반 스케일 — Fargate 서비스 오토스케일 【정답 포인트】 ▸ ".NET 현대화 + 컨테이너화" → App2Container로 컨테이너화 ▸ "CloudWatch 기반 스케일 + 운영 유지관리 최소" → ECS on Fargate(서버 관리 없음) 【오답 체크】 (B) ECS on EC2는 인스턴스 패치·관리 필요 → Fargate 대비 운영 오버헤드↑. (C) App Runner는 컨테이너화 도구가 아님(소스/이미지 배포 서비스), 설명이 부정확. (D) App Runner "컨테이너화" 표현 부정확 + EKS on EC2는 운영 부담↑. 【시험 포인트】 "기존 .NET 컨테이너화 = App2Container", "운영 최소 = ECS Fargate".

해설

【핵심 용어】 ▸ AWS Secrets Manager — 사용자명/비밀번호 등 자격증명 저장·관리에 특화 ▸ BatchGetSecretValue API — 다수 시크릿을 한 번에 조회 ▸ CloudFormation 통합 — 배포 시 Secrets Manager에서 자격증명 조회 【정답 포인트】 ▸ "여러 사용자명/비밀번호를 안전하게 저장·조회" + "최소 운영 오버헤드" → Secrets Manager + BatchGetSecretValue로 일괄 조회 【오답 체크】 (A) Parameter Store는 자격증명 특화·자동 로테이션 측면에서 Secrets Manager 대비 부적합, BatchGetSecretValue는 Secrets Manager API. (B) AWS Batch를 끼워 넣는 구성은 불필요한 복잡성 추가. (C) Parameter Store + AWS Batch 조합은 서비스 특성·API 모두 부정확·과설계. 【시험 포인트】 "다수 사용자 비밀번호 저장·일괄 조회, 최소 오버헤드" = Secrets Manager + BatchGetSecretValue.

해설

【핵심 용어】 ▸ Amazon CloudFront — 엣지 캐싱으로 전 세계 다운로드 지연 감소, S3를 오리진으로 사용 ▸ Signed URL — 제한된 접근으로 소프트웨어 파일 배포 ▸ 캐싱 활성화 — 반복 다운로드되는 소프트웨어 파일을 엣지에 캐시해 지연 완화 【정답 포인트】 ▸ "전 세계 서버가 동일 소프트웨어 반복 다운로드" + "지연 감소 + 최소 오버헤드" → S3 오리진 CloudFront 배포로 엣지 캐싱 【오답 체크】 (A) CachingDisabled 캐시 정책은 엣지 캐시를 끔 → 지연 감소 목적에 정반대. (B) 2개 버킷 복제 + 이중 오리진 페일오버는 지연 감소가 아니라 가용성 구성, 과설계. (C) S3 Transfer Acceleration은 S3로의 업로드 가속용, 전 세계 다운로드 캐싱과 다름. 【시험 포인트】 "전 세계 반복 다운로드 지연 감소" = CloudFront(캐싱). Transfer Acceleration은 업로드용.

해설

【핵심 용어】 ▸ Amazon FSx for NetApp ONTAP (Multi-AZ) — 다중 AZ 고가용, iSCSI로 저지연 블록 스토리지 제공 ▸ iSCSI — 네트워크 기반 블록 스토리지 프로토콜, 공유 블록 액세스 ▸ Windows 액티브/스탠바이 — 두 AZ EC2에 하나 액티브, 하나 대기 【정답 포인트】 ▸ "다중 AZ 저지연 블록 스토리지" + "최소 구현 노력" → FSx for NetApp ONTAP Multi-AZ를 iSCSI로 연결(관리형 이중화) 【오답 체크】 (A) FSx for Windows File Server는 파일(SMB) 공유이지 블록 스토리지가 아님. (B) EBS gp3 + 애플리케이션 레벨 복제는 직접 복제 구현 부담↑ (EBS는 AZ 한정). (D) io2 + EBS 레벨 AZ 간 복제 구성도 수작업 복제로 구현 노력↑. 【시험 포인트】 "다중 AZ 공유 블록 스토리지 관리형" = FSx for NetApp ONTAP Multi-AZ(iSCSI).

해설

【핵심 용어】 ▸ ALB 보안 그룹 인바운드 — 인터넷에서 HTTPS(443) 수신 허용 필요 ▸ ALB 보안 그룹 아웃바운드 — 백엔드 인스턴스로 나가는 트래픽(앱 443, 헬스체크 8443) 허용 ▸ 헬스체크 포트 8443 — ALB가 HTTPS로 상태 점검 【정답 포인트】 ▸ (A) 인바운드 HTTPS 443 from 0.0.0.0/0 → 공개 인터넷 HTTPS 수신 ▸ (C) 아웃바운드 HTTPS 443 → 웹 인스턴스로 앱 트래픽 전달 ▸ (E) 아웃바운드 8443 → 웹 인스턴스 헬스체크(HTTPS) 【오답 체크】 (B) 0.0.0.0/0로 전체 아웃바운드 443 허용은 대상을 인스턴스로 한정하지 못해 요건(인스턴스로만)에 부적합. (D) 인스턴스로부터의 인바운드 443 허용은 방향이 반대(ALB→인스턴스가 아웃바운드). (F) 헬스체크는 ALB가 나가는 방향(아웃바운드) → 인바운드 8443은 방향 오류. 【시험 포인트】 ALB SG: "인바운드=클라이언트 443, 아웃바운드=백엔드 앱443/헬스체크8443". 헬스체크도 아웃바운드.

해설

【핵심 용어】 ▸ ACM 인증서(us-east-1) — CloudFront에서 쓰는 커스텀 도메인 인증서는 반드시 us-east-1(N. Virginia)에 발급 ▸ CloudFront OAC (Origin Access Control) — CloudFront만 S3 업로드/접근 허용, 버킷 직접 노출 차단 ▸ 커스텀 도메인 + HTTPS — CloudFront에 ACM 인증서 연결 【정답 포인트】 ▸ (A) CloudFront용 공개 인증서는 us-east-1에 발급해야 CloudFront에서 사용 가능 ▸ (D) S3가 CloudFront OAC로부터의 업로드를 허용하도록 구성 → 커스텀 도메인 통해 안전 업로드 【오답 체크】 (B) eu-west-1 인증서는 CloudFront에서 사용 불가(CloudFront는 us-east-1 인증서만). (C) Transfer Acceleration은 커스텀 도메인+CloudFront 업로드 요건과 별개 기능. (E) S3 웹사이트 엔드포인트는 정적 호스팅용, OAC 기반 CloudFront 업로드 모델과 맞지 않음. 【시험 포인트】 "CloudFront 커스텀 도메인 인증서 = us-east-1 ACM", "S3 접근 제어 = OAC".

해설

【핵심 용어】 ▸ Amazon Athena — S3 데이터를 표준 SQL로 직접 쿼리하는 서버리스 서비스, 쿼리당 스캔량 과금(간헐적 사용에 최적), Parquet·CSE-KMS 암호화 파일 읽기 지원 ▸ S3 Select — 단일 객체 내부에서 일부 데이터만 추출, 집계·다중 파일 조인 부적합 ▸ Redshift Spectrum / EMR Serverless — 대규모 분석용, 클러스터·엔진 상시 비용 발생 【정답 포인트】 ▸ "occasional SQL queries"(간헐적) + "MOST cost-effectively" → 상시 인프라 없이 쿼리당 과금하는 Athena가 최적 ▸ Parquet + CSE-KMS 암호화 파일을 Athena가 직접 읽어 이동 없이 S3 위에서 쿼리 가능 【오답 체크】 (B) S3 Select는 단일 객체 스캔 위주로 이동 평균 같은 다중 파일 집계 분석에 부적합. (C) Redshift Spectrum은 Redshift 클러스터를 상시 운영해야 해 간헐적 사용엔 비용 과다. (D) EMR Serverless + SparkSQL은 간헐적 소규모 쿼리에 비해 오버헤드·비용 과다. 【시험 포인트】 "S3 위 간헐적 SQL" + "비용 최적" → Athena. 상시 클러스터(Redshift/EMR)는 지속 워크로드용.

해설

【핵심 용어】 ▸ Route 53 geoproximity routing — 리소스와 사용자의 지리적 위치 기반으로 가장 가까운 엔드포인트로 라우팅(bias 조정 가능) ▸ Route 53 geolocation routing — 사용자가 속한 대륙/국가 등 정의된 위치별로 특정 엔드포인트 매핑(근접성 아님) ▸ Network Load Balancer — AZ 간 트래픽 분산, 고성능 L4 로드밸런서 【정답 포인트】 ▸ "closest to the user's location"(가장 가까운) → 리소스·사용자 위치 근접성으로 라우팅하는 geoproximity가 정답 【오답 체크】 (A) geolocation은 지정된 국가/대륙 규칙 기반이라 "가장 가까운" 근접 라우팅과는 다름. (C) multivalue answer는 헬스체크 기반 다중 IP 응답(라운드로빈)으로 위치 개념 없음. (D) weighted는 가중치 비율 분산으로 위치와 무관. 【시험 포인트】 "가장 가까운 위치로" → geoproximity. "특정 국가/대륙별 지정" → geolocation.

해설

【핵심 용어】 ▸ RDS 저장 시 암호화(Encryption at rest) — KMS 관리형 키로 활성화만 하면 자동 적용(관리 오버헤드 최소) ▸ AWS Certificate Manager (ACM) — SSL/TLS 인증서 발급·자동 갱신, 전송 중 암호화 표준 ▸ IPsec/VPN — 네트워크 계층 터널링, DB 전송 암호화엔 불필요한 관리 부담 【정답 포인트】 ▸ "encrypted at rest and in transit" + "LEAST operational overhead" → 저장은 RDS KMS 암호화, 전송은 ACM SSL/TLS 인증서로 관리형 처리 【오답 체크】 (B) IPsec 터널은 수동 구성·운영 부담이 크고 DB 전송 암호화에 과함. (C) 서드파티 애플리케이션 레벨 암호화는 구현·키 관리 오버헤드가 큼. (D) VPN 연결은 프라이빗 연결용이며 SSL/TLS 대비 운영 부담이 큼. 【시험 포인트】 RDS 암호화: 저장=KMS 설정, 전송=ACM TLS. VPN/IPsec은 전송 암호화의 정답이 아님.