정답 · 해설

해설

【핵심 용어】 ▸ S3 File Gateway — SMB 프로토콜을 통한 S3 액세스 제공, 온프레미스와 AWS 간 동기화 ▸ S3 Standard-IA — 저액세스 데이터 저장에 최적, 즉시 검색 가능 ▸ S3 Glacier Deep Archive — 거의 액세스되지 않는 데이터용, 검색 시간 길음 【정답 포인트】 ▸ 5분 내 검색 필요 → Glacier Deep Archive 불가 (12시간 이상 소요) ▸ 메타데이터 파일과 이미지 파일 모두 거의 액세스되지 않음 → 동일 스토리지 클래스 사용 가능 ▸ S3 Standard-IA는 5분 내 즉시 검색 가능하므로 RTO 요구사항 충족 【오답 체크】 (A) AWS Outposts — 온프레미스 환경과 비용 효율성 측면에서 비효율적 (B) FSx for Windows — 비용이 높고 관리 오버헤드 증가 (C) Glacier Deep Archive — 5분 요구사항 충족 불가능 (복구 시간 > 12시간) 【시험 포인트】 재해복구 솔루션에서 RTO/RPO 요구사항과 스토리지 클래스 특성을 정확히 매칭해야 합니다. Glacier Deep Archive는 장기 아카이빙용이며, 빠른 검색이 필요하면 S3 Standard-IA 또는 S3 Standard를 선택합니다.

해설

【핵심 용어】 ▸ Amazon WorkSpaces — 전체 데스크톱 환경 제공, 기존 경험 복제 가능 ▸ AD Connector — 온프레미스 AD와 AWS 통합, 사용자 인증 ▸ RADIUS 서버 — 네트워크 인증 프로토콜, MFA 지원 ▸ AppStream 2.0 — 애플리케이션만 스트리밍, 전체 데스크톱 아님 【정답 포인트】 ▸ "사용자 경험 복제" → WorkSpaces (애플리케이션, 운영체제 전부) ▸ "기존 ID 자격증명" → AD Connector로 온프레미스 AD 사용 ▸ "MFA 제공" → RADIUS 서버 설정 필수 (WorkSpaces의 표준 MFA 방식) ▸ "Windows와 Linux 혼합" → WorkSpaces가 두 OS 모두 지원 【오답 체크】 (A) WorkSpaces 기본 MFA는 RADIUS 아님 (B) (D) AppStream 2.0 — 애플리케이션만 스트리밍, "완전한 데스크톱 경험" 제공 불가 【시험 포인트】 재해복구에서 WorkSpaces(데스크톱)와 AppStream(애플리케이션)의 차이를 구분하세요. 온프레미스 AD + MFA는 AD Connector + RADIUS 조합입니다.

해설

【핵심 용어】 ▸ UpdateContactAttributes API — 진행 중인 통화에 속성 추가/수정 ▸ Contact Control Panel(CCP) — 상담원 인터페이스, 커스터마이징 가능 ▸ Contact Lens — 통화 기록 및 분석 도구 (실시간 필터링 아님) 【정답 포인트】 ▸ "상담원이 플래그" → 상담원이 수동으로 조작할 수 있는 UI 필요 ▸ "자동으로 차단" → 향후 통화 시 연락처 흐름에서 자동 차단 ▸ "가장 운영 효율적" → 가장 간단한 구현 (CCP 커스터마이징 + UpdateContactAttributes) ▸ 실시간 처리 → Lambda 함수로 번호를 DynamoDB에 저장 후 흐름에서 확인 【오답 체크】 (B) Contact Lens — 통화 기록 분석용이지 실시간 필터링 아님 (C) Quick Connect — 스팸으로 표시하는 메커니즘 부족 (D) 자동 감지 — 상담원이 수동으로 표시할 수 없고 초기 흐름에 의존 【시험 포인트】 Amazon Connect에서 상담원의 수동 조작과 자동 흐름 제어를 조합할 때, CCP 커스터마이징과 UpdateContactAttributes API의 역할을 이해하세요.

해설

【핵심 용어】 ▸ Kinesis Data Firehose — S3/Redshift에 데이터 전달, 데이터 분석용 아님 ▸ Kinesis Data Stream — 실시간 스트림 처리용, Lambda 통합 가능 ▸ Lambda — 낮은 지연시간, 자동 스케일링, SNS 통합 용이 ▸ MSK — 고처리량 메시지 브로커, 이 시나리오에 과도함 【정답 포인트】 ▸ "실시간 분석" → Kinesis Data Stream (Firehose는 배치) ▸ "즉시 알림" → Lambda로 신속한 처리 (Step Functions는 오버헤드) ▸ "간단한 구현" → Lambda + SNS 조합이 가장 간단 ▸ "센서 데이터" → 불규칙한 트래픽 패턴 → 자동 스케일링 필요 【오답 체크】 (A) Firehose + Step Functions — 데이터 배치 처리, 실시간 아님 (B) MSK + Fargate — 과도한 복잡성 및 비용 (D) Kinesis Data Analytics + ECS — Analytics로 충분, ECS 불필요 【시험 포인트】 실시간 분석 시나리오: Kinesis Data Stream + Lambda는 저지연시간, 자동 스케일링, 비용 효율적입니다. Firehose는 배치 전달용, Analytics는 SQL 쿼리용입니다.

해설

【핵심 용어】 ▸ Topology Spread Constraints — 포드를 가용 영역/노드에 분산배치 ▸ Node Resilience — 노드 장애 시 다른 노드로 포드 자동 이전 ▸ Cluster Autoscaler — 필요 시 노드 추가 (복원력 아님) 【정답 포인트】 ▸ "노드 복원력 극대화" → 단일 노드 장애 시에도 서비스 지속 ▸ "위상 분산 제약" → Availability Zone 분산 (같은 AZ 노드 장애 방지) ▸ "상태 비저장 포드" → 어느 노드에서나 실행 가능 ▸ 짧은 시간의 대량 생성 → AZ 분산으로 장애 격리 【오답 체크】 (A) 제어 평면 분리 — 복원력과 무관 (B) 더 큰 인스턴스 + 적은 노드 — 단일 노드 장애 영향 증가 (C) Autoscaler underprovisioning — 스케일링 속도 저하, 복원력 아님 【시험 포인트】 노드 복원력 = 가용 영역 분산입니다. Topology Spread Constraints는 포드가 여러 AZ/노드에 분산되도록 보장하여, 단일 노드/AZ 장애 시에도 서비스 연속성을 보장합니다.

해설

【핵심 용어】 ▸ Cross-Region Read Replica — 실시간 데이터 동기화, 빠른 승격 ▸ RDS Snapshot — 시간차 백업, 복구 시간 길음 ▸ RTO 최소화 — 이미 구성된 보조 인프라 사용 【정답 포인트】 ▸ "복구 시간 최소화" → 스냅샷 복사 및 생성보다 읽기 복제본 승격 빠름 ▸ "크로스 리전 읽기 복제본" → 항상 동기화, 장애 시 즉시 승격 가능 ▸ "별도 리전 ECS 준비" → 네트워크 및 애플리케이션 구성 사전 준비 ▸ Lambda로 읽기 복제본만 승격 → 신속한 RTO 달성 【오답 체크】 (A) Snapshot 복사 + 생성 — RTO 길음 (수십 분) (B) Lambda로 클러스터 동적 생성 — 신규 생성 시간 추가로 RTO 증가 (D) DynamoDB 글로벌 테이블로 변환 불가 (RDS는 DynamoDB가 아님) 【시험 포인트】 DR 전략에서 RTO 최소화 = 사전 준비된 보조 인프라 + 실시간 데이터 동기화입니다. 크로스 리전 읽기 복제본은 이 두 요소를 모두 제공합니다.

해설

【핵심 용어】 ▸ AWS Budgets — 예산 설정 및 임계값 알람 (고정 또는 상대값) ▸ Cost Anomaly Detection — 머신러닝 기반 이상 탐지 (정확한 임계값 설정 어려움) ▸ Trusted Advisor — 모범 사례 권고 (비용 추적 아님) ▸ Amazon Detective — 보안 조사 도구 (비용 모니터링 아님) 【정답 포인트】 ▸ "10% 높은 임계값" → 정확한 임계값 설정 가능한 Budgets 필요 ▸ "일일 알람" → Budgets의 일일 기간 설정 ▸ "지난 30일 평균 + 10%" → Budgets에 고정값으로 설정 ▸ "simple" → Budgets이 가장 직관적이고 구성 용이 【오답 체크】 (B) Cost Anomaly Detection — 머신러닝 기반, "정확히 10%" 임계값 설정 불가 (C) Trusted Advisor — 권고용 도구, 비용 추적 아님 (D) Amazon Detective — 보안 조사 전문, 비용 모니터링 아님 【시험 포인트】 비용 모니터링: Budgets(예산 추적) vs Cost Anomaly Detection(이상 탐지). 정확한 임계값이 필요하면 Budgets, 자동 이상 탐지가 필요하면 Cost Anomaly Detection입니다.

해설

【핵심 용어】 ▸ Amazon SQS — 메시지 큐, 느슨한 결합, 자동 확장 ▸ AWS Lambda — 서버리스, 자동 스케일링, 산발적 트래픽 최적 ▸ Step Functions — 복잡한 워크플로우용 (주문 처리에 과도) 【정답 포인트】 ▸ "느슨한 결합" → SQS (메시지 큐) ▸ "산발적 트래픽" → Lambda 자동 스케일링 ▸ "최소 지연" → Lambda + SQS 조합 (추가 오버헤드 없음) ▸ "고가용성" → SQS의 내구성 및 Lambda의 자동 재시도 ▸ "간단" → EC2 관리 오버헤드 없음 【오답 체크】 (A) EC2 — 관리 필요, 자동 스케일링 복잡, 고가용성 보장 어려움 (C) Step Functions — 복잡한 상태 머신 관리, 단순 큐 처리엔 과도 (D) Kinesis — 실시간 분석용, 주문 처리엔 SQS가 더 적합 【시험 포인트】 느슨한 결합 + 산발적 스케일링 = SQS + Lambda. 이는 가장 신뢰할 수 있고 관리 최소화된 아키텍처입니다.

해설

【핵심 용어】 ▸ AWS Secrets Manager — 자격증명 관리, 자동 로테이션 지원 ▸ Parameter Store — 설정값 저장 (자동 로테이션 기본 미지원) ▸ 환경 변수 — Lambda에서 보안 값 참조 (코드 노출 방지) 【정답 포인트】 ▸ "자격증명 자동 회전" → Secrets Manager만 기본 지원 ▸ "코드 노출 금지" → 환경 변수로 간접 참조 ▸ "QA/프로덕션 분리" → 별도 키 항목으로 관리 ▸ "암호화" → Secrets Manager 자체 암호화 【오답 체크】 (A) Parameter Store — 자동 로테이션 지원 안 함 (수동 or 별도 Lambda 필요) (C) AWS KMS — 로테이션은 KMS 키 로테이션이지 자격증명 자동 회전 아님 (D) S3 + 명명 패턴 — 비효율적, 로테이션 기능 없음 【시험 포인트】 자격증명 자동 회전이 필수 → AWS Secrets Manager가 유일한 선택입니다. Parameter Store는 회전 기능이 없습니다.

해설

【핵심 용어】 ▸ Service Control Policy(SCP) — 명령 수준 제어 (차단) ▸ AWS Control Tower 사전 예방 제어 — 프로비저닝 시 검증 (사후 생성 방지 아님) ▸ AWS Config — 사후 감지 (차단 아님) 【정답 포인트】 ▸ "새로운 또는 기존" → 사후 감지는 부족, 사전 차단 필요 ▸ "공인 IP 획득 방지" → SCP로 API 호출 자체 차단 ▸ "신규 + 기존" → SCP는 RunInstances + AssociateAddress 모두 차단 ▸ "OU에 연결" → Control Tower 예방 제어도 OU 대상이지만, 사전 예방 제어는 프로비저닝 시점 검증만 가능 【오답 체크】 (A) Systems Manager 런북 — 사후 수정, 기존 인스턴스만 (신규 방지 아님) (B) Control Tower 사전 예방 제어 — 속성 검증이지 정책 강제 아님, "방지"할 수 없음 (D) AWS Config 수정 — 사후 감지, 신규 생성은 방지하지 못함 【시험 포인트】 신규 + 기존 모두 차단 = SCP입니다. SCP는 명령 수준에서 API 호출을 거부하므로, RunInstances와 AssociateAddress를 모두 차단할 수 있습니다.

해설

【핵심 용어】 ▸ Amazon Cognito 사용자 풀 — 사용자 인증 관리, MFA 지원 ▸ ALB 인증 통합 — 리스너 규칙에서 OIDC/Cognito 인증 강제 ▸ AWS Amplify — 프론트엔드 개발 도구 (인증 프로바이더 아님) ▸ IAM Identity Center — 직원 SSO (외부 사용자 인증 아님) 【정답 포인트】 ▸ "애플리케이션 수정 불가" → 외부 인증 (ALB 수준) ▸ "특정 사용자 목록" → Cognito 사용자 풀 ▸ "MFA 필수" → Cognito 풀 MFA 설정 ▸ "인터넷 액세스" → Cognito 호스팅 UI (타사 IdP 통합 불필요) ▸ "간단한 구현" → Cognito + ALB 리스너 규칙 【오답 체크】 (B) IAM — 직원용, 외부 사용자 관리 아님, ALB 리스너 아직 IAM 인증 지원 안 함 (C) Identity Center — 조직 직원 SSO용, 외부 사용자 아님 (D) AWS Amplify — 개발 도구, 호스팅 UI 제공 안 함 【시험 포인트】 ALB 수준 인증: 애플리케이션 수정 없이 외부 사용자 인증 필요 → Amazon Cognito 사용자 풀 + ALB 리스너 규칙입니다.

해설

【핵심 용어】 ▸ CAPABILITY_NAMED_IAM — 커스텀 IAM 리소스(명명된 역할) 생성 승인 ▸ CAPABILITY_IAM — 기본 IAM 리소스 생성 승인 ▸ CloudFormation StackSets — 다중 리전/계정 배포 【정답 포인트】 ▸ "커스텀 이름을 가진 IAM 역할" → CAPABILITY_NAMED_IAM 필수 ▸ "새로운 리전" → 신규 리전 활성화 필요 (리전이 비활성화되면 배포 불가) ▸ "스택 인스턴스 생성 실패" → 두 가지 원인: 리전 활성화 미흡 + IAM 기능 미지정 【오답 체크】 (B) Quota 증가 — 이미 충분한 할당량 보유 (C) SELF_MANAGED — StackSets 관리 모델, 리전 활성화 여전히 필요 (D) CAPABILITY_IAM — 커스텀 이름 역할 생성 불가, CAPABILITY_NAMED_IAM 필요 【시험 포인트】 새로운 리전에서 CloudFormation 스택 배포: 리전 활성화 + 적절한 IAM capability. 커스텀 명명 IAM 리소스 = CAPABILITY_NAMED_IAM입니다.

해설

【핵심 용어】 ▸ Amazon RDS Proxy — 연결 풀링, "타이머 기반" 단기 연결 효율화 ▸ Connection Pool — 물리 연결 재사용, 데이터베이스 연결 수 감소 ▸ Lambda + 단기 연결 → 연결 누적 문제 (RDS Proxy로 해결) 【정답 포인트】 ▸ "많은 단기 연결" → RDS Proxy의 연결 풀링 필수 ▸ "읽기 전용 작업" → RDS Proxy 읽기 전용 엔드포인트 사용 ▸ "신뢰성 향상" → 연결 고갈 방지 ▸ "예측 불가능한 피크" → RDS Proxy가 자동으로 처리 【오답 체크】 (B) max_connections 증가 — 임시 해결책, 비용 증가 (C) 인스턴스 스케일링 — 수평 확장도 RDS Proxy 없이는 연결 누적 (D) Aurora Data API — HTTP 기반 인터페이스 (성능 오버헤드) 【시험 포인트】 Lambda의 단기 연결 문제 = RDS Proxy입니다. RDS Proxy의 연결 풀링은 물리 연결 수를 감소시켜 max_connections 한계를 해결합니다.

해설

【핵심 용어】 ▸ AWS IoT Core Pre-provisioning Hook — 프로비저닝 전 검증 단계 ▸ allow-auto-registration — 등록된 CA 자격증명으로 자동 장치 등록 ▸ RegisterThing API — 수동 등록 (제조 단계, 설치 전) ▸ StartThingRegistrationTask — 대량 등록용 【정답 포인트】 ▸ "설치될 때까지 데이터 전송 불가" → 설치 시점의 검증 필요 ▸ "일련번호 검증" → Lambda 사전 프로비저닝 훅 ▸ "CA 인증서로 자동 등록" → allow-auto-registration 설정 ▸ "프라이빗 CA" → AWS IoT Core에 등록 필수 【오답 체크】 (A) RegisterThing (제조 단계) — 설치 전 등록, "설치 후만" 요구사항 미충족 (B) Step Functions — 사전 프로비저닝 훅용 아님 (D) 템플릿 검증만 — 설치 시점 검증 불가, 자동 등록 메커니즘 부족 【시험 포인트】 IoT 장치 조건부 프로비저닝: 사전 프로비저닝 훅(검증) + allow-auto-registration(자동 등록)입니다. RegisterThing은 제조 단계가 아닌 설치 시점에 사용됩니다.

해설

【핵심 용어】 ▸ GitHub 웹훅 — 이벤트 기반 트리거 (웹소켓은 지원 안 함) ▸ Jenkins 플러그인 for CodeBuild — Jenkins와 CodeBuild 통합 ▸ Blue/Green 배포 — 가동 중지 없음, 원활한 롤백 ▸ In-Place 배포 — 가동 중지 가능, 빠름 【정답 포인트】 ▸ "GitHub" → GitHub 웹훅 (올바른 트리거 메커니즘) ▸ "Jenkins" → Jenkins 플러그인 for CodeBuild ▸ "가동 중지 없음" → Blue/Green 배포 필수 ▸ "원활하고 롤백 가능" → Blue/Green의 특징 ▸ "잘못된 빌드 알림" → SNS (표준) 【오답 체크】 (A) (C) GitHub 웹소켓 — GitHub는 웹훅만 지원 (C) (D) AWS X-Ray — 테스트 도구 아님, 분산 추적 도구 (A) (D) In-Place 배포 — 가동 중지 가능 【시험 포인트】 CI/CD 파이프라인: GitHub 웹훅(트리거) + CodeBuild(빌드) + Blue/Green(무중단 배포) + SNS(알림)입니다.

해설

【핵심 용어】 ▸ Cost Allocation Tags — AWS Billing 콘솔에서 비용 추적 ▸ RCU/WCU — DynamoDB의 실제 리소스 사용량 ▸ AWS Cost Explorer API — 프로그래밍 방식 비용 조회 ▸ Operational Effort — 구현 및 유지보수 복잡도 【정답 포인트】 ▸ "세밀한 보기" → 실제 RCU/WCU 기반 계산 (태그는 테이블 단위) ▸ "각 테넌트의 소비" → 트랜잭션별 RCU/WCU 로깅 필수 ▸ "최소 운영 노력" → 자동화된 Lambda + EventBridge (정기 실행) ▸ "공유 테이블" → 테이블 수준 태그 불가능, 트랜잭션 수준 추적 필요 【오답 체크】 (A) 테이블 태그 — 공유 테이블이므로 테넌트별 분리 불가 (C) 파티션 키 변경 — 스키마 수정 필요, 운영 오버헤드 큼 (D) 가격 계산기 — 자동화 불가, 수동 계산 필요 【시험 포인트】 멀티테넌트 환경의 비용 할당: 공유 리소스 → 트랜잭션별 추적입니다. CloudWatch Logs에 RCU/WCU를 기록하고 Lambda로 주기적 계산합니다.

해설

【핵심 용어】 ▸ S3 Object Lock — 객체 삭제 방지 (WORM: Write Once Read Many) ▸ Versioning — 객체 수정 추적 및 복구 ▸ Cross-Account — 자격증명 침해 격리 ▸ Immutable Backup — 공격자 접근 방지 【정답 포인트】 ▸ "공개된 자격증명" → 계정 침해 가능성 ▸ "기존 및 향후 객체" → 즉시 적용 + 지속 보호 ▸ "1년 보관" → S3 Object Lock 기본 보존 1년 ▸ "별도 계정" → 권한 분리로 침해 격리 ▸ "모든 기존 데이터" → Batch Replication으로 이전 【오답 체크】 (B) AWS Config + Lambda — 사후 수정, 기존 데이터 삭제 불가 방지 아님 (C) Service Catalog — 향후 생성만 제어, 기존 버킷 보호 안 됨 (D) GuardDuty — 침해 탐지 도구, 보호 아님 【시험 포인트】 공격자로부터의 데이터 보호 (Ransomware/Deletion): S3 Object Lock + 별도 계정입니다. Object Lock은 MFA Delete와 달리 권한 있는 사용자도 삭제할 수 없는 강제 보존입니다.

해설

【핵심 용어】 ▸ ALB 인증 통합 — IdP 연동, OIDC 지원 ▸ Signed URLs — 임시 액세스용 (인증 아님) ▸ AWS WAF — 요청 필터링 (IdP 연동 불가) ▸ CloudTrail — 감사 로깅 (차단 기능 아님) 【정답 포인트】 ▸ "모든 백엔드 서비스" → API Gateway + ALB 모두 인증 필요 ▸ "인증된 사용자만" → IdP 통합 인증 강제 ▸ "OIDC IdP" → ALB가 OIDC 지원 ▸ "ALB 인증 비활성" → ALB 리스너 규칙에서 인증 강제 【오답 체크】 (B) Signed URLs — 임시 액세스용, 사용자 인증 아님 (토큰 검증 없음) (C) AWS WAF — IdP와 통합 안 됨, 단순 필터링만 가능 (D) CloudTrail — 이미 발생한 요청 기록 (사전 차단 불가) 【시험 포인트】 애플리케이션 수준 인증 강제: ALB 리스너 규칙 + IdP 통합입니다. ALB는 OIDC/Cognito와 네이티브 통합을 지원합니다.

해설

【핵심 용어】 ▸ AWS Security Hub — 모든 AWS 보안 서비스의 중앙화 대시보드 ▸ Amazon Detective — 보안 조사 도구 (가시성 제공) ▸ AWS Config — 리소스 컴플라이언스 추적 ▸ Delegated Administrator — 위임 관리자 계정 【정답 포인트】 ▸ "모든 계정의 보안 상태" → 통합 대시보드 필요 ▸ "예방적 + 탐지적 제어" → Security Hub가 모든 제어 통합 ▸ "중앙화된 보기" → Security Hub의 핵심 기능 ▸ "AWS Organizations" → Security Hub는 조직 수준 활성화 지원 ▸ "위임 관리자" → 한 계정에서 모든 계정 모니터링 【오답 체크】 (A) AWS Config 컴플라이언스 팩 — 리소스 컴플라이언스만 (보안 종합 보기 아님) (B) Amazon Detective — 보안 조사 도구 (실시간 중앙 대시보드 아님) (C) CloudFormation StackSets + Detective — Detective는 통합 대시보드 제공 안 함 【시험 포인트】 멀티 계정 보안 모니터링: AWS Security Hub입니다. Security Hub는 모든 AWS 보안 서비스(GuardDuty, Config, IAM, Trusted Advisor 등)의 결과를 통합하여 중앙화된 보기를 제공합니다.

해설

【핵심 용어】 ▸ AWS DataSync — 대규모 데이터 전송을 위한 자동화된 솔루션으로, TLS 암호화를 기본 지원하며 온프레미스에서 AWS로 지속적인 데이터 동기화 가능 【정답 포인트】 ▸ 60TB 규모 + 지속적인 새 이미지 생성 → DataSync 자동 작업 스케줄링으로 해결 ▸ 전송 중 암호화 필수 → DataSync는 TLS 암호화를 기본 지원 ▸ 커스텀 개발 불필요 → DataSync는 완전 관리형 서비스 【오답 체크】 (B) Kinesis Data Firehose는 스트리밍 데이터(로그, 센서 데이터)용으로, 대용량 파일 전송에 부적합 (C) Snowball은 일회성 데이터 마이그레이션용이며, 매일 생성되는 새 이미지의 지속적 전송에 부적합 (D) Site-to-Site VPN은 낮은 대역폭으로 60TB 전송이 비효율적이고, 자동화된 솔루션이 아님 【시험 포인트】 "automatically transfer all existing and new software images" → 지속적인 동기화 필요 → DataSync TLS 암호화 + 대규모 파일 + 자동화 → DataSync 조합이 최적