정답 · 해설

해설

【핵심 용어】 ▸ AWS Backup — RDS 포함 다중 서비스 백업 중앙 관리, 백업 플랜으로 90일 이상 장기 보존 및 연속 백업(PITR) 지원 ▸ RDS 자동 백업 — 보존 기간 최대 35일로 90일 규정 요건 충족 불가 ▸ PITR(Point-in-Time Restore) — 특정 시점 복원, 연속 백업 기반 【정답 포인트】 ▸ "90일 보존" + "14일 이내 특정 시점 복원" + "LEAST overhead" → AWS Backup 플랜으로 90일 보존과 연속 백업(PITR)을 한 번에 관리형으로 충족 【오답 체크】 (A) RDS 자동 백업은 보존 최대 35일이라 90일 설정 자체가 불가. (B) 매일 수동 스냅샷 생성·삭제는 운영 오버헤드가 큼. (C) Aurora Clone은 Aurora 전용 기능으로 RDS for Oracle에 부적용, 보존 목적도 아님. 【시험 포인트】 RDS 장기(35일 초과) 백업 보존 = AWS Backup. 자동 백업만으로는 최대 35일.

해설

【핵심 용어】 ▸ Amazon Aurora Serverless — 관계형(RDS 호환) 관리형 DB, 실제 사용량에 따라 용량 자동 확장/축소, 가변·읽기 위주 워크로드에 비용 최적 ▸ Provisioned IOPS SSD — 고정 고성능 스토리지, 상시 비용 높음 ▸ DynamoDB — NoSQL, 관계형 요구와 불일치 【정답 포인트】 ▸ "relational" + "variable, read-heavy" + "cost-optimize" + "AWS managed" → 사용량 기반 자동 스케일하는 Aurora Serverless가 가변 부하에 가장 경제적 【오답 체크】 (A) RDS Provisioned IOPS는 상시 고정 프로비저닝으로 가변 부하에 비용 낭비. (C) DynamoDB는 NoSQL로 관계형 데이터 요건에 부적합. (D) magnetic 스토리지는 구형·저성능이며 read replica는 추가 비용/복잡도 증가. 【시험 포인트】 "관계형 + 가변 부하 + 비용 최적" → Aurora Serverless. NoSQL은 관계형 요건에서 제외.

해설

【핵심 용어】 ▸ VPC Gateway Endpoint (S3) — S3로의 트래픽을 라우팅 테이블 경유 프라이빗 연결, 추가 비용 없음 ▸ IAM 조건 키(aws:ResourceAccount 등) — 요청 대상 리소스의 소유 계정으로 접근 제어, 계정 내 모든 버킷을 한 정책으로 커버 ▸ EC2 인스턴스 프로파일 — EC2에 IAM 권한 부여 【정답 포인트】 ▸ "회사 AWS 계정 소속 S3 버킷만 접근" + "LEAST overhead" → Gateway Endpoint + IAM 정책에 계정 조건 키(Deny)를 걸어 신규 고객 버킷까지 자동 커버 【오답 체크】 (A) 특정 버킷만 개별 Allow하는 방식은 고객 버킷이 늘 때마다 정책 갱신이 필요해 운영 부담. (B) NAT gateway는 비용 발생 + 계정 소속 버킷만으로 제한하지 못함. (D) NAT gateway + 모든 버킷에 개별 버킷 정책 부여는 관리 오버헤드 과다. 【시험 포인트】 "계정 소속 리소스만" 제한은 IAM 조건 키(ResourceAccount) 한 방으로. 버킷 개별 나열은 확장성 낮음.

해설

【핵심 용어】 ▸ IAM Identity Center — 중앙 집중 워크포스 자격 증명·SSO, 권한 세트(permission set)로 계정·리소스 접근을 그룹 단위로 관리 ▸ Permission set — 재사용 가능한 세분화 권한 묶음, 최소 권한 부여에 적합 ▸ IAM 사용자/역할 개별 관리 — 팀·구성원별 수동 관리로 오버헤드 큼 【정답 포인트】 ▸ "IAM Identity Center로 자격 관리" + "최소 권한" + "LEAST overhead" → 권한 세트로 RDS·S3 세분 권한을 정의하고 팀을 그룹에 배정하는 방식이 가장 간결 【오답 체크】 (A) 팀별 커스텀 IAM 정책·역할 수작업 관리는 Identity Center 미활용으로 오버헤드. (C) 구성원별 개별 IAM 사용자 생성은 최소 권한·확장성·관리 측면에서 비효율. (D) 팀별 계정 분리 + 교차 계정 역할은 이 요건 대비 과도한 복잡성. 【시험 포인트】 Identity Center 사용 명시 + 최소 권한 = 권한 세트 + 그룹. 개별 IAM 사용자는 오답 신호.

해설

【핵심 용어】 ▸ IAM Roles Anywhere — 온프레미스 서버/VM이 X.509 인증서로 IAM 역할을 assume해 임시 자격 증명 획득(장기 액세스 키 불필요) ▸ 임시 자격 증명 — 자동 만료로 유출 위험 최소화, 임시 접근에 적합 ▸ 장기 액세스 키 — 유출·관리 위험 큼 【정답 포인트】 ▸ "on-premises VM" + "temporary access" + "secure" → IAM Roles Anywhere로 인증서 기반 임시 자격 증명을 발급받아 S3 접근이 가장 안전 【오답 체크】 (A) 공인 IP 범위 허용 버킷 정책은 IP 스푸핑·과다 노출로 안전하지 않음. (C) IAM 사용자 액세스 키를 VM에 설정하는 장기 키 방식은 유출 위험. (D) Secrets Manager에 저장해도 결국 장기 액세스 키라 임시 접근·보안 요건에 미흡. 【시험 포인트】 온프레미스/비 AWS 워크로드의 안전한 임시 자격 증명 → IAM Roles Anywhere. 장기 액세스 키는 오답.

해설

【핵심 용어】 ▸ AWS Transit Gateway — 다수 VPC·계정·온프레미스(DX/VPN)를 허브-스포크로 연결하는 관리형 라우터, 신규 계정 추가가 간단 ▸ AWS Direct Connect (DX) — 온프레미스↔AWS 전용 회선, TGW에 연결해 공유 가능 ▸ 계정별 DX/VPN — 신규 계정마다 개별 연결은 비용·운영 부담 【정답 포인트】 ▸ "추가 계정들이 온프레미스 네트워크 서비스에 빠르고 저렴·일관되게 접근" + "LEAST overhead" → Transit Gateway로 계정 연결 후 DX를 TGW에 붙여 공유하면 신규 계정 확장이 용이 【오답 체크】 (A) 계정마다 DX 연결 생성은 비용·리드타임 과다. (B) VPC 엔드포인트는 AWS 서비스용이며 온프레미스 디렉터리/DNS 공유에 부적합. (C) 계정마다 VPN 연결 생성은 관리 오버헤드 증가. 【시험 포인트】 "다수 계정 + 온프레미스 공유 + 확장성" → Transit Gateway 허브. DX/VPN 계정별 반복은 오답.

해설

【핵심 용어】 ▸ Amazon CloudFront — 글로벌 엣지 CDN, 정적뿐 아니라 동적 콘텐츠도 엣지 경유로 가속, 기존 ALB를 오리진으로 지정 가능 ▸ ALB 오리진 — 기존 EC2/ASG 아키텍처 변경 없이 CloudFront 앞단만 추가 ▸ Global content delivery — 캐싱 + 엣지 연결 최적화 【정답 포인트】 ▸ "serve dynamic content globally" + "cost-optimized" + 기존 ALB 활용 → 기존 ALB를 오리진으로 CloudFront 배포만 추가하면 글로벌 성능·비용 최적 【오답 체크】 (B) Route 53 지리 라우팅은 캐싱/엣지 가속 없이 단순 DNS 라우팅이라 글로벌 동적 전송 개선 제한적. (C) S3 정적 웹 호스팅은 동적 콘텐츠를 제공할 수 없음. (D) Direct Connect는 특정 온프레미스 전용 연결로 글로벌 고객 대상 콘텐츠 전송에 부적합. 【시험 포인트】 "글로벌 콘텐츠 전송(동적 포함) + 기존 ALB" → CloudFront + ALB 오리진.

해설

【핵심 용어】 ▸ S3 Intelligent-Tiering — 접근 패턴을 자동 모니터링해 계층 이동, 예측 불가·가변 접근에 비용 최적, 검색 수수료 없음, Standard급 내구성·가용성 ▸ S3 Standard — 자동 비용 최적화 없음 ▸ S3 One Zone-IA — 단일 AZ로 가용성·내구성(AZ 손실 위험) 낮음 【정답 포인트】 ▸ "지속 사용 + 일부는 수개월 미사용(가변 접근)" + "최고 내구성·고가용 유지 + 비용 효율" → 접근 패턴 자동 최적화하는 Intelligent-Tiering 【오답 체크】 (A) S3 Standard는 미사용 데이터에 대한 자동 비용 절감이 없어 가변 패턴에 비효율. (C) Glacier Deep Archive는 아카이브용으로 상시 접근 워크로드에 부적합. (D) One Zone-IA는 단일 AZ라 요구되는 최고 내구성·고가용에 미달. 【시험 포인트】 "접근 패턴 가변·예측 불가 + 자동 비용 최적" → Intelligent-Tiering. 단일 AZ 계층은 가용성 요건에서 탈락.

해설

【핵심 용어】 ▸ Amazon EFS — 완전관리형 NFS 파일 시스템, 다중 AZ에서 여러 EC2가 동시 마운트/공유, 자동 확장, NFS 기반이라 코드 변경 최소 ▸ Auto Scaling group 공유 스토리지 — 모든 인스턴스가 동일 데이터 접근 필요 ▸ EBS — 기본적으로 단일 인스턴스·단일 AZ 종속 【정답 포인트】 ▸ "ASG의 여러 EC2가 동일 데이터 공유" + "고가용·복원력" + "코드 변경 최소" → 다중 AZ 공유 파일 시스템인 EFS(General Purpose 모드) 【오답 체크】 (A) 단일 EC2 NFS 서버 + 단일 EBS는 단일 장애점(SPOF)이라 고가용 미달. (B) FSx for Windows를 단일 AZ SMB로 구성하면 고가용성 부족(+SMB/Windows 전제). (C) EBS 볼륨은 다수 인스턴스 공유에 부적합(단일 AZ·연결 제약). 【시험 포인트】 "여러 EC2/다중 AZ 공유 + 파일 스토리지" → EFS. EBS/단일 서버는 공유·HA 요건에서 탈락.

해설

【핵심 용어】 ▸ Network Load Balancer — L4(TCP/UDP) 초고성능 로드밸런서, TCP 애플리케이션에 적합, 다중 AZ 분산 ▸ EC2 Auto Scaling group — 사용자 증가에 따라 자동 확장/축소, 고가용성 확보 ▸ Application Load Balancer — L7(HTTP/HTTPS) 전용 【정답 포인트】 ▸ (A) "End users use TCP" → L4 처리 NLB로 트래픽 분산 ▸ (B) "highly available + automatically scale" → Auto Scaling group으로 인스턴스 자동 확장 + 다중 AZ 고가용 【오답 체크】 (C) ALB는 L7(HTTP) 전용으로 순수 TCP 통신에 부적합. (D) 수동 인스턴스 추가는 자동 확장 요건 미충족. (E) Gateway Load Balancer는 방화벽 등 가상 어플라이언스용. 【시험 포인트】 TCP + 자동확장 + HA = NLB + Auto Scaling group. HTTP면 ALB.

해설

【핵심 용어】 ▸ AWS Organizations Tag Policy — 태그 키·허용 값 표준화 강제, EC2 등 리소스에 지정 값 적용 강제 가능 ▸ Service Control Policy (SCP) — 계정/OU에 대한 최대 권한 경계, 특정 액션 Deny 가능(태그 없는 인스턴스 생성 거부, 태그 삭제 거부) ▸ OU(조직 단위) — 정책 부착 대상 【정답 포인트】 ▸ (A) 태그 정책으로 data sensitivity 키와 허용 값(sensitive/nonsensitive)을 표준화·강제 ▸ (D) SCP로 "태그 키 없이 인스턴스 생성 거부" + "태그 삭제 거부"를 Deny로 강제 【오답 체크】 (B) SCP는 태그 값 표준화/강제 기능이 아님(값 표준화는 태그 정책 역할). (C) 태그 정책은 인스턴스 실행 자체를 거부(Deny)하거나 태그 삭제를 차단하는 강제 기능이 없음. (E) Config 규칙 + Lambda 삭제는 사후 탐지·복잡도 증가로 예방적 강제와 다름. 【시험 포인트】 값 표준화=Tag Policy, 액션 거부(생성/삭제 차단)=SCP. Deny 강제는 SCP의 몫.

해설

【핵심 용어】 ▸ RDS 자동 백업 보존 기간 — 최대 35일 내 설정 가능(30일 설정 가능), 추가 서비스 없이 콘솔 설정으로 관리 ▸ RDS 수동 스냅샷 — 사용자가 명시 삭제 전까지 유지 ▸ 30일 보존 정책 — 자동·수동 백업 모두 30일 미만분 유지 목표 【정답 포인트】 ▸ "30일 보존" + "기존 자동·수동 백업(30일 미만) 유지" + "MOST cost-effective" → 자동 백업 보존을 30일로 설정하고, 수동 스냅샷은 30일 초과분만 수동 삭제(추가 서비스 불필요) 【오답 체크】 (A) AWS Backup 사용은 불필요한 서비스 추가로 비용·복잡도 증가. (B) 자동 백업 비활성화·기존 백업 삭제는 30일 미만 기존 백업 유지 요건 위배. (D) CloudFormation으로 삭제 자동화는 과도한 오버헤드. 【시험 포인트】 RDS 30일 보존은 자동 백업 보존 기간(최대 35일 이내) 설정으로 충분. AWS Backup/CFN은 오버엔지니어링.

해설

【핵심 용어】 ▸ Amazon EFS — NFS 프로토콜 기반 완전관리형 파일 시스템, 애플리케이션 프로토콜 변경 없이 그대로 사용 가능 ▸ NFS 요구 — 애플리케이션이 NFS 외 프로토콜로 수정 불가 ▸ DataSync/EBS/EMRFS — 각각 전송 서비스/블록/S3 기반으로 NFS 스토리지 아님 【정답 포인트】 ▸ "NFS로만 통신 가능, 코드 수정 불가" → NFS를 네이티브 지원하는 EFS가 유일 적합 【오답 체크】 (A) DataSync는 데이터 전송 서비스이지 상시 스토리지가 아님. (B) EBS는 블록 스토리지로 NFS 파일 공유 프로토콜 미지원. (D) EMRFS는 EMR용 S3 기반 파일 시스템으로 NFS 아님. 【시험 포인트】 "NFS 프로토콜 필수" → EFS. 블록(EBS)·전송도구(DataSync)는 제외.

해설

【핵심 용어】 ▸ Amazon SQS — 완전관리형 메시지 큐, 유입 트래픽 버퍼링·디커플링으로 처리 폭주 방지, 메시지 보존으로 재처리(replay) 가능 ▸ 데이터 유실 방지 — 폭주 시 큐에 저장 후 소비자가 폴링 ▸ 최소 운영 오버헤드 — 관리형 큐로 자동 스케일 【정답 포인트】 ▸ "폭주로 데이터 유실 + 재생 불가 방지" + "least overhead" → SQS 큐로 유입을 버퍼링하고 애플리케이션이 폴링 처리, 미처리 메시지는 큐에 남아 재처리 가능 【오답 체크】 (A) S3 저장 후 스캔 방식은 이벤트 버퍼링·순서 처리 큐로서는 부자연스럽고 스캔 오버헤드. (B) API Gateway + Lambda는 유입을 완충하지 않아 폭주 시 여전히 유실 위험. (D) DynamoDB 저장·쿼리 + TTL은 큐 대비 구현 복잡도 증가. 【시험 포인트】 "트래픽 폭주 완충 + 유실 방지 + 재처리 + 최소 운영" → SQS로 디커플링.

해설

【핵심 용어】 ▸ RDS 프라이빗 서브넷 배치 — 인터넷 미노출로 보안 강화 ▸ AWS Site-to-Site VPN — 온프레미스 고객 게이트웨이↔VPC 간 암호화 터널로 프라이빗 직접 연결 ▸ RDS 보안 그룹 — 소스 IP/보안 그룹 기반 접근 제어(단, 프라이빗 리소스에 인터넷 경로 제공은 아님) 【정답 포인트】 ▸ "온프레미스 데스크톱 클라이언트가 RDS에 직접 연결 + MOST securely" → RDS를 프라이빗 서브넷에 두고 Site-to-Site VPN으로 사무실↔VPC를 암호화 연결 【오답 체크】 (A) RDS를 퍼블릭 서브넷에 두는 구성은 노출 위험으로 보안 미흡. (C) 프라이빗 서브넷 RDS에 사무실 IP만 보안 그룹 허용해도 인터넷 경로가 없어 실제 연결이 성립하지 않음(VPN 없이는 도달 불가). (D) 퍼블릭 서브넷 배치는 보안상 부적합. 【시험 포인트】 "온프레미스→프라이빗 RDS 안전 연결" → 프라이빗 서브넷 + Site-to-Site VPN. 퍼블릭 배치는 오답.

해설

【핵심 용어】 ▸ 동일 AZ 내 데이터 전송 — 프라이빗 IP 사용 시 무료(인스턴스 간 통신 비용 절감) ▸ 교차 AZ 전송 — GB당 요금 부과 ▸ EC2 간 대량 네트워크 전송 — 배치 처리에서 전송 비용이 주요 비용 요소 【정답 포인트】 ▸ "EC2 인스턴스 간 네트워크 전송 비용 절감" → 모든 EC2를 동일 AZ에 배치하면 프라이빗 IP 인스턴스 간 전송이 무료 【오답 체크】 (A) Auto Scaling group은 전송 비용과 무관. (B) 동일 Region이라도 AZ가 다르면 교차 AZ 전송 요금 발생. (D) 다중 AZ 프라이빗 서브넷 배치는 교차 AZ 전송 비용을 유발. 【시험 포인트】 인스턴스 간 전송 비용 최소화 = 같은 AZ. 가용성보다 비용이 초점일 때의 트레이드오프.

해설

【핵심 용어】 ▸ AWS Secrets Manager — 자격 증명 저장·자동 교체(rotation) 관리형 서비스, RDS/Aurora와 통합해 커스텀 주기(14일) 자동 회전 ▸ KMS 암호화 — 시크릿을 KMS 키로 암호화 ▸ Parameter Store — SecureString 저장 가능하나 자동 회전은 별도 Lambda 구현 필요 【정답 포인트】 ▸ "자격 증명 암호화 + 14일마다 교체" + "LEAST effort" → Secrets Manager 시크릿을 KMS로 암호화하고 Aurora와 연동해 14일 커스텀 회전 자동화 【오답 체크】 (B) Parameter Store는 회전을 위한 Lambda를 직접 구현·운영해야 해 노력 큼. (C) EFS에 자격 파일 저장 + Lambda 회전은 복잡도·운영 부담 과다. (D) S3에 자격 파일 저장 + 정기 다운로드 + Lambda 회전은 관리 오버헤드 큼. 【시험 포인트】 "자격 증명 자동 교체 + 최소 노력" → Secrets Manager rotation. Parameter Store는 회전 자동화 미내장.

해설

【핵심 용어】 ▸ Amazon ECS + AWS Fargate — 서버리스 컨테이너 실행, 실행 시간 제한 없음, 수요에 따라 자동 스케일, 인프라 관리 불필요 ▸ AWS Lambda — 최대 실행 15분 제한(20분 처리 불가) ▸ 대용량(TB) 비디오 처리(최대 20분) — 장시간·확장·비용 균형 필요 【정답 포인트】 ▸ "20분 소요 처리" + "수요에 따라 스케일 + 비용 효율" → 시간 제한 없이 서버리스로 스케일하는 ECS/Fargate 마이크로서비스가 적합 【오답 체크】 (A) Lambda는 최대 15분 제한이라 20분 비디오 처리 불가. (C) EC2 ASG + ALB + SQS는 인프라 관리·비용 측면에서 Fargate 대비 비효율(ALB도 처리에 불필요). (D) EKS on EC2는 관리 오버헤드 크고, RDS 단일 AZ·Glacier Deep Archive(처리용 콘텐츠 저장에 부적합)로 부적절. 【시험 포인트】 "15분 초과 작업 + 서버리스 스케일" → Fargate. Lambda 15분 제한이 결정적 배제 기준.

해설

【핵심 용어】 ▸ AWS Fargate (EKS) — EKS Pod를 서버리스로 실행, 노드(EC2) 관리 불필요, Fargate 프로파일로 Pod 배포 ▸ EKS 관리형 노드 그룹 — EC2 노드 프로비저닝을 일부 자동화하나 여전히 EC2 관리 존재 ▸ 자체 관리 노드 — 사용자가 EC2 직접 관리 【정답 포인트】 ▸ "기반 컴퓨팅 인프라를 관리하고 싶지 않음" + "LEAST overhead" → EC2 노드가 아예 없는 Fargate로 EKS Pod 실행 【오답 체크】 (A) 자체 관리 노드는 EC2를 직접 운영해야 함. (B) 관리형 노드 그룹도 결국 EC2 노드 관리(패치·스케일)가 남음. (D) 관리형 노드 그룹 + Karpenter 역시 EC2 기반이라 인프라 관리 필요. 【시험 포인트】 "EKS + 노드/컴퓨팅 관리 불원" → Fargate. 노드 그룹류는 EC2 관리가 남음.

해설

【핵심 용어】 ▸ Amazon Aurora Serverless — 구조화된 관계형 DB, 트래픽에 따라 용량 서버리스 자동 스케일, 자동 백업 내장, 비용 효율 ▸ 구조화 데이터(사용자 프로필·설정·트랜잭션) — 관계형 DB 적합 ▸ 자체 관리 EC2 DB — 운영 오버헤드·중단 위험 【정답 포인트】 ▸ "structured database" + "scalable with traffic" + "backups" + "MOST cost-effective" → 트래픽에 맞춰 자동 스케일하고 백업을 제공하는 Aurora Serverless 【오답 체크】 (A) EC2 자체 관리 + Spot은 운영 부담·Spot 중단 위험으로 트랜잭션 DB에 부적합. (B) RDS 고정 인스턴스는 가변 트래픽에 대해 서버리스 자동 스케일 대비 비용 효율 낮음. (D) 자체 관리 NoSQL은 구조화 관계형 요건과 불일치 + 운영 오버헤드. 【시험 포인트】 "구조화(관계형) + 트래픽 자동 스케일 + 백업 + 비용 최적" → Aurora Serverless.