정답 · 해설

해설

【핵심 용어】 ▸ AWS Control Tower — 멀티 계정 자동 프로비저닝 + 가드레일(보안 통제) 자동 적용 ▸ AWS RAM(Resource Access Manager) — 중앙 네트워킹 계정의 VPC 서브넷을 워크로드 계정과 공유 ▸ 공유 VPC 모델 → 네트워킹 중앙 관리 【정답 포인트】 ▸ "계정별 격리 + 자동 가드레일" → Control Tower로 계정 배포(가드레일 자동)(A) ▸ "네트워킹 중앙 관리 + 최소 운영" → 네트워킹 계정 VPC 서브넷을 RAM으로 워크로드 계정에 공유 【오답 체크】 (B) Organizations 단독은 가드레일(보안 통제) 자동화가 없어 Control Tower보다 운영 부담 큼. (C) 계정마다 VPC + 인스펙션 VPC/TGW 라우팅은 네트워킹 중앙 공유보다 운영 복잡. (D) Organizations + 계정별 VPC/TGW 역시 가드레일 자동화 부재 + 네트워크 관리 부담 큼. 【시험 포인트】 계정 자동 생성 + 가드레일 → Control Tower. 네트워킹 중앙 공유 → RAM으로 서브넷 공유(계정마다 VPC 대비 운영 최소).

해설

【핵심 용어】 ▸ Amazon S3 정적 웹 호스팅 — 서버 없이 정적 콘텐츠 제공, 매우 저렴 ▸ Amazon CloudFront — 글로벌 CDN 캐싱으로 트래픽 증가에도 오리진 부하·비용 절감 ▸ ALB + EC2 → 정적 콘텐츠엔 과도한 상시 비용 【정답 포인트】 ▸ "정적 콘텐츠" + "트래픽 증가" + "호스팅 비용 최소화" → S3에 사이트 이전 + CloudFront 배포(A) ▸ S3(저장) + CloudFront(캐싱)로 EC2/ALB 상시 비용 제거, 트래픽 증가에도 저렴 【오답 체크】 (B) ElastiCache는 S3 정적 콘텐츠 앞단 캐시 용도가 아님(CDN이 정답). (C) Amplify + ALB 조합은 불필요한 ALB 비용, 구성도 부자연스러움. (D) Amplify + EC2 캐싱은 EC2 상시 비용을 다시 들여 비용 절감 목표에 반함. 【시험 포인트】 정적 웹 + 비용 최소 + 글로벌 트래픽 → S3 + CloudFront. EC2/ALB는 정적 콘텐츠에 과함.

해설

【핵심 용어】 ▸ Amazon FSx for Windows File Server — 완전관리형 SMB 파일 스토리지, Windows/SMB 클라이언트 네이티브 지원 ▸ SMB 프로토콜 → Windows 파일 공유 ▸ Storage Gateway Volume/Tape Gateway — 블록(iSCSI)/백업 테이프용으로 SMB 파일 공유가 아님 【정답 포인트】 ▸ "SMB 클라이언트로 공유 스토리지 접근" + "최소 관리 부담" → 완전관리형 FSx for Windows File Server(D) ▸ SMB 네이티브 지원 + 관리형이라 서버 운영 불필요 【오답 체크】 (A) Volume Gateway는 iSCSI 블록 스토리지로 SMB 파일 공유 프로토콜이 아님. (B) Tape Gateway는 가상 테이프 백업용으로 파일 공유와 무관. (C) EC2 Windows 파일 서버 자체 구축은 OS·패치·가용성 운영 부담이 큼. 【시험 포인트】 SMB(Windows) 파일 공유 + 최소 관리 → Amazon FSx for Windows File Server. NFS/Linux면 FSx나 EFS, 관리형이 정답.

해설

【핵심 용어】 ▸ Aurora Global Database — 리전 간 저지연 복제(보통 RPO 1초 미만, RTO 1분 내 승격), 관리형 페일오버 ▸ RPO 5분 / RTO 20분 목표 + 구성 변경 최소 + 최고 운영 효율 ▸ Read replica / DMS 대비 관리형·저지연 우위 【정답 포인트】 ▸ "RPO 5분·RTO 20분 + 구성 변경 최소 + 운영 효율" → Aurora Global Database 변환 + 관리형 페일오버(B) ▸ 리전 간 짧은 복제 지연으로 RPO/RTO 충족, 관리형이라 운영 부담 최소 【오답 체크】 (A) 크로스 리전 read replica는 Global Database보다 복제 지연·페일오버 관리 부담이 큼. (C) 새 클러스터 + CRR 수동 구성은 운영 효율이 떨어짐. (D) DMS 동기화는 지속 운영·모니터링 부담이 크고 DR 자동화에 부적합. 【시험 포인트】 Aurora 리전 간 DR + 낮은 RPO/RTO + 운영 효율 → Aurora Global Database(관리형 페일오버).

해설

【핵심 용어】 ▸ Amazon Security Lake — 조직 전반 보안 데이터를 OCSF 표준으로 자동 수집·중앙화(S3 데이터 레이크) ▸ 최소 개발 노력으로 보안 데이터 중앙 집계 ▸ Lake Formation/Glue 대비 관리형·목적 특화 【정답 포인트】 ▸ "회사 전체 보안 데이터 중앙 수집" + "최소 개발 노력" → 관리형 Amazon Security Lake로 자동 수집·정규화(C) ▸ 다양한 소스를 표준 포맷으로 S3에 집계, 커스텀 파이프라인 불필요 【오답 체크】 (A) Lake Formation + Glue 크롤러는 직접 구성·ETL 개발 부담이 큼. (B) Lambda로 CSV 수집·업로드는 커스텀 개발이 필요. (D) DMS + RDS는 DB 마이그레이션 도구로 보안 데이터 집계 목적과 무관. 【시험 포인트】 보안 데이터 중앙 집계 + 최소 개발 → Amazon Security Lake(관리형, OCSF 표준화).

해설

【핵심 용어】 ▸ AWS Transit Gateway — 다수 VPC·온프레미스를 허브로 연결, 100개 이상 확장에 최적 ▸ VPC Peering — 1:1 비전이(non-transitive), 다수 VPC 풀 메시 시 연결 폭증 ▸ 공유 서비스 VPC + 상호 통신 요구 【정답 포인트】 ▸ "다수 VPC 상호 통신 + 공유 서비스 VPC + 100개 이상 확장 + 최소 관리" → Transit Gateway 허브로 모든 VPC 연결(D) ▸ 각 VPC를 TGW에 연결하면 확장 시 신규 VPC만 붙이면 되어 관리 최소 【오답 체크】 (A) 소프트웨어 VPN 터널은 구성·운영 부담이 크고 확장성 낮음. (B) VPC Peering은 비전이라 다수 VPC 상호 통신 시 연결 수가 폭발(N제곱), 100+엔 부적합. (C) Direct Connect는 온프레미스↔AWS 전용선으로 VPC 간 연결 솔루션이 아님. 【시험 포인트】 다수 VPC(+온프레미스) 상호 연결 + 대규모 확장 + 최소 관리 → Transit Gateway. Peering은 소수·비전이라 대규모에 부적합.

해설

【핵심 용어】 ▸ Amazon ECS Anywhere(external launch type) — 온프레미스 서버에서 ECS 태스크 실행, 하이브리드 단일 관리 ▸ AWS Fargate — 클라우드 서버리스 컨테이너 실행 ▸ Application Load Balancer — HTTP/HTTPS(L7) 트래픽 분산 【정답 포인트】 ▸ "온프레미스·하이브리드·클라우드 단일 컨테이너 솔루션" → 클라우드는 Fargate, 온프레미스는 ECS Anywhere(external) 런치 타입(A) ▸ "HTTP 트래픽 로드밸런서" → ALB(L7)로 클라우드 ECS 서비스 분산(B) 【오답 체크】 (C) NLB는 L4로 HTTP 요구에 부적합(HTTP는 ALB). (D) Fargate 런치 타입은 온프레미스 컨테이너를 실행할 수 없음(온프레미스는 ECS Anywhere 필요). (E) ECS Anywhere는 external 런치 타입이며 "Fargate 런치 타입"과 결합한다는 서술이 잘못됨. 【시험 포인트】 온프레미스 컨테이너를 ECS로 관리 → ECS Anywhere(external). 클라우드 서버리스 → Fargate. HTTP 분산 → ALB.

해설

【핵심 용어】 ▸ Amazon RDS Multi-AZ — 관리형 관계형 DB, 자동 백업·패치·페일오버로 운영 부담↓, 고가용성 ▸ RDS for SQL Server — SQL Server 관리형 지원 ▸ AWS KMS 암호화 — 저장 데이터 암호화로 보안 강화 【정답 포인트】 ▸ "SQL Server를 클라우드로 이전 + 보안 강화 + 운영 부담 감소" → 관리형 Multi-AZ RDS for SQL Server + KMS 암호화(B) ▸ Multi-AZ로 가용성, KMS로 저장 암호화, 관리형으로 패치·백업 자동화 【오답 체크】 (A) EC2로 이전은 OS·DB 패치·백업을 직접 관리해야 해 운영 부담 감소 목표에 반함. (C) S3 + Macie는 관계형 DB 워크로드에 부적합(객체 스토리지). (D) DynamoDB는 NoSQL이라 SQL Server 관계형 앱과 호환되지 않음. 【시험 포인트】 관계형 DB 클라우드 이전 + 운영 부담↓ + 보안 → RDS Multi-AZ + KMS. EC2 자체 관리·NoSQL 전환은 오답.

해설

【핵심 용어】 ▸ Auto Scaling group(Multi-AZ) — 여러 AZ에 인스턴스 분산·자동 확장으로 가용성 향상 ▸ Application Load Balancer — 트래픽 분산, WAF 연결 지점(WAF는 ALB/CloudFront/API GW에 연결) ▸ AWS WAF — L7 웹 공격 방어, ALB에 연결 가능 【정답 포인트】 ▸ "가용성 향상 + WAF 사용" → 2개 AZ에 걸친 Auto Scaling group + ALB + ALB에 WAF 연결(A) ▸ ASG로 확장·복구, ALB로 분산, WAF는 ALB에 부착(정상 연결 대상) 【오답 체크】 (B) 클러스터 배치 그룹은 단일 AZ 저지연용으로 가용성에 반하고, WAF는 배치 그룹에 연결 불가. (C) 고정 EC2 2대는 자동 확장·복구가 없어 ASG보다 가용성 낮음. (D) WAF는 Auto Scaling group에 직접 연결할 수 없음(ALB/CloudFront/API GW에 연결). 【시험 포인트】 가용성 → Multi-AZ ASG + ALB. WAF는 ALB/CloudFront/API Gateway에 연결(ASG·배치 그룹에는 불가).

해설

【핵심 용어】 ▸ Amazon S3 Access Points — 버킷 내 접근을 애플리케이션별 이름 있는 엔드포인트+정책으로 분리, 세분화 제어 ▸ 접두사(prefix)별 접근 제한 → 각 접근 지점 정책으로 prefix 한정 ▸ 단일 버킷 정책 관리 복잡성 완화 【정답 포인트】 ▸ "앱마다 자기 prefix로 제한 + 세분화 제어 + 최소 운영" → 앱별 전용 S3 Access Point + 접근 지점 정책(A) ▸ 각 접근 지점 정책으로 해당 prefix만 허용, 버킷 정책 비대화 없이 확장 용이 【오답 체크】 (B) 오브젝트별 ACL 설정 배치 작업은 대규모에서 관리 부담이 크고 권장되지 않음. (C) 앱별 버킷 복제는 데이터 중복·복제 비용·관리 부담 증가. (D) 복제 후 접근 지점 구성은 불필요한 데이터 복제 단계가 추가되어 오버헤드 증가. 【시험 포인트】 단일 버킷 내 앱/prefix별 세분화 접근 + 최소 운영 → S3 Access Points + 접근 지점 정책.

해설

【핵심 용어】 ▸ S3 Event Notifications → SQS → Lambda — 업로드 이벤트를 큐로 버퍼링, Lambda가 소비해 처리(디커플링·재시도) ▸ AWS Lambda — 2분/512MB 처리에 정확히 부합하는 서버리스(사용분만 과금) ▸ 이벤트 기반 즉시 처리로 야간 배치 대체 【정답 포인트】 ▸ "업로드 시 즉시 처리 + 2분·512MB + 최저 비용" → S3 이벤트 → SQS → Lambda(A) ▸ SQS로 안정적 버퍼링, Lambda는 유휴 비용 0이며 짧은 작업에 최적 【오답 체크】 (B) EC2 예약 인스턴스는 상시 비용이 들어 이벤트성 짧은 작업에 비효율. (C) ECS 컨테이너 인스턴스 상시 구독·구동은 서버리스 대비 비용·운영 부담 큼. (D) Elastic Beanstalk는 상시 환경 유지 비용이 들어 최저 비용 목표에 반함. 【시험 포인트】 업로드 즉시 처리 + 짧은 작업 + 최저 비용 → S3 Event → SQS → Lambda. 상시 EC2/ECS/Beanstalk는 유휴 비용으로 탈락.

해설

【핵심 용어】 ▸ AWS Global Accelerator — TCP/UDP를 AWS 백본으로 가속, 정적 애니캐스트 IP로 최근접 리전 라우팅(L4, 게임/실시간 최적) ▸ Network Load Balancer — L4(TCP/UDP) 분산, Global Accelerator 엔드포인트로 등록 ▸ TCP(EC2, 다중 리전) + UDP(온프레미스) 하이브리드 【정답 포인트】 ▸ "TCP/UDP 워크로드 가용성·성능 향상" → Global Accelerator로 로드밸런서를 엔드포인트로 등록(A) ▸ TCP/UDP 모두 L4이므로 각 리전에 NLB 구성(EC2용, 온프레미스용) → Global Accelerator가 최근접 라우팅(D) 【오답 체크】 (B) CloudFront는 HTTP(S) 콘텐츠 캐싱 중심으로 TCP/UDP 상태 저장 워크로드에 부적합. (C) ALB는 L7(HTTP)이라 TCP/UDP 워크로드에 맞지 않음. (E) 온프레미스 UDP에 ALB(L7)는 부적합, UDP는 NLB여야 함. 【시험 포인트】 TCP/UDP 글로벌 가속·성능·가용성 → Global Accelerator + NLB(L4). HTTP가 아니면 CloudFront/ALB 배제.

해설

【핵심 용어】 ▸ Recycle Bin(for EBS Snapshots) — 삭제된 스냅샷을 보존 규칙 기간 동안 복구 가능하게 보관, 실수 삭제 방지 ▸ 보존 규칙(retention rule) — 예: 7일 후 자동 영구 삭제(무기한 보관 방지) ▸ 최소 개발 노력으로 데이터 손실 방지 【정답 포인트】 ▸ "스냅샷 실수 삭제 방지 + 무기한 보관은 원치 않음 + 최소 개발" → Recycle Bin 7일 보존 규칙 적용(C) ▸ 삭제돼도 7일간 복구 가능, 이후 자동 정리 → 코드 변경 없이 관리형으로 해결 【오답 체크】 (A) IAM 삭제 거부 정책은 정당한 삭제까지 막고, 스크립트 실수 시나리오 대응이 경직됨. (B) 다른 리전 복사는 복제 비용·관리 증가, 실수 삭제 근본 방지책이 아님. (D) S3 IA로 스냅샷 복사는 EBS 스냅샷 관리 방식이 아니며 개발 부담·복잡도 증가. 【시험 포인트】 스냅샷/S3 객체 실수 삭제 복구 + 기간 제한 보관 + 최소 노력 → Recycle Bin 보존 규칙.

해설

【핵심 용어】 ▸ S3 Presigned URL — 시간 제한 서명 URL로 비공개 객체에 임시 접근 부여(퍼블릭 개방 없이) ▸ CloudFormation 템플릿 URL — 스택 생성 시 템플릿 위치 지정 ▸ 퍼블릭 차단 버킷 + 사용자 요청 기반 접근 + 보안 모범 사례 【정답 포인트】 ▸ "퍼블릭 차단 버킷 템플릿을 특정 요청 시에만 접근 + 보안 모범 사례" → presigned URL 생성 후 CloudFormation이 해당 URL 사용(C) ▸ 서명 URL은 만료 시간이 있어 퍼블릭 개방 없이 한시적 접근 제공 【오답 체크】 (A) 게이트웨이 VPC 엔드포인트 + S3 객체 URL만으로는 퍼블릭 차단 객체 접근·요청 기반 통제가 불충분. (B) API Gateway를 S3 프록시로 두는 구성은 과도하고 목적에 맞지 않음. (D) 퍼블릭 개방 후 재차단은 노출 창이 생겨 보안 모범 사례에 정면 위배. 【시험 포인트】 비공개 S3 객체 임시·한시 접근 + 퍼블릭 개방 금지 → Presigned URL.

해설

【핵심 용어】 ▸ AWS Systems Manager Session Manager — SSH·베스천·인바운드 포트 없이 프라이빗 EC2 셸 접근, 감사·통제 우수 ▸ IAM Identity Center(구 SSO) — 외부 엔지니어에게 콘솔 접근을 중앙 페더레이션으로 안전 제공 ▸ SSM Agent + 인스턴스 프로파일 → Session Manager 연결 전제 【정답 포인트】 ▸ "외부 엔지니어에게 콘솔 + 프라이빗 Linux EC2 OS 접근 + 가장 안전" → IAM Identity Center로 콘솔 접근, Session Manager로 OS 접근(A) ▸ SSM Agent·인스턴스 프로파일 준비 후 Session Manager 사용 → 인바운드 포트·키 관리 불필요 【오답 체크】 (B) 각 계정에 로컬 IAM 사용자 자격 증명 배포는 중앙 관리·보안이 약함. (C) SSH 인바운드 개방 + 로컬 IAM 사용자 + 키 배포는 공격 표면·자격 관리 리스크 큼. (D) 베스천 호스트 + SSH 키 + 로컬 IAM 사용자는 관리 부담·노출 위험이 큼. 【시험 포인트】 프라이빗 EC2 안전 접근 → Session Manager(포트·베스천·키 불필요). 외부 사용자 콘솔 접근 → IAM Identity Center.

해설

【핵심 용어】 ▸ Amazon RDS Read Replica(동일 리전) — 읽기(리포트) 트래픽을 복제본으로 오프로딩해 기본 DB 부하 감소, 저비용 ▸ 리포트가 같은 DB에서 생성되어 업무 시간 성능 저하 → 읽기 분리 ▸ 크로스 리전 replica/DMS 대비 저비용·단순 【정답 포인트】 ▸ "리포트로 인한 성능 저하 + 비용 효율" → 동일 리전(us-east-1) read replica 생성 후 리포트를 복제본에서 생성(D) ▸ 읽기 부하를 복제본으로 분리해 운영 DB 성능 회복, 크로스 리전보다 저렴 【오답 체크】 (A) 크로스 리전 read replica는 리전 간 데이터 전송 비용 발생으로 동일 리전보다 비쌈. (B) Multi-AZ 대기(standby)는 페일오버용이며 읽기 트래픽 처리에 사용 불가. (C) DMS 논리 복제는 지속 운영 부담·비용이 커 비용 효율 목표에 반함. 【시험 포인트】 읽기(리포트) 부하 분리 + 최저 비용 → 동일 리전 RDS Read Replica. Multi-AZ standby는 읽기용 아님.

해설

【핵심 용어】 ▸ EC2 상세 모니터링(Detailed Monitoring) — CloudWatch 메트릭을 1분 주기로 수집(기본은 5분) ▸ 2분 이하 세분화 요구 → 1분 상세 모니터링 필요 ▸ CloudWatch 메트릭 분석 【정답 포인트】 ▸ "2분 이하 세분화로 성능 분석" → 모든 EC2에 상세 모니터링 활성화(1분 주기) + CloudWatch 메트릭 분석(B) ▸ 기본 5분으론 2분 요구 미달, 상세 모니터링이 1분 세분화 제공 【오답 체크】 (A) CloudWatch 로그→Redshift→QuickSight는 과도하고 세분화 요구와 직접 관련 없음. (C) Lambda로 로그 수집은 불필요한 구성, 세분화는 상세 모니터링으로 해결됨. (D) EC2 로그→S3→Redshift→QuickSight는 복잡·과도하며 목적(성능 메트릭 세분화)과 어긋남. 【시험 포인트】 2분 이하(1분) 메트릭 세분화 → EC2 Detailed Monitoring 활성화(기본 5분 → 1분).

해설

【핵심 용어】 ▸ S3 Event Notification → Lambda — 업로드 즉시 이벤트 기반 처리(서버리스, 사용분 과금) ▸ 하루 약 150장 → 저빈도 이벤트, Lambda가 최저 비용 ▸ 상시 EC2/EMR 대비 유휴 비용 없음 【정답 포인트】 ▸ "신규 업로드마다 썸네일 생성 + 최저 비용" → S3 이벤트로 Lambda 호출해 썸네일 생성·두 번째 버킷에 저장(C) ▸ 이벤트 기반이라 유휴 비용 0, 저빈도 작업에 최적 【오답 체크】 (A) 상시 EMR 클러스터는 저빈도 작업에 비용 과다. (B) 상시 켜진 메모리 최적화 EC2는 유휴 비용이 커 비효율. (D) S3 Storage Lens는 사용 분석 지표 서비스로 Lambda를 이벤트로 호출하는 기능이 없음. 【시험 포인트】 객체 업로드 즉시 경량 처리 + 최저 비용 → S3 Event Notification + Lambda. 상시 EC2/EMR·스케줄 폴링은 오답.

해설

【핵심 용어】 ▸ S3 Inventory — 대규모 객체 목록을 파일로 생성 ▸ S3 Batch Operations — 인벤토리 기반으로 수백만 객체에 Lambda 등 작업을 대규모 수행(서버리스) ▸ Lambda로 보존 대상 필터 후 삭제 【정답 포인트】 ▸ "수백만 객체(Deep Archive)에서 3년 초과 삭제, 일부는 보존 + 서버리스" → S3 Inventory로 목록화, Lambda로 필터·삭제, S3 Batch Operations로 인벤토리 기반 대규모 실행(D) ▸ 완전 서버리스 조합으로 대량 객체 선택 삭제 처리 【오답 체크】 (A) EC2에서 CLI 스크립트 실행은 서버리스가 아니며 운영 부담 큼. (B) AWS Batch는 컴퓨팅 환경 관리가 필요해 순수 서버리스 요구에 덜 부합. (C) Glue 크롤러 + 스크립트 조합은 복잡하고 대량 객체 삭제 실행에 최적이 아님. 【시험 포인트】 대량 S3 객체 선택적 일괄 처리(삭제/복사) + 서버리스 → S3 Inventory + Batch Operations + Lambda.

해설

【핵심 용어】 ▸ Lambda 실행 역할(IAM Role per function) — 함수마다 개별 역할로 최소 권한 부여 ▸ 최소 권한 원칙 — 인가된 함수만 S3 접근 ▸ 버킷 정책/공유 역할 대비 함수별 세분화 【정답 포인트】 ▸ "인가된 Lambda만 접근 + 최소 권한" → 함수마다 개별 IAM 역할 생성, 필요한 S3 접근만 부여, 각 함수 실행 역할로 지정(C) ▸ 함수별 역할로 최소 권한과 세밀한 통제 실현 【오답 체크】 (A) 공유 역할로 전체 버킷 접근은 최소 권한 원칙에 정면 위배. (B) VPC 엔드포인트 IP 기반 버킷 정책은 함수 단위 인가를 정확히 표현하지 못함. (D) 함수 ARN 기반 버킷 정책은 신뢰할 수 있는 함수 인가 방식으로 부적절하며 관리도 취약. 【시험 포인트】 Lambda의 리소스 접근 최소 권한 → 함수별 개별 실행 역할(IAM Role). 공유 역할·전체 권한은 오답.