정답 · 해설

해설

【핵심 용어】 ▸ AWS WAF(Web Application Firewall) — HTTP/HTTPS 기반 IP 화이트리스트 ▸ IP Set — WAF에서 관리하는 동적 IP 목록 ▸ ALB 앞단 보안 — 애플리케이션 레벨 필터링 【정답 포인트】 ▸ 동적 IP 관리 → IP Set으로 등록된 IP만 허용, 추가/제거 쉬움 ▸ HTTP/HTTPS 레벨 → ALB와 직접 연결, 요청 전 차단 ▸ 확장성 → 20,000개 IP도 IP Set으로 관리 가능 ▸ 중앙 관리 → AWS WAF 콘솔에서 일괄 업데이트 【오답 체크】 (B) Firewall Manager는 조직 전체 방화벽 정책 관리, 단일 ALB IP 필터링에 오버스펙 (C) DynamoDB + Lambda는 복잡한 커스텀 로직, WAF IP Set처럼 간단하지 않고 비용도 높음 (D) Network ACL은 서브넷 레벨, ALB 단계에서 필터링 불가(애플리케이션 도달 후 차단), 비효율 【시험 포인트】 ▸ HTTP/HTTPS + IP 화이트리스트 → AWS WAF + IP Set ▸ 함정 → Network ACL(저수준), Lambda(복잡), Firewall Manager(과도)로 착각, WAF의 간편성

해설

【핵심 용어】 ▸ AWS Lake Formation — 데이터 레이크 구축 및 보안 관리 서비스 ▸ 행/셀 수준 필터(Row/Cell-level Filters) — 세분화된 데이터 접근 제어 메커니즘 【정답 포인트】 ▸ 민감한 정보 숨김 → 필터링으로 동적 마스킹 ▸ Lake Formation의 핵심 기능: IAM 역할이 아닌 데이터 필터를 통한 실시간 접근 제어. 행/셀 필터를 적용하면 동일 테이블에 접근할 때 사용자 역할에 따라 자동으로 민감 칼럼이나 행을 제외시킴. 【오답 체크】 (A) IAM 역할만으로는 세분화된 행/셀 제어 불가 — 테이블 수준 권한만 가능 (C) Lambda로 데이터 사전 제거는 원본 훼손 및 운영 비용 증가 (D) 주기적 쿼리 및 제거는 실시간 보안 미충족, 실행 지연 발생 【시험 포인트】 ▸ Lake Formation 보안 → 필터(동적) vs IAM(정적) 구분 ▸ 함정: Lambda 자동화는 대량 데이터 처리로 보이지만, Lake Formation 내장 필터가 운영 효율적 (고가용성, 재계산 불필요)

해설

【핵심 용어】 ▸ 게이트웨이 VPC 엔드포인트(S3용) — S3 접근 시 인터넷 우회, 프라이빗 경로 ▸ AWS Direct Connect — 온프레미스와 AWS 간 고속 전용 네트워크 링크 【정답 포인트】 ▸ EC2→S3 데이터 전송: 게이트웨이 엔드포인트로 인터넷 우회, 테이블 기반 라우팅 ▸ 온프레미스 응용: Direct Connect로 공용망 회피. 두 경로 모두 공용 인터넷 없음 — 규정 준수 충족 【오답 체크】 (A) EC2용 인터페이스 엔드포인트는 S3에 필수 아님, VPN은 대역폭 제한 (C) Transit Gateway는 S3 직접 지원 구조 아님, VPN은 공용망 기반 (D) NAT 게이트웨이는 공용 IP 거쳐서 전송 — 규정 준수 위반 【시험 포인트】 ▸ S3 접근 경로 → 게이트웨이 엔드포인트(VPC 경로 기반, 저비용) ▸ 온프레미스 연결 → Direct Connect(전용선, 안정적) vs VPN(인터넷 기반, 부적절)

해설

【핵심 용어】 ▸ Amazon Kinesis Data Streams — 높은 처리량 실시간 데이터 수집 및 버퍼링 ▸ 탈커플링(Decoupling) — 공급자와 처리 시스템 분리로 부하 흡수 【정답 포인트】 ▸ 503 오류 원인: EC2 직접 요청 처리로 용량 부족 ▸ Kinesis는 무제한 수집 → Lambda 비동기 처리로 탈커플링. 공급자는 빠르게 응답받음, Lambda는 유연하게 스케일. 【오답 체크】 (B) API Gateway 할당량은 처리 능력 미향상, 여전히 EC2 직접 처리 (C) SNS는 팬아웃 용 — 단순 푸시 서비스, 버퍼링 미지원 (D) ECS Auto Scaling은 시간 소요, 급증 대응 느림 — Kinesis 버퍼링보다 후발적 【시험 포인트】 ▸ 실시간 대량 수집 → Kinesis(버퍼) + Lambda(서버리스 처리) ▸ 함정: Auto Scaling은 인스턴스 시작 지연 있음, 즉각 수용 불가

해설

【핵심 용어】 ▸ VPC 엔드포인트(S3용 게이트웨이) — AWS 내부 네트워크로만 접근, 인터넷 우회 ▸ 프라이빗 서브넷 — 인터넷 게이트웨이 없는 격리된 네트워크 【정답 포인트】 ▸ 프라이빗 EC2 → S3 접근: 인터넷 사용 금지 조건 ▸ VPC 엔드포인트는 라우팅 테이블 기반으로 S3를 직결 — 애플리케이션 코드 변경 최소, 인터넷 회피 【오답 체크】 (A) 인터넷 게이트웨이는 공용 접근 — 요구사항 위반 (B) VPN은 제3자 또는 온프레미스용, S3 접근 시 오버헤드 (C) NAT 게이트웨이는 공용 IP로 라우팅 — 인터넷 사용 — 조건 위반 【시험 포인트】 ▸ 프라이빗 리소스의 AWS 서비스 접근 → VPC 엔드포인트 (경로 기반, 네이티브) ▸ 함정: NAT는 아웃바운드 유연성 주지만 인터넷 거침

해설

【핵심 용어】 ▸ Kubernetes Secrets 자동 암호화 — etcd에서 저장 시점 데이터 암호화 ▸ AWS KMS 통합 — EKS 클러스터 수준 암호화 정책 적용 【정답 포인트】 ▸ 최소 운영 오버헤드 → EKS 클러스터 설정만으로 자동 암호화 ▸ KMS 암호화 활성화: etcd 데이터베이스 내 모든 Secret이 투명하게 인크립션됨. 응용 단에서 코드 변경 불필요. 【오답 체크】 (A) 애플리케이션 레벨 암호화는 각 Pod에서 구현 필요 — 운영 복잡도 상승 (C) Lambda 함수로 별도 암호화는 비동기 처리, 복잡한 워크플로우 (D) Parameter Store는 외부 저장소 — Kubernetes 네이티브 구조 아님 【시험 포인트】 ▸ EKS 보안 → 클러스터 수준 암호화(KMS) vs 애플리케이션 수준 ▸ 함정: 애플리케이션 암호화는 유연하지만 운영 비용 증가

해설

【핵심 용어】 ▸ Application Load Balancer(ALB) — 계층 7(애플리케이션) 로드 밸런싱, 라우팅 ▸ 보안 그룹 — 상태 기반 방화벽, 소스/목적지 포트 제어 가능 【정답 포인트】 ▸ 계층 간 통신 제어: ALB로 웹→앱 트래픽 중개 ▸ 보안 그룹을 이용한 수평적 접근 제어 — ALB 보안 그룹은 웹 서버 SG만 허용, 앱 서버 SG는 ALB에서의 요청만 수용 【오답 체크】 (A) PrivateLink는 AWS 서비스용, 내부 서버 간 통신에 부적절 (B) VPC 엔드포인트는 AWS 서비스 노출용, 프라이빗 서버 간 통신 불가 (C) Network Load Balancer + 네트워크 ACL은 상태 기반 제어 약함, 고정 IP 기반 복잡도 【시험 포인트】 ▸ 계층 간 접근 제어 → ALB(애플리케이션 로드 밸런싱) + 보안 그룹(정밀 제어) ▸ 함정: 네트워크 ACL은 상태비저장, 동적 Auto Scaling 환경에 부족

해설

【핵심 용어】 ▸ CloudWatch Container Insights — Kubernetes 네이티브 모니터링, Pod/Node 메트릭 ▸ 중앙 집계(Centralized Aggregation) — 마이크로서비스 전체 가시성 【정답 포인트】 ▸ Container Insights는 EKS 클러스터에 에이전트 배포로 자동 메트릭 수집 ▸ CloudWatch 통합: Pod, Node, 워크로드별 지표와 로그 한곳에서 확인 가능. Kubernetes 환경에 최적화. 【오답 체크】 (A) CloudWatch 에이전트는 EC2 용 — Kubernetes Pod 메트릭 미수집 (B) App Mesh는 서비스 메시 관리용, 중앙 모니터링 전문이 아님 (C) CloudTrail은 API 이벤트용, 애플리케이션 메트릭/로그 미제공 【시험 포인트】 ▸ EKS 모니터링 → Container Insights(Kubernetes 네이티브) ▸ 함정: 일반 CloudWatch 에이전트로는 Pod 수준 메트릭 불완전

해설

【핵심 용어】 ▸ Amazon GuardDuty — AWS 계정 및 리소스 위협 탐지 (머신러닝 기반) ▸ AWS Security Hub — 보안 결과 중앙 집계 및 대시보드 표시 【정답 포인트】 ▸ 악의적 활동 탐지: GuardDuty는 API 로그, VPC Flow Logs 분석으로 비정상 행동 감지 ▸ 중앙 대시보드: Security Hub는 GuardDuty 결과 집계하여 통합 보안 보기 제공 【오답 체크】 (A) Macie는 S3 데이터 민감도 분류용, 악의적 활동 탐지 아님 (B) Inspector는 EC2/컨테이너 취약점 스캔, 악의적 활동 탐지 불가 (D) AWS Config는 규정 준수 추적용, 위협 탐지 기능 없음 【시험 포인트】 ▸ 위협 탐지 → GuardDuty (탐지 엔진) + Security Hub (대시보드) ▸ 함정: Macie(데이터 분류), Inspector(취약점), Config(컴플라이언스)는 다른 목적

해설

【핵심 용어】 ▸ Amazon EFS — NFS 호환 파일 시스템, 다중 AZ 자동 확장 ▸ AWS DataSync — 온프레미스 ↔ AWS 데이터 마이그레이션 자동화, 검증 기능 【정답 포인트】 ▸ NFS 프로토콜 지원: EFS는 표준 NFS v4.1 준수, AWS 리소스 간 공유 가능 ▸ 비용 효율: DataSync는 증분 동기화 및 자동 무결성 검증으로 운영 부담 최소화, 다운타임 없음 【오답 체크】 (A) FSx Lustre는 고성능 컴퓨팅용, 작은 데이터셋(200GB)에 비용 낭비 (C) S3는 NFS 미지원 프로토콜, 별도 마이그레이션 필요 (D) 수동 복사는 검증 부재, 대역폭 제어 어려움 【시험 포인트】 ▸ NFS 마이그레이션 → EFS(목표) + DataSync(수단) ▸ 함정: FSx Lustre는 비용 대비 과사양, S3는 객체 스토어(파일 아님)

해설

【핵심 용어】 ▸ 다중 AZ 배포(Multi-AZ) — FSx 고가용성, RPO 5분 충족 ▸ Backup Vault Lock 규정 준수 모드 — 관리자도 삭제 불가, 완전 잠금 【정답 포인트】 ▸ 5분 RPO: Multi-AZ는 자동 장애 조치 포함, 가동 중단 최소화 ▸ 5년 불변성: Vault Lock 규정 준수 모드는 법적 구속력, 관리자 권한으로도 우회 불가. 거버넌스는 관리자 승인으로 해제 가능 — 위험 【오답 체크】 (A) 단일 AZ는 가용성 부족, 계획 유지보수 시에도 다운타임 우려 (B) 다중 AZ 맞지만 거버넌스 모드는 관리자 삭제 가능 — 규제 부적합 (D) 단일 AZ + 거버넌스는 이중 문제 【시험 포인트】 ▸ 높은 가용성 + 불변 백업 → Multi-AZ + 규정 준수 모드 ▸ 함정: 거버넌스 vs 규정 준수 모드 구분 (법적 요구사항에서 중요)

해설

【핵심 용어】 ▸ Service Control Policy(SCP) — Organizations 수준 권한 관리, 루트 사용자도 제약 ▸ 명시적 거부(Explicit Deny) — IAM 정책 오버라이드, 최고 권한 【정답 포인트】 ▸ 루트 사용자 제어: IAM 정책은 루트에 적용 불가, SCP만 루트를 제약 ▸ Organizations-wide 정책: 개발자 계정에 SCP 적용하면 명시적 거부로 CloudTrail API 변경 차단 【오답 체크】 (A) IAM 정책은 루트 사용자 바이패스 가능 — 무효 (B) 조직 추적은 마스터 계정 추적, 개발자 계정의 로컬 추적은 여전히 변경 가능 (D) 서비스 연결 역할은 특정 서비스용 역할, 정책 조건으로 CloudTrail API 차단 불충분 【시험 포인트】 ▸ Organizations 환경에서 루트 제약 → SCP (명시적 거부) ▸ 함정: IAM 정책은 루트에 대해 작동하지 않음

해설

【핵심 용어】 ▸ S3 교차 리전 복제(Cross-Region Replication, CRR) — 자동 동기화, 새 객체만 ▸ 최소 운영 노력 — 관리 자동화, 코드 불필요 【정답 포인트】 ▸ 새 사진만 복제: 설정 후 자동으로 신규 객체 us-east-1 버킷에 복사 ▸ 운영 부담 최소: S3 설정만으로 완료, Lambda/이벤트 코드 불필요 【오답 체크】 (B) CORS는 브라우저 교차 요청용, 데이터 복제 메커니즘 아님 (C) 수명 주기 규칙은 객체 삭제/아카이빙용, 리전 간 복제 불가 (D) Lambda + 이벤트는 자동화 가능하나 운영 복잡도 증가, 코드 관리 필요 【시험 포인트】 ▸ S3 리전 간 복제 → Cross-Region Replication (자동, 설정만) ▸ 함정: Lambda 방식은 유연하지만 운영 부담 크다

해설

【핵심 용어】 ▸ AWS WAF(Web Application Firewall) — SQL 주입, XSS 등 애플리케이션 계층 공격 차단 ▸ AWS Shield — DDoS 공격만 방어, 애플리케이션 수준 침입 미포함 【정답 포인트】 ▸ SQL 주입/XSS: WAF의 관리형 규칙 세트로 자동 탐지/차단 ▸ 운영 효율: API Gateway에 직접 WAF 연결, CloudFront 추가 배포 불필요 【오답 체크】 (A) Shield는 DDoS 전용, 애플리케이션 공격 미지원 (C) CloudFront+Shield는 여전히 SQL/XSS 미보호, 불필요한 CDN 레이어 추가 (D) CloudFront는 정적 콘텐츠 최적화용, API Gateway에 WAF 직결이 명확하고 효율적 【시험 포인트】 ▸ 애플리케이션 공격 방어 → WAF (SQL/XSS/CSRF 규칙) ▸ DDoS vs 애플리케이션 공격 구분: Shield vs WAF ▸ 함정: CloudFront는 API에 불필요한 복잡도

해설

【핵심 용어】 ▸ SAML 2.0 페더레이션 — Active Directory와 AWS 통합, 단일 ID ▸ 그룹 매핑 — AD 그룹 멤버십으로 AWS 역할 자동 할당 【정답 포인트】 ▸ 단일 ID: SAML 페더레이션으로 AD 사용자가 AWS 콘솔 로그인 가능, 추가 ID 불필요 ▸ 그룹 기반 권한: AD 그룹을 AWS 역할에 매핑하면, 회사 정책 변경 시 자동 동기화 【오답 체크】 (A) IAM 사용자 수동 생성은 1500명 관리 비효율, 중복 ID (B) Cognito는 외부 애플리케이션용, 엔터프라이즈 AD 통합에 부족 (C) 교차 계정 역할은 다중 AWS 계정용, 단일 테넌트 아키텍처에는 과사양 【시험 포인트】 ▸ 엔터프라이즈 AD 통합 → SAML 페더레이션 (표준, 확장성) ▸ 그룹 기반 권한 관리 → AD 그룹 ↔ AWS 역할 매핑 ▸ 함정: Cognito는 모바일/B2C용, IAM 수동 생성은 비용 폭증

해설

【핵심 용어】 ▸ Geolocation Routing(지리적 위치) — 사용자 위치 기반 정확한 제어 ▸ Geoproximity Routing(지리 근접) — 위도/경도 기반 근접성 우선, 편향 값 조정 【정답 포인트】 ▸ 배포 권한 준수: 각 국가/지역별 콘텐츠 제한이 있을 때, Route 53 지리적 위치 정책으로 정확히 제어 ▸ 사용자 위치 감지: 요청 출처 IP 기반 지역 파악 → 해당 ALB로 라우팅 【오답 체크】 (A) CloudFront+WAF는 콘텐츠 필터링용, 지리적 라우팅 미지원 (B) ALB의 WAF는 공격 방어, 지역별 콘텐츠 제약 불가 (D) 지리 근접 라우팅은 거리 기반 최적화, 배포 권한 강제 불가 (편향값으로 조정 가능하나 의도적 제약 목적이 아님) 【시험 포인트】 ▸ 법적/배포 제약 → Geolocation Routing (명시적 제어) ▸ 성능 최적화 → Geoproximity Routing (거리 기반) ▸ 함정: Geoproximity는 지리적 거리 계산이지, 정책 준수 메커니즘 아님

해설

【핵심 용어】 ▸ AWS DataSync — 온프레미스 ↔ AWS 대용량 데이터 전송, 자동 무결성 검증 ▸ 검증 메커니즘 — ETag/메타데이터 비교, 전송 후 자동 재전송 【정답 포인트】 ▸ 자동 무결성 검증: DataSync는 전송 후 체크섬 자동 검증, 불일치 시 재전송 ▸ 온라인 전송: 네트워크 연결로 지속적 동기화 가능, 대역폭 제어 기능 【오답 체크】 (A) Snowball Edge는 오프라인 전송 (물리 배송), 검증 기능 제한 (C) S3 파일 게이트웨이는 캐싱용, 대용량 마이그레이션 비효율 (D) Transfer Acceleration은 업로드 속도 증가, 무결성 검증 메커니즘 아님 【시험 포인트】 ▸ 대용량 온라인 전송 + 자동 검증 → DataSync ▸ 오프라인 전송 → Snowball, 온라인 → DataSync ▸ 함정: 파일 게이트웨이는 지속적 캐싱, 마이그레이션 목적 아님

해설

【핵심 용어】 ▸ Amazon Route 53 — AWS 관리형 DNS 서비스, 자동 스케일, SLA 99.99% ▸ Auto Scaling + Multi-AZ — 고가용성, 운영 자동화 【정답 포인트】 ▸ 가용성 최대화: 두 개 AZ에 분산하면 한 AZ 장애 시에도 서비스 지속 ▸ 운영 오버헤드 최소: Auto Scaling으로 CPU 기반 자동 확장, 200 영역과 100만 QPS 처리 ▸ 중요: Route 53으로 마이그레이션이 최선이나, 선택지 내에서 EC2 + Auto Scaling이 거의 동등 수준 가용성 제공 【오답 체크】 (A) Route 53 콘솔 수동 가져오기는 200 영역 관리 복잡도, Auto Scaling 미지원 (B) 단일 EC2 인스턴스는 SPOF(단일 장애점), 100만 QPS 처리 용량 부족 (C) AWS SMS는 서버 이미지 마이그레이션용, DNS 영역 파일 마이그레이션에 부적절 【시험 포인트】 ▸ 높은 QPS + 고가용성 DNS → 관리형 서비스(Route 53 권장) 또는 Multi-AZ Auto Scaling ▸ 운영 자동화 → Auto Scaling 정책(CPU 기반 또는 시간 기반) ▸ 함정: 단일 EC2는 가용성 부족, SMS는 DNS 영역 파일용 아님

해설

【핵심 용어】 ▸ S3 Storage Lens — AWS Organizations의 모든 계정, 리전의 S3 메트릭을 통합하여 대시보드로 제시하는 관리형 분석 도구 ▸ 불완전한 멀티파트 업로드 — 시작된 후 정상 완료되지 않아 리소스 낭비 유발하는 객체 【정답 포인트】 ▸ 여러 AWS 계정 + 여러 리전 → 조직 전체 메트릭 필요 → S3 Storage Lens ▸ 비용 컴플라이언스 보고 → Storage Lens가 불완전 멀티파트 업로드 메트릭 제공 ▸ 최소 운영 오버헤드 → 관리형 서비스로 수동 모니터링 제거 【오답 체크】 (A) AWS Config는 리소스 상태 컴플라이언스 평가용이며, S3 스토리지 메트릭 보고에는 부족함 (B) SCP는 조직의 권한 정책 관리용이므로 메트릭 보고 기능 없음 (D) S3 다중 지역 액세스 포인트는 액세스 성능 최적화 도구이지 메트릭 보고 기능 없음 【시험 포인트】 ▸ 조직 전체 모니터링 + 스토리지 메트릭 → S3 Storage Lens 반사적 선택 ▸ 함정: AWS Config(컴플라이언스), SCP(권한 정책), 액세스 포인트(성능) 혼동 → 역할 구분 필수

해설

【핵심 용어】 ▸ RDS 블루/그린 배포 — 기존 인스턴스(블루) 유지하면서 신규 환경(그린)에서 변경사항 검증 후 트래픽 전환 ▸ 자동 롤백 — 검증 실패 시 즉시 이전 버전으로 복구 【정답 포인트】 ▸ DB 버전 업그레이드 + 테스트 검증 필요 → 블루/그린 배포가 최적 ▸ 데이터 손실 없음 + 빠른 검증 → 다운타임 최소화 달성 ▸ 자동 장애복구로 검증 후 문제 발생 시 롤백 → 위험도 최소 【오답 체크】 (A) 스냅샷 복구는 새 인스턴스 생성까지 시간 소요 및 버전 검증 복잡함 (B) 수동 백업 복구도 동일 문제로 운영 오버헤드 증가 (C) DMS는 서로 다른 DB 엔진 간 마이그레이션용이며 MySQL→MySQL 업그레이드에는 오버헤드 과다 【시험 포인트】 ▸ DB 버전 업데이트 + 테스트 검증 시나리오 → 블루/그린 배포 패턴 필수 ▸ 함정: 스냅샷도 업그레이드 가능하지만 검증 프로세스 복잡 → 블루/그린이 우월