정답 · 해설

해설

【핵심 용어】 ▸ Amazon EventBridge Rule — AWS Batch 작업의 SUCCEEDED 이벤트에 반응 ▸ EventBridge API Destination — 외부 HTTP API를 대상으로 호출, Connection에 사용자명/비밀번호(기본 인증) 저장·관리 ▸ Lambda / API Gateway 프록시 — 커스텀 코드/추가 계층 (서버리스·최소 구성 대비 부담) 【정답 포인트】 ▸ "Batch 작업 성공 시 서드파티 HTTP API(사용자명/비밀번호) 호출" + "서버리스" → EventBridge 규칙이 SUCCEEDED 매칭 → API destination(기본 인증)을 타깃으로 직접 호출, 코드 불필요 【오답 체크】 (B) EventBridge Scheduler는 시간 기반 스케줄러로 이벤트(SUCCEEDED) 매칭 용도가 아니며 Lambda 코드도 추가됨. (C) Batch가 직접 API Gateway로 이벤트를 발행하는 기능은 없고 흐름이 성립 안 함. (D) API Gateway + Lambda 프록시는 불필요한 추가 계층·코드로 API destination 대비 복잡. 【시험 포인트】 "이벤트 → 외부 HTTP API(인증 포함) 호출, 코드 없이" → EventBridge Rule + API Destination(Connection).

해설

【핵심 용어】 ▸ AWS PrivateLink — 인터넷/피어링 없이 계정 간 서비스에 프라이빗 연결(인터페이스 엔드포인트) ▸ Network Load Balancer — PrivateLink 엔드포인트 서비스의 프런트로 RDS 앞에 배치 ▸ Direct Connect / VPN / Transit Gateway + Peering — 전용선/터널/광역 연결 (요건·구성 부적합) 【정답 포인트】 ▸ "IGW·Direct Connect·VPN 없는 VPC에서 벤더 계정 RDS 접근" → 벤더가 RDS 앞에 NLB 배치 후 PrivateLink로 소비 측 VPC에 프라이빗 노출 ▸ 인터넷 경유 없이 계정 간 단방향 프라이빗 접근 실현 【오답 체크】 (A) Direct Connect 호스티드 커넥션은 물리 전용선으로 과도하고, 피어링 언급도 시나리오와 안 맞음. (B) Client VPN + 피어링 조합은 목적·구성이 부적절하고 복잡. (D) Transit Gateway와 VPC 피어링을 동시에 쓰는 구성은 모순적이고 요건에 과함. 【시험 포인트】 "계정 간 특정 서비스만 프라이빗 노출(인터넷 없이)" → NLB + PrivateLink.

해설

【핵심 용어】 ▸ Amazon Managed Grafana in VPC — 워크스페이스를 VPC에 연결해 데이터를 인터넷에 노출하지 않고 프라이빗 접근 ▸ RDS Private Endpoint — RDS를 프라이빗 엔드포인트로 두어 VPC 내부에서만 접근 ▸ 퍼블릭 엔드포인트 — 인터넷 노출 (보안 요건 위반) 【정답 포인트】 ▸ "RDS를 인터넷에 노출하지 않고 안전하게 시각화" → Managed Grafana를 VPC에 배치 + RDS 프라이빗 엔드포인트로 연결 【오답 체크】 (A) VPC 없는 워크스페이스 + RDS 퍼블릭 엔드포인트는 데이터를 인터넷에 노출해 요건 위반. (C) VPC 없는 워크스페이스 구성은 프라이빗 접근 요건과 맞지 않고 설명도 부정확. (D) VPC 내 워크스페이스라도 RDS 퍼블릭 엔드포인트를 쓰면 인터넷 노출로 요건 위반. 【시험 포인트】 "데이터 인터넷 미노출 + 프라이빗 접근" → 서비스 VPC 연결 + 데이터소스 프라이빗 엔드포인트.

해설

【핵심 용어】 ▸ AWS Glue DataBrew — 코드 없이(no-code) 시각적 데이터 정제/변환, 데이터 계보(lineage)·프로파일링 제공 ▸ DataBrew Recipe — 변환 단계를 레시피로 저장·공유해 사내 재사용 ▸ Glue Studio / EMR Serverless / Athena SQL — 코드/스크립트 기반 (no-code·계보·프로파일링·레시피 공유 요건 미충족) 【정답 포인트】 ▸ "코드 없는 사전 구축 변환 + 데이터 계보·프로파일링 + 변환 단계 사내 공유" → DataBrew + 레시피 공유가 정확히 부합 【오답 체크】 (A) Glue Studio 비주얼 캔버스는 노코드에 가깝지만 데이터 프로파일링·계보를 DataBrew만큼 기본 제공하지 않고 Glue 잡은 코드성. (B) EMR Serverless는 코드/스크립트 기반으로 no-code 요건 위반. (D) Athena SQL 쿼리는 코드(SQL) 작성이 필요하고 프로파일링·계보 요건 미충족. 【시험 포인트】 "no-code 데이터 준비 + 프로파일링·계보 + 레시피 공유" → AWS Glue DataBrew.

해설

【핵심 용어】 ▸ Route 53 A Record → ALB — 개발용 도메인을 ALB로 매핑(alias) ▸ ALB Listener Rule (host/path 기반) — 개발 도메인 요청을 개발 인스턴스가 속한 타깃 그룹으로 포워딩 ▸ Target Group — 인스턴스가 교체돼도 타깃 그룹 등록으로 라우팅 유지 【정답 포인트】 ▸ "개발 도메인으로 특정 개발 인스턴스 접근 + 인스턴스 교체돼도 자동 라우팅" → A 레코드를 ALB로 두고, ALB 리스너 규칙이 개발 타깃 그룹으로 전달 ▸ 공인 IP가 아닌 타깃 그룹 기반이라 인스턴스 교체 시에도 안정적 【오답 체크】 (B) 인스턴스 공인 IP를 A 레코드에 직접 지정하면 인스턴스 교체 시 IP가 바뀌어 라우팅 깨짐. (C) ALB가 특정 공인 IP로 리다이렉트하는 방식도 인스턴스 교체 시 IP 변경으로 실패. (D) 모든 인스턴스를 한 타깃 그룹에 넣으면 개발 인스턴스 하나만 지정하는 요건을 못 지킴. 【시험 포인트】 "특정 인스턴스로 안정 라우팅(교체 무관)" → Route53 A→ALB + 리스너 규칙 → 해당 타깃 그룹.

해설

【핵심 용어】 ▸ Amazon EKS — 관리형 Kubernetes, 온프레미스 Kubernetes에서 이관 시 재작업 최소 ▸ Amazon MQ — 관리형 메시지 브로커, AMQP(및 MQTT/STOMP) 프로토콜 그대로 지원 ▸ SQS — AWS 고유 프로토콜(AMQP 아님)로 애플리케이션 코드 변경 필요 【정답 포인트】 ▸ "온프레미스 Kubernetes 컨테이너 앱" → EKS로 이관해 변경 최소 ▸ "AMQP로 메시지 큐 통신" → Amazon MQ가 AMQP를 그대로 지원해 코드 변경 없이 이관 【오답 체크】 (A) ECS는 Kubernetes에서의 이관 변경이 크고, SQS는 AMQP를 지원하지 않아 코드 수정 필요. (C) EC2 직접 운영은 관리 부담이 크고 관리형 대비 운영 오버헤드 증가. (D) Lambda로 재작성 + SQS(AMQP 미지원)는 컨테이너 앱 이관에 큰 변경 필요. 【시험 포인트】 "Kubernetes→EKS(변경 최소), AMQP 큐→Amazon MQ(프로토콜 호환)".

해설

【핵심 용어】 ▸ AWS Global Accelerator (Standard) — AWS 글로벌 백본과 애니캐스트 IP로 전 세계 사용자 지연 감소, NLB/ALB/EIP를 엔드포인트로 등록 ▸ NLB Target Endpoints — 기존 리전별 NLB를 그대로 Global Accelerator 엔드포인트로 사용 ▸ Route 53 가중치 / 리전 추가 / ALB 교체 — DNS 분산·인프라 증설 (백본 기반 지연 최적화 아님) 【정답 포인트】 ▸ "여러 리전 NLB + 글로벌 고객 종단 지연 감소" → Global Accelerator 표준 액셀러레이터에 기존 NLB를 엔드포인트로 등록해 최적 경로로 라우팅 【오답 체크】 (A) NLB를 ALB로 교체하는 것은 지연 개선의 핵심이 아니고 대규모 변경. (B) Route 53 균등 가중 라우팅은 지연 기반 최적화가 아니라 단순 분산. (C) 리전·인스턴스 추가 증설은 비용·복잡도가 크고 근본적 글로벌 지연 최적화가 아님. 【시험 포인트】 "글로벌 사용자 종단 지연 감소 + 다중 리전 엔드포인트" → AWS Global Accelerator.

해설

【핵심 용어】 ▸ AWS Transfer Family — 완전관리형 SFTP/FTPS/FTP 엔드포인트, S3/EFS로 직접 업로드 ▸ Managed Service — 레거시 SFTP 클라이언트를 코드 변경 없이 수용, 서버 운영 부담 없음 ▸ DMS / EC2 SFTP / S3 File Gateway — DB 복제 / 자체 운영 / SMB (SFTP 관리형 요건 대비 부적합/운영 부담) 【정답 포인트】 ▸ "레거시 벤더가 SFTP 그대로 사용 + 관리형 + 최소 운영" → AWS Transfer Family SFTP 엔드포인트로 S3에 업로드 【오답 체크】 (A) DMS는 DB 마이그레이션/복제 도구로 SFTP 파일 업로드 시나리오와 무관. (C) EC2에서 SFTP 서버를 직접 운영하면 패치·확장 등 운영 부담이 커 관리형 요건 위반. (D) S3 File Gateway는 SMB/NFS 프로토콜로 SFTP를 요구하는 벤더 요건과 불일치. 【시험 포인트】 "관리형 SFTP/FTPS 엔드포인트" → AWS Transfer Family.

해설

【핵심 용어】 ▸ Amazon Textract — PDF/문서에서 텍스트·데이터 추출(문제에서 사용 지정) ▸ Amazon Comprehend — 추출된 텍스트의 인사이트·감정(sentiment) 분석을 관리형으로 수행 ▸ SageMaker / Athena / QuickSight — 모델 개발 / 쿼리 / 시각화 (감정 분석 관리형·최소 운영 요건과 불일치) 【정답 포인트】 ▸ "Textract로 PDF 처리 후 콘텐츠·감정 인사이트 추출" + "최소 운영" → Comprehend가 사전 학습 NLP로 감정·엔티티 분석 제공, 결과를 S3에 저장 【오답 체크】 (A) Athena는 SQL 분석 엔진으로 감정 분석 기능이 없음. (B) SageMaker로 감정 모델을 직접 구축하는 것은 운영 부담이 커 최소 운영에 반함. (D) QuickSight는 시각화 도구로 감정 분석을 수행하지 않음. 【시험 포인트】 "문서 텍스트 추출(Textract) + 감정/인사이트 분석(관리형)" → Amazon Comprehend.

해설

【핵심 용어】 ▸ Amazon Kinesis Data Streams — 서드파티의 실시간 데이터를 수집(ingest)하는 스트림 ▸ Amazon Kinesis Data Firehose — 스트림을 소비해 S3 등 대상으로 자동 적재(원시 데이터 저장) ▸ DMS / DataSync / Direct Connect — DB 복제 / 파일 전송 / 전용선 (실시간 스트리밍 수집·S3 적재에 부적합) 【정답 포인트】 ▸ "서드파티 실시간 데이터 수집 → 원시 데이터를 S3에 저장" → Kinesis Data Streams(수집) + Firehose(소비·S3 전달) 조합 【오답 체크】 (B) DMS는 DB 간 마이그레이션/복제 도구로 서드파티 실시간 스트림 수집에 부적합. (C) DataSync는 파일/스토리지 전송 서비스로 실시간 스트리밍 수집이 아님. (D) Direct Connect는 전용 네트워크 연결로 실시간 데이터 수집의 핵심 수단이 아니며 구성이 과함. 【시험 포인트】 "실시간 데이터 수집 + S3 적재" → Kinesis Data Streams + Firehose.

해설

【핵심 용어】 ▸ DynamoDB Item Size Limit — 항목 최대 400KB (700KB 데이터는 초과) ▸ S3 + DynamoDB 포인터 패턴 — 큰 데이터는 S3 객체로 저장, DynamoDB에는 S3 URL(포인터)만 저장 ▸ DocumentDB / BatchWriteItem / gzip — 대체 DB / 배치 쓰기 / 압축 (크기 한도 근본 해결·효율 부적합) 【정답 포인트】 ▸ "최대 700KB(400KB 초과) + 계속 증가 + 운영 효율" → 대용량은 S3에 저장하고 DynamoDB 항목엔 S3 URL만 두는 표준 패턴 【오답 체크】 (A) 큰 데이터를 DocumentDB로 분리하면 두 DB 운영 부담이 늘어 효율 저하. (C) 같은 파티션 키로 분할 저장은 핫 파티션 위험 + 재조립 복잡성 + 항목 한도 근본 해결 아님. (D) gzip 압축으로 700KB를 400KB 미만으로 항상 줄인다는 보장이 없어 신뢰 불가. 【시험 포인트】 "DynamoDB 400KB 초과 대용량 저장" → S3에 데이터, DynamoDB에 S3 포인터.

해설

【핵심 용어】 ▸ Amazon EventBridge Scheduler — 크론/반복 및 일회성(미래 시점) 스케줄을 관리형으로 실행 ▸ AWS Fargate — 서버리스 컨테이너 실행, 1~20분 등 다양한 실행 시간 지원(Lambda 15분 한도 초과분 수용) ▸ 컨테이너 이미지화 — 기존 크론 잡을 재작성 없이 컨테이너로 감싸 최소 리팩터링 【정답 포인트】 ▸ "수백 개 크론 잡(1~20분) + 최소 리팩터링 + 미래 이벤트 실행" → 크론 잡을 컨테이너 이미지로 만들고 EventBridge Scheduler로 반복·미래 스케줄, 실행은 Fargate(시간 제한 없음) 【오답 체크】 (A) Lambda는 최대 15분 제한이라 20분까지 걸리는 잡을 처리 못함. (B) AWS Batch는 배치 처리용으로 다수 크론 스케줄 관리에 맞지 않고 미래 이벤트 스케줄링 요건과 어긋남. (D) Step Functions Wait 상태로 개별 크론을 구현하는 것은 수백 개 잡에 복잡·과도한 리팩터링. 【시험 포인트】 "다양한 길이의 크론 잡(>15분) + 반복·미래 스케줄 + 최소 리팩터링" → EventBridge Scheduler + Fargate.

해설

【핵심 용어】 ▸ Amazon AppFlow — SaaS(Salesforce 등)와 AWS 간 데이터 전송을 코드 없이 수행, 초기+증분 변경 지원 ▸ AWS PrivateLink — AppFlow-Salesforce 트래픽을 인터넷을 거치지 않고 프라이빗하게 전송 ▸ Glue DataBrew / VPN / Direct Connect / VPC Peering — 데이터 정제 / 네트워크 연결 (Salesforce↔Redshift 통합·최소 개발 요건 부적합) 【정답 포인트】 ▸ "Salesforce의 기존·증분 데이터를 Redshift로 + 공용 인터넷 미경유 + 최소 개발" → AppFlow(관리형 커넥터)로 전송 + PrivateLink로 프라이빗 경로 【오답 체크】 (A) VPN + DataBrew는 Salesforce 커넥터가 아니며 개발·구성 부담이 큼. (B) Salesforce로 직접 Direct Connect를 맺는 구성은 부적절하고 DataBrew는 전송 도구가 아님. (D) Salesforce와 VPC 피어링은 불가능(SaaS는 고객 VPC가 아님), 개념 오류. 【시험 포인트】 "SaaS(Salesforce)↔AWS 데이터 전송 최소 개발 + 프라이빗" → Amazon AppFlow + PrivateLink.

해설

【핵심 용어】 ▸ Amazon S3 Intelligent-Tiering — 접근 패턴에 따라 티어를 자동 이동해 관리 없이 스토리지 비용 최적화 ▸ S3 API 전환 — 애플리케이션을 S3 API로 변경해 인덱싱 파일을 객체 스토리지에 저장 ▸ FSx / S3 Glacier Flexible Retrieval — 파일 서버 / 아카이브(검색 지연) (자주 접근되는 인덱싱 데이터·비용 최적화에 부적합) 【정답 포인트】 ▸ "EFS 스토리지 비용 최적화 + 앱/서비스 변경 허용" → 파일을 S3로 옮기고 Intelligent-Tiering으로 접근 패턴 기반 자동 비용 절감, 앱은 S3 API 사용 【오답 체크】 (B) FSx for Windows(CIFS)는 파일 서버로 비용 최적화 목적과 맞지 않음. (C) FSx for OpenZFS도 고성능 파일 시스템으로 비용 절감 목표에 부적합. (D) S3 Glacier Flexible Retrieval는 아카이브용으로 검색 지연이 커 활발히 쓰는 인덱싱 파일에 부적합. 【시험 포인트】 "접근 패턴 불명확한 파일 비용 최적화 + 관리 없이" → S3 Intelligent-Tiering.

해설

【핵심 용어】 ▸ Application Load Balancer (ALB) — L7 로드밸런서, 쿼리 문자열(query string)·경로·호스트 기반 라우팅 지원 ▸ AWS Certificate Manager (ACM) — ALB에 TLS 인증서 부착해 트래픽 암호화(HTTPS) ▸ NLB / GWLB — L4 / 트래픽 검사 (쿼리 문자열 기반 L7 라우팅 미지원) 【정답 포인트】 ▸ "퍼블릭 로드밸런서 + 쿼리 문자열 기반 타깃 그룹 라우팅 + 암호화" → ALB(L7 쿼리스트링 라우팅) + ACM 인증서(HTTPS) 【오답 체크】 (A) NLB는 L4라 쿼리 파라미터 기반 라우팅을 지원하지 않음. (B) GWLB는 트래픽 검사용이고 HTTP 경로 라우팅·쿼리 라우팅에 부적합, IAM 인증서 방식도 비권장. (D) NLB는 쿼리 파라미터 기반 라우팅이 불가하고 IAM 인증서 임포트 방식도 ACM 대비 비권장. 【시험 포인트】 "쿼리 문자열/경로 기반 L7 라우팅 + HTTPS" → ALB + ACM.

해설

【핵심 용어】 ▸ Auto Scaling group + ALB — 애플리케이션 계층의 자동 확장·고가용성 표준 구성 ▸ Amazon Aurora Serverless (MySQL 호환) — 트래픽에 따라 용량 자동 조절, Multi-AZ 고가용성 지원 ▸ Amazon Redshift — 데이터 웨어하우스(OLAP), 트랜잭션 MySQL 대체 불가 ▸ ElastiCache for Redis — 인메모리 캐시, DB 대체 아님 【정답 포인트】 ▸ "고가용성 + 자동 확장" 앱 계층 → Auto Scaling group + ALB ▸ "MySQL DB + 자동 확장" → Aurora Serverless MySQL이 부하 증가에 따라 용량 자동 조절 【오답 체크】 (A) Redshift는 분석용 웨어하우스로 애플리케이션 트랜잭션 DB로 부적합. (B) target group만 구성은 Auto Scaling group이 아니라 앱 계층 자동 확장이 없음. (D) ElastiCache Redis는 캐시일 뿐 MySQL DB 대체 불가, "MySQL connector"는 허구. 【시험 포인트】 "HA + 자동 확장 앱" = ASG + ALB, "자동 확장 MySQL DB" = Aurora Serverless.

해설

【핵심 용어】 ▸ AWS KMS customer managed key — 고객 관리형 키, 자동 키 순환(연 1회) 지원 ▸ SSE-S3 — S3 관리형 키 암호화, 순환은 자동이나 주기를 사용자가 제어 불가 ▸ 가져온 키 자료(imported key material) — 자동 순환 불가 【정답 포인트】 ▸ "저장 시 암호화 + 매년 자동 순환" → KMS 고객 관리형 키의 자동 순환은 연 1회 주기 ▸ "최소 운영 부담" → 기본 암호화 설정으로 지정 후 자동 순환 활성화하면 관리 불필요 【오답 체크】 (A) SSE-S3는 매년 순환을 사용자가 구성·보장할 수 없음. (C) 수동 순환은 매년 직접 작업이 필요해 운영 부담 큼. (D) 가져온 키 자료는 KMS 자동 순환을 지원하지 않음. 【시험 포인트】 "매년 자동 키 순환 + 최소 운영" → KMS 고객 관리형 키 + 자동 순환.

해설

【핵심 용어】 ▸ AWS IAM Identity Center — 여러 AWS 계정에 걸친 SSO 제공, Organizations 연동 ▸ AWS Managed Microsoft AD + forest trust — 자체 관리 온프레미스 AD와 양방향 신뢰 관계로 연결 ▸ AD Connector / 자체 IdP — 대안 연결 방식 【정답 포인트】 ▸ "모든 계정 SSO" → IAM Identity Center 활성화 ▸ "온프레미스 AD에서 사용자·그룹 계속 관리" → AWS Managed Microsoft AD와 양방향 포리스트 신뢰로 자체 AD를 ID 원본으로 유지 【오답 체크】 (A) AWS에 새 AD를 ID 원본으로 만들면 온프레미스 AD에서 사용자 계속 관리 요건과 어긋남. (C) Directory Service 신뢰만으로는 다계정 SSO를 제공하지 못함(IAM Identity Center 없음). (D) EC2에 자체 IdP 배포는 운영 부담이 크고 기존 AD 활용도 아님. 【시험 포인트】 "다계정 SSO + 온프레미스 AD 유지" → IAM Identity Center + Managed Microsoft AD 신뢰.

해설

【핵심 용어】 ▸ Aurora I/O-Optimized — I/O 요금 없는 예측 가능한 스토리지 구성, I/O 집약 워크로드에 비용 효율적 ▸ Aurora Standard — I/O당 과금, 낮은 I/O에 유리 ▸ Provisioned IOPS / General Purpose — RDS(비 Aurora)용 스토리지 유형, Aurora 옵션 아님 【정답 포인트】 ▸ "대량 트래픽 + 부하 증가에 따른 스토리지 성능 최적화 + 가장 비용 효율" → I/O가 많을수록 I/O-Optimized가 요금 예측 가능하고 저렴 【오답 체크】 (A) Aurora Standard는 I/O당 과금이라 고트래픽에서 비용 급증. (B) Provisioned IOPS는 Aurora 스토리지 옵션이 아님. (C) General Purpose는 Aurora 스토리지 옵션이 아님. 【시험 포인트】 Aurora + "높은 I/O·대량 트래픽에 비용 효율" → Aurora I/O-Optimized.

해설

【핵심 용어】 ▸ AWS Security Hub — 다계정 보안 태세를 표준(NIST, PCI DSS 등) 기준으로 통합 평가·모니터링 ▸ Amazon Inspector — 취약점 스캔(EC2/컨테이너/Lambda) ▸ Amazon GuardDuty — 위협 탐지, CloudTrail — 감사 로깅 【정답 포인트】 ▸ "설계된 통제가 구현·정상 작동한다는 증빙 + 현재 상태를 계정 전체에서 모니터링" → Security Hub 위임 관리자로 전 멤버 계정 활성화, NIST/PCI DSS 표준 적용 【오답 체크】 (A) Inspector는 취약점 스캔용으로 규정 준수 통제 상태 증빙 목적과 다름. (B) GuardDuty는 위협 탐지용, 규정 준수 표준 평가 도구 아님. (C) CloudTrail은 로깅 서비스로 보안 표준 평가 기능 없음. 【시험 포인트】 "NIST/PCI DSS 규정 준수 상태 다계정 모니터링" → Security Hub 표준.