정답 · 해설

해설

【핵심 용어】 ▸ SQS 대기열 깊이 — 처리 대기 중인 메시지 수, 병목 지표 ▸ Auto Scaling(메트릭 기반) — 큐 깊이 증가시 워커 자동 증가 ▸ 처리 병목 — 입력(요청 수락)이 아닌 처리(초대 발송) 느림 【정답 포인트】 ▸ 병목 분석 → "회의 초대 지연" = 발송 애플리케이션 처리 느림 ▸ SQS 메시지 쌓임 → 발송 앱 인스턴스 부족 ▸ Auto Scaling(SQS 깊이 기반) → 큐 길이 증가시 워커 자동 확장 ▸ 처리 가속화로 고객 대기 시간 단축 【오답 체크】 (A) DAX 캐시 — DynamoDB 읽기 성능 개선, 초대 "발송" 지연과 무관 (B) API Gateway — 요청 수락 단계 개선, 초대 발송 처리 속도 미영향 (C) CloudFront — CDN 콘텐츠 캐싱용, 메일 발송 가속화 불가능 【시험 포인트】 ▸ SQS 메시지 누적 = 워커 부족 신호 → Auto Scaling으로 대응 ▸ 병목점 정확히 파악: 입력 vs 처리(지연)

해설

【핵심 용어】 ▸ AWS Lake Formation — 데이터 레이크 통합 카탈로그, 열/행 수준 세분화 권한 ▸ Lake Formation 액세스 제어 — 열(Column), 행(Row) 단위 권한 관리 ▸ 이기종 데이터 소스 — S3 + RDS를 통합 통제점에서 관리 【정답 포인트】 ▸ Lake Formation 데이터 레이크 → S3 + RDS 데이터 통합 카탈로그 ▸ Glue JDBC 커넥터 → RDS 데이터 메타데이터 자동 수집 ▸ 세분화 권한(열/행 수준) → 팀별 데이터 접근 세밀 제어 ▸ "운영 오버헤드 최소화" → Lake Formation 정책 엔진 자동 관리 【오답 체크】 (A) RDS 통합만 → S3 데이터 미포함, 이기종 통합 불가, 권한 관리 산재 (B) Lambda+Glue+Athena+S3 정책 → 권한 관리 분산(4개 서비스), 세분화 제어 약함 (D) Redshift → 데이터 웨어하우스, 레이크 아님, Redshift 권한만 가능(Lake Formation 미지원) 【시험 포인트】 ▸ "세분화 권한" → Lake Formation 열/행 수준 접근 제어가 핵심 ▸ 이기종 데이터(S3+RDS) → Lake Formation 통합 카탈로그 선택

해설

【핵심 용어】 ▸ S3 + CloudFront OAI — 프라이빗 S3 버킷, CloudFront만 접근 ▸ 정적 사이트 호스팅 — 서버리스 스토리지만으로 충분 ▸ AWS CLI 업로드 — 온프레미스→S3 직접 전송, SFTP 대체 【정답 포인트】 ▸ 프라이빗 S3 + OAI → 최소 비용, 최대 보안 ▸ CloudFront 원점 = S3 → 캐싱 이점, CDN 성능 ▸ "가장 비용 효율적" + "탄력적" → 서버리스(S3), 자동 확장(CloudFront) ▸ CLI 업로드 → IAM 권한으로 안전하게 관리 【오답 체크】 (A) Lightsail 서버 — 고정 비용(항상 실행), 정적 사이트 오버엔지니어링 (B) Auto Scaling+ALB — 매우 비효율, 정적 콘텐츠에 불필요한 복잡도 (D) 퍼블릭 S3+AWS Transfer — 공개 노출 보안 위험, Transfer 비용 추가 【시험 포인트】 ▸ 정적 사이트 → S3+CloudFront 표준 패턴(비용 최소) ▸ 콘텐츠 업로드 → CLI/SDK(보안), SFTP/퍼블릭 버킷은 비권장

해설

【핵심 용어】 ▸ EventBridge 규칙 — AWS API 이벤트 실시간 감지, 자동 라우팅 ▸ CreateImage API — EC2 AMI 생성 이벤트, EventBridge에서 네이티브 지원 ▸ "최소 운영 오버헤드" → 쿼리/Lambda 로직 불필요, 규칙 기반 【정답 포인트】 ▸ EventBridge 규칙 생성 → "source": "aws.ec2", "detail-type": "AWS API Call" ▸ CreateImage 이벤트 패턴 → "detail": {"eventName": "CreateImage"} ▸ SNS 대상 연결 → API 호출시 실시간 알림 전송 ▸ 이벤트 기반 아키텍처 → 폴링/쿼리 불필요 【오답 체크】 (A) Lambda+CloudTrail 폴링 — 지속적 쿼리 비용, 지연 발생 (B) CloudTrail→S3→Athena — 배치 처리, 실시간 아님, 매우 비효율 (D) SQS→Lambda→SNS — 불필요한 큐잉 단계, EventBridge 우월 【시험 포인트】 ▸ AWS API 모니터링 → CloudTrail(로그) vs EventBridge(실시간) ▸ 실시간 알림 → EventBridge 규칙이 표준 솔루션

해설

【핵심 용어】 ▸ 쓰기 버퍼링 — 즉시 DB 쓰기 대신 큐에 저장, 부하 평준화 ▸ SQS + Lambda — 비동기 쓰기, 메시지 지속성, 재시도 자동화 ▸ "기존 사용자 영향 없음" → API 응답 시간 악화 방지 【정답 포인트】 ▸ 문제 분석 → DynamoDB 처리량 한계, 쓰기 요청 손실 ▸ 해결책 → API→SQS→Lambda→DynamoDB (비동기 분리) ▸ SQS 메시지 저장 → Lambda 재시도 → "요청 손실" 방지 ▸ API 응답 즉시(큐 삽입만) → 사용자 경험 미영향 【오답 체크】 (A) API Gateway 스로틀 → 요청 거절, "사용자 영향 없음" 위배 (B) DAX 캐시 — 읽기 성능, 쓰기 부하 미해결 (C) 보조 인덱스 — 읽기 쿼리용, 쓰기 처리량 개선 없음 【시험 포인트】 ▸ 쓰기 부하 분산 → SQS 버퍼링+Lambda 워커 패턴 ▸ "요청 손실" 방지 → 메시지 지속성(SQS) 필수

해설

【핵심 용어】 ▸ VPC 엔드포인트 — VPC 내부 AWS 서비스 접근, 공인 IP 불필요 ▸ 인터페이스 VPC 엔드포인트 — ENI 기반, 모든 AWS 서비스 지원 ▸ 게이트웨이 VPC 엔드포인트 — 라우팅 기반, S3/DynamoDB 전용 【정답 포인트】 ▸ 인터페이스 엔드포인트 → S3 API 호출을 VPC 내부 라우팅 ▸ "공용 인터넷 경로 미사용" → 인터페이스 엔드포인트 필수 ▸ IAM 역할 기반 권한 → EC2 인스턴스만 S3 접근 ▸ "S3 전용 접근" 조건 충족 【오답 체크】 (B) 게이트웨이 엔드포인트 — 경로 기반, 보안 그룹 미지원, 인터페이스가 더 안전 (C) (D) nslookup/ip-ranges.json — 프라이빗 IP 수동 추출 불필요, 엔드포인트가 자동 처리 【시험 포인트】 ▸ VPC 내부 AWS 접근 → VPC 엔드포인트(공인 IP 제외) ▸ "인터넷 경로 제외" → 인터페이스 엔드포인트 선택

해설

【핵심 용어】 ▸ ElastiCache — 분산 세션 저장소(Redis/Memcached) ▸ 분산 세션 — 세션 상태를 서버 로컬이 아닌 공유 저장소 저장 ▸ Auto Scaling 환경 → 인스턴스 수 변동, 특정 인스턴스 고정 불가 【정답 포인트】 ▸ 빈번한 확장/축소 → 인스턴스 수 변동, 세션 손실(스티키 불가) ▸ ElastiCache 중앙 저장소 → 모든 EC2 인스턴스가 동일 세션 접근 ▸ "코드 변경 가능" → Redis 클라이언트 라이브러리로 세션 저장소 로직 추가 【오답 체크】 (B) 스티키 세션(ALB) — 특정 인스턴스 고정, 축소시 세션 손실, Auto Scaling 부적합 (C) Systems Manager Session Manager — EC2 관리 접근용, 애플리케이션 세션 아님 (D) AWS STS GetSessionToken — 권한 임시 토큰, HTTP 세션 관리 아님 【시험 포인트】 ▸ Auto Scaling+분산 세션 → 중앙 저장소(ElastiCache) 필수 ▸ 스티키 세션은 확장성 제약, 권장 안함

해설

【핵심 용어】 ▸ 메시지 큐 버퍼링 — 빠른 수집과 느린 이행 프로세스 분리 ▸ Auto Scaling 독립 운영 — 각 프로세스 부하에 따라 별도 확장 ▸ "데이터 손실 방지" → 메시지 지속성(SQS) 필수 【정답 포인트】 ▸ 수집 → SQS → 이행 구조 → 두 프로세스 속도 차이 흡수 ▸ 각 Auto Scaling 그룹 독립적 운영 → 부하별 최적 확장 ▸ SQS 메시지 지속 → 스케일링 중 데이터 손실 없음 ▸ 리소스 활용 최적화 → 불필요한 오버프로비저닝 제거 【오답 체크】 (A) 메시지 큐 없이 직접 연결 — 부하 불일치, 스케일링 시 손실 위험 (B) 수집 증가만 — 이행 병목 해결 못함, 일부만 개선 (D) 이행만 증가 — 수집 쓸모 없음, 구조적 개선 아님 【시험 포인트】 ▸ 비동기 처리 분리 → SQS 큐 버퍼링 ▸ "데이터 손실" 방지 → 메시지 지속성, Auto Scaling 조정

해설

【핵심 용어】 ▸ AWS WAF — 애플리케이션 계층(L7) 공격 차단 ▸ AWS Shield Standard — DDoS 기본 보호(자동 포함) ▸ AWS Shield Advanced — DDoS 고급 보호(선택적) ▸ NACLs — 네트워크 계층(L3/L4) 필터 【정답 포인트】 ▸ SQL 주입/XSS → 애플리케이션 계층 공격 ▸ WAF Web ACL → SQL 주입, XSS 패턴 탐지 및 차단 ▸ CloudFront 통합 → 엣지에서 조기 차단 ▸ Shield Standard 자동 포함 → 기본 DDoS 보호 【오답 체크】 (A) NACLs — 네트워크 계층(IP/포트) 필터, SQL 주입 탐지 불가 (B) Shield Advanced — DDoS 보호, SQL 주입 미포함 (C) VPC 보안 그룹 — 연결 제어, 패턴 검사 불가 【시험 포인트】 ▸ "SQL 주입/XSS" → WAF 관리형 규칙 ▸ CloudFront+WAF → CDN+애플리케이션 보안 계층

해설

【핵심 용어】 ▸ AWS RDS 자동 백업 — 일일 전체 스냅샷 + 트랜잭션 로그 ▸ RDS Backup Window — 백업 수행 시간대 ▸ "거의 손실 없는 복구" → Point-in-Time Recovery(최대 35일) ▸ Multi-AZ → 동기 레플리카, 자동 페일오버 【정답 포인트】 ▸ 자동 백업 활성화 → 일일 스냅샷 + 트랜잭션 로그 ▸ Backup Retention 설정(최대 35일) → PITR 가능 ▸ "거의 손실 없는 복구" → 초 단위 복구 ▸ 운영 오버헤드 최소 → 자동화된 관리형 백업 【오답 체크】 (A) 수동 스냅샷 → 주기적 작업 필요, 자동화 불가, 유실 가능 (B) 읽기 레플리카 → 재해 복구 아님, 백업이 아닌 스케일링 (C) RDS 내보내기 → Parquet 형식 S3 저장, 복구용 아님 【시험 포인트】 ▸ "거의 손실 없는 복구" → RDS 자동 백업+PITR ▸ 트랜잭션 로그 → 초 단위 복구 가능

해설

【핵심 용어】 ▸ CloudFront Invalidation — 캐시된 콘텐츠 즉시 제거 ▸ TTL 설정 — 캐시 만료 시간 제어 ▸ 객체 버전 관리 — 파일명 변경(new-image-v2.jpg) ▸ "대기 시간 최소" → 즉시성 【정답 포인트】 ▸ CloudFront Invalidation → 즉시 캐시 제거(비용 청구) ▸ 저가 옵션: TTL 단축 또는 객체 버전 관리 ▸ "즉시 반영" 요구 → Invalidation이 유일 ▸ "최소 대기 시간" → Invalidation(초 단위) 【오답 체크】 (A) TTL 단축만 → 다음 만료시까지 대기(즉시 아님) (B) 객체 버전 관리 → 수동 URL 변경 필요, 자동화 어려움 (C) 캐시 정책 변경 → 이미 캐시된 콘텐츠 미영향 【시험 포인트】 ▸ 즉시 갱신 → CloudFront Invalidation ▸ TTL vs Invalidation → 경비용 vs 즉시성

해설

【핵심 용어】 ▸ Amazon EventBridge — 이벤트 기반 아키텍처 ▸ 예약 규칙(cron) — 정기적 작업 실행 ▸ Lambda 대상 — 서버리스 함수 자동 실행 ▸ SNS 알림 — 완료 알림 전송 【정답 포인트】 ▸ EventBridge 규칙 생성 → "rate(1 day)" 또는 "cron(0 2 * * ?)" ▸ Lambda 함수 대상 → 리포트 생성 자동 실행 ▸ SNS 알림 → 완료시 이메일 전송 ▸ 관리형 서비스 → 운영 오버헤드 최소 【오답 체크】 (A) CloudWatch Logs → 로그 필터, 자동 작업 실행 안됨 (B) Systems Manager Automation → 복잡한 구성, EventBridge가 간단 (C) Step Functions → 워크플로우용, 단순 예약 작업에 과도 【시험 포인트】 ▸ 정기적 자동 작업 → EventBridge + Lambda 조합 ▸ Cron 스케줄 → "최소 운영 오버헤드"

해설

【핵심 용어】 ▸ Amazon Redshift Spectrum — S3 데이터 직접 쿼리 ▸ 외부 테이블 — S3 데이터 메타데이터 ▸ 비용 최적화 — 데이터 모움 최소화 ▸ 스케일링 → 데이터 증가시 자동 처리 【정답 포인트】 ▸ S3에 원본 데이터 저장 → 비용 저렴(Glacier/Cold storage) ▸ Redshift Spectrum → S3 데이터 직접 쿼리, Redshift 로드 불필요 ▸ 외부 테이블 → 메타데이터만 Redshift 관리 ▸ "비용 효율적" + "확장성" → S3 저장, Spectrum 쿼리 【오답 체크】 (A) Redshift 로드 → 모든 데이터 클러스터 저장, 비용 높음 (B) Redshift Federated Query → 외부 RDS 쿼리용, S3 대량 데이터 비효율 (C) S3 Select → 단순 필터링, 분석 쿼리 부적합 【시험 포인트】 ▸ 대용량 데이터 분석 → Redshift Spectrum(S3 데이터 직접) ▸ 비용 최적화 → 데이터 중복 저장 제거

해설

【핵심 용어】 ▸ AWS Secrets Manager — 민감 정보 중앙 관리 ▸ 자동 순환 — 주기적 시크릿 갱신 ▸ 감사 로그 — CloudTrail 추적 ▸ IAM 권한 → 세분화 액세스 제어 【정답 포인트】 ▸ 데이터베이스 자격증명 저장 → Secrets Manager 중앙화 ▸ 자동 순환 활성화 → Lambda 함수로 주기적 갱신 ▸ "운영 오버헤드 최소" → 자동화된 관리 ▸ IAM 권한 → 애플리케이션만 시크릿 액세스 【오답 체크】 (A) 애플리케이션 코드 저장 → 보안 위험, 감사 불가 (B) Systems Manager Parameter Store → 민감정보용 아님, 암호화 기본 없음 (C) S3 암호화 저장 → 자동 순환 불가, 접근 제어 약함 【시험 포인트】 ▸ 민감 정보 관리 → Secrets Manager ▸ 자동 순환 → Lambda 함수 지원

해설

【핵심 용어】 ▸ Amazon DynamoDB 글로벌 테이블 — 다중 리전 복제 ▸ 다중 마스터 → 모든 리전에서 읽기/쓰기 ▸ 자동 동기화 → 밀리초 수준 복제 ▸ "높은 가용성" + "성능" → 로컬 리전 액세스 【정답 포인트】 ▸ 글로벌 테이블 활성화 → 다중 리전 자동 복제 ▸ 각 리전 로컬 처리 → 지연 최소 ▸ 자동 페일오버 → 한 리전 장애시 다른 리전 사용 ▸ "낮은 지연" → 글로벌 사용자 로컬 액세스 【오답 체크】 (A) 읽기 레플리카 → 단일 방향, 쓰기는 주 테이블만 (B) S3 크로스 리전 복제 → 데이터 웨어하우스용, 실시간 쿼리 부적합 (C) CloudFront 캐싱 → 정적 콘텐츠, DynamoDB 쿼리 결과 캐싱 불가 【시험 포인트】 ▸ 다중 리전 실시간 쓰기 → DynamoDB 글로벌 테이블 ▸ "낮은 지연" → 로컬 리전 액세스

해설

【핵심 용어】 ▸ AWS Application Load Balancer(ALB) 호스트 기반 라우팅 — 도메인별 타겟 그룹 ▸ 경로 기반 라우팅 — URL 경로별 라우팅 ▸ "최소 운영 오버헤드" → 단일 로드 밸런서 ▸ Multi-AZ → 고가용성 【정답 포인트】 ▸ 단일 ALB 생성 → 여러 도메인 지원 ▸ 호스트 기반 규칙 → api.example.com, web.example.com 분리 ▸ 각 도메인별 타겟 그룹 → 마이크로서비스별 라우팅 ▸ Multi-AZ 배포 → 고가용성 【오답 체크】 (A) 도메인별 ALB → 비용 높음, 오버헤드 증가 (B) NLB → 성능 우선, 애플리케이션 계층 라우팅 약함 (C) API Gateway → API만, 웹 서비스 라우팅 부적합 【시험 포인트】 ▸ 다중 도메인 라우팅 → ALB 호스트 기반 규칙 ▸ "최소 오버헤드" → 단일 로드 밸런서

해설

【핵심 용어】 ▸ AWS CloudFormation StackSets — 다중 계정/리전 배포 ▸ Service-managed 스택셋 → AWS 관리형 배포 ▸ Self-managed 스택셋 → 사용자 직접 배포 ▸ "운영 오버헤드 최소" → 자동화 【정답 포인트】 ▸ StackSets 생성 → 단일 정의로 다중 계정/리전 배포 ▸ Service-managed 옵션 → AWS 자동 배포 및 업데이트 ▸ 자동 롤백 → 배포 실패시 자동 복구 ▸ 일관성 있는 구성 관리 【오답 체크】 (A) CloudFormation 스택 수동 배포 → 각 계정/리전 반복, 오버헤드 높음 (B) AWS Organizations 정책 → 리소스 배포 아님, 정책 관리용 (C) Terraform → 외부 도구, CloudFormation 생태계 벗어남 【시험 포인트】 ▸ 다중 계정/리전 배포 → CloudFormation StackSets ▸ Service-managed → 최소 운영 오버헤드

해설

【핵심 용어】 ▸ AWS VPC VPN — 온프레미스와 VPC 간 암호화 연결 ▸ AWS Direct Connect — 전용 네트워크 연결 ▸ "일관된 성능" → Direct Connect 추천 ▸ "낮은 지연" → 프라이빗 연결 【정답 포인트】 ▸ Direct Connect 물리적 전용선 → 일관된 대역폭 보장 ▸ VPN보다 낮은 지연 → 전용 경로 ▸ "대규모 데이터 전송" → Direct Connect 필수 ▸ 암호화 필요시 → Direct Connect + VPN 조합 【오답 체크】 (A) VPN만 → 공용 인터넷 기반, 성능 변동 가능 (B) CloudFront → CDN 캐싱, 전용 프라이빗 연결 아님 (C) S3 Transfer Acceleration → 공용 인터넷 최적화, 프라이빗 아님 【시험 포인트】 ▸ "일관된 성능" → AWS Direct Connect ▸ 대규모 데이터 → 전용선 필수

해설

【핵심 용어】 ▸ AWS Organizations 서비스 제어 정책(SCP) — 권한 상한선 ▸ IAM 권한 → 실제 권한 부여 ▸ "최악의 경우" → SCP가 모든 권한 제어 ▸ 계층적 거버넌스 → OU별 정책 【정답 포인트】 ▸ SCP는 권한 상한선 → IAM 권한보다 제한적 ▸ EC2, RDS 서비스만 허용 → SCP "ec2:* RDS:*" 허용 ▸ 계정의 모든 사용자/역할 적용 → 일괄 통제 ▸ 계층적 조직 구조 → OU별 차등 정책 【오답 체크】 (A) IAM 권한만 → 조직 전체 통제 불가 (B) CloudTrail → 감시만, 권한 제어 아님 (C) 보안 그룹 → 네트워크 접근, 서비스 제어 아님 【시험 포인트】 ▸ "최악의 경우" 권한 제어 → SCP ▸ 조직 전체 통제 → Organizations SCP

해설

【핵심 용어】 ▸ Amazon EC2 인스턴스 메타데이터 → v1(평문), v2(토큰 기반) ▸ IMDSv2 — 네트워크 호핑 공격 방어 ▸ "보안 권장사항" → IMDSv2 필수 ▸ IAM 역할 자격증명 → 인스턴스 권한 【정답 포인트】 ▸ IMDSv2 활성화(필수) → 토큰 기반 인증 ▸ Token TTL 조정 → 세션 시간 제어 ▸ "HTTP 호핑" 공격 방어 → 네트워크 레벨 보호 ▸ IAM 역할 사용 → 인스턴스 권한 안전 관리 【오답 체크】 (A) IMDSv1 → SSRF 공격 취약 (B) 메타데이터 비활성화 → 애플리케이션 동작 불가 (C) 인스턴스 프로필 없음 → 권한 관리 불가 【시험 포인트】 ▸ EC2 메타데이터 보안 → IMDSv2 필수 ▸ "HTTP 호핑" 방어 → 네트워크 격리