정답 · 해설

해설

【핵심 용어】 ▸ Redshift Private Subnet + Interface VPC Endpoint — 외부에서 접근 불가. NAT Gateway로 S3 인입 가능. ▸ Enhanced VPC Routing — Redshift COPY/UNLOAD 트래픽이 VPC를 경유. Direct Connect로 외부 데이터 제공자와 사설 연결. 【정답 포인트】 ▸ A(프라이빗 서브넷 + Interface VPC Endpoint) — 외부 노출 0. ▸ C(Enhanced VPC Routing + Direct Connect) — 데이터 제공자와의 트래픽이 회사 네트워크 내부로. 【오답 체크】 (B) CloudHSM 키 관리는 외부 노출 차단과 직접 무관. (D) PK/FK 제약은 데이터 모델 — 보안 무관. (E) Federated query는 데이터 제공자 직접 쿼리 — 시나리오 다름.

해설

【핵심 용어】 ▸ S3 Event Notifications → Lambda → Redshift COPY — 파일 도착 즉시 적재. near real-time 표준 패턴. 【정답 포인트】 ▸ 파일 도착 트리거 + Redshift 적재 = S3 이벤트 + Lambda + COPY. 【오답 체크】 (A) Query Editor 스케줄은 시간 기반 — 즉시성 부족. (B) Aurora zero-ETL은 Aurora ↔ Redshift 통합. S3 파일과 무관. (C) Glue 잡은 배치 — near real-time 보장 어려움.

해설

【핵심 용어】 ▸ Redshift Streaming Ingestion from KDS — Materialized View로 KDS 스트림을 직접 적재. Firehose/S3 중간 단계 0. 【정답 포인트】 ▸ KDS → Redshift Streaming Ingestion + MV = 가장 가벼운 경로. AUTO REFRESH로 신규 데이터 즉시 반영. 【오답 체크】 (A) Firehose 중간은 버퍼링 지연. (B) S3 → 1분 COPY는 배치 지연. (C) Flink → Redshift 직접 송출은 표준 통합 아님.

해설

【핵심 용어】 ▸ Glue JDBC + Job Bookmark — 단조 증가 컬럼 기반 증분 추적. 50GB 미만 테이블에 적합. 【정답 포인트】 ▸ 단조 증가 키 + 50GB 미만 + 매일 야간 ETL = Glue JDBC + 책갈피. DMS 대비 단순. 【오답 체크】 (A) DMS는 가능하지만 50GB 미만 테이블엔 과한 인프라. (C)(D) 매일 전체 로드는 비효율 + 운영 부담.

해설

【핵심 용어】 ▸ DMS Ongoing Replication (CDC) → S3 Parquet — Oracle 트랜잭션 로그를 읽어 S3에 변경분만 Parquet 적재. 70개 테이블 일괄 처리. 【정답 포인트】 ▸ 70개 테이블 + PK 있음 + 매일 변경 반영 + Parquet = DMS CDC + S3 Parquet 타깃이 최소 노력. 【오답 체크】 (A) Sqoop은 EMR 운영 부담 + 변경 감지 직접 구현. (B) Glue 책갈피 + 70개 테이블 = 잡·연결 관리 부담. (D) RDS 경유 + Lambda 트리거 = 인프라 폭증.

해설

【핵심 용어】 ▸ Kinesis Producer Library (KPL) — 자동 배칭·집계(aggregation)·재시도. 같은 샤드로 여러 레코드를 묶어 처리량·비용 효율. ▸ 작은 레코드(10B) + 초당 10,000건 + 지연 허용 = KPL aggregation의 최적 대상. 【정답 포인트】 ▸ 처리량 효율 + 신뢰성 = KPL. 【오답 체크】 (A) Kinesis Agent는 로그 파일 기반 — 임베디드 SDK 시나리오와 다름. (C) Firehose는 KDS 인입 도구가 아닌 별도 적재 경로. (D) Kinesis SDK 직접은 배칭·집계 직접 구현 부담.

해설

【핵심 용어】 ▸ Glue FindMatches — fuzzy 매칭 ML. 오타·표기 변형까지 같은 엔티티로 dedup. 【정답 포인트】 ▸ 표기 차이 dedup + 최소 운영 = FindMatches 변환. 학습 데이터 소량 + 자동 처리. 【오답 체크】 (B) Athena 윈도 함수는 정확 일치만. (C) Neptune Gremlin은 그래프 — dedup 도구 아님. (D) DynamoDB Global Tables는 동기화이지 dedup 아님.

해설

【핵심 용어】 ▸ KPL의 PutRecords 재시도 → 네트워크 타임아웃 시 중복 인입 가능. ▸ KCL의 샤드 변동(리샤딩) → 새 워커가 같은 데이터 재처리할 수 있음. 【정답 포인트】 ▸ A(프로듀서 타임아웃 → 재시도 중복). ▸ C(샤드 수/레코드 프로세서 변경 → 재처리). 【오답 체크】 (B) IteratorAgeMilliseconds는 처리 지연 지표 — 중복 원인 아님. (D) AggregationEnabled는 묶음 처리 — 중복 원인 아님. (E) max_records 자체는 중복 원인 아님.

해설

【핵심 용어】 ▸ Glue + Redshift + QuickSight — 다양한 RDB 인입(Glue 커넥터) + DW(Redshift) + 대시보드(QuickSight). 표준 분석 스택. 【정답 포인트】 ▸ 여러 운영 시스템 → DW → 대시보드 = Glue + Redshift + QuickSight. 시간당 추적도 자연스럽게. 【오답 체크】 (B) DynamoDB는 분석 DW 아님. (C)(D) DMS + DynamoDB + Grafana/QuickSight = 분석 워크로드엔 RDS·Redshift가 더 자연스러움.

해설

【핵심 용어】 ▸ Amazon Neptune — 그래프 DB. 두 가지 그래프 모델 지원: Property Graph(Gremlin), RDF(SPARQL). 【정답 포인트】 ▸ A(Gremlin) — 속성 그래프 쿼리 언어. ▸ D(SPARQL) — RDF 쿼리 언어. 【오답 체크】 (B)(C) SQL/ANSI SQL은 관계형 DB 언어. (E) Spark SQL은 빅데이터 프레임워크 언어.

해설

【핵심 용어】 ▸ KDS Enhanced Fan-out — 컨슈머별 전용 처리량(2 MB/s/샤드). 여러 컨슈머가 서로 영향 없이 독립 소비. 【정답 포인트】 ▸ 3개 내부 컨슈머 + 각자 전용 처리량 = KDS + Enhanced Fan-out. 【오답 체크】 (B) Firehose는 직접 컨슈머 모델이 다름. (C) Firehose에 enhanced fan-out 개념 없음. (D) EC2 직접 호스팅 + EFO 미사용 = 처리량 공유.

해설

【핵심 용어】 ▸ Spectrum 성능 = 컬럼형 포맷 + 파티셔닝 + 작은 파일 합치기. 【정답 포인트】 ▸ A(소스에서 컬럼형 생성) — Glue ETL 단계 절약. ▸ C(주문 일자 파티셔닝) — 일별 집계 쿼리에서 파티션 프루닝. 【오답 체크】 (B) 30개 → 1개 파일은 병렬도 떨어짐 — 컬럼형이 더 핵심. (D) JSON은 행 기반 — 비효율. (E) SUPER 컬럼은 반정형용 — 100개 컬럼 정형 데이터엔 부적합.

해설

【핵심 용어】 ▸ S3 Object Lock Compliance Mode — 보존 기간 동안 누구도(루트 포함) 삭제·수정 불가. 규제 준수. ▸ Governance Mode — 특정 권한 보유자는 우회 가능. 【정답 포인트】 ▸ 루트 사용자도 변경 불가 = Compliance Mode가 유일한 옵션. 【오답 체크】 (A) Governance는 우회 가능. (C) Legal hold는 보존 기간 무관. (D) Object Lock 없는 보존 기간 설정은 표준 기능 아님.

해설

【핵심 용어】 ▸ CTAS WITH NO DATA — 스키마만 복제, 행 0개. 빈 테이블 생성에 표준. 【정답 포인트】 ▸ 스키마 동일 + 빈 테이블 = CREATE TABLE AS (SELECT...) WITH NO DATA. 【오답 체크】 (A) 일반 CTAS는 데이터까지 복제. (B) INSERT는 데이터 적재. (C) CREATE TABLE LIKE는 Athena Hive 표준 호환 X(또는 일부 엔진 한정).

해설

【핵심 용어】 ▸ INSERT INTO ... SELECT — 다른 테이블의 부분 결과를 기존 테이블에 적재. 【정답 포인트】 ▸ cities_world에서 country='usa'만 cities_us에 적재 = INSERT INTO ... SELECT WHERE. 【오답 체크】 (B) MOVE는 SQL 표준 아님. (C) 컬럼 명시 없이 INSERT INTO는 컬럼 매칭 위험(스키마 일치 시 가능하지만 A가 더 명확). (D) UPDATE 부속 SELECT 형태는 부적절.

해설

【핵심 용어】 ▸ Redshift Data Share — 다른 워크그룹/계정과 라이브 공유. ▸ Lake Formation Data Share Integration — Redshift Data Share를 Lake Formation 카탈로그로 공유 → 행/열 권한 관리. 【정답 포인트】 ▸ B(Redshift Data Share 생성) + D(LF 카탈로그로 공유) = LF가 컬럼 단위 권한을 마케팅·컴플라이언스에 다르게 부여. 【오답 체크】 (A) 뷰 분리는 운영 부담↑. (C) 워크그룹 직접 공유는 LF 기반 컬럼 권한 적용 어려움. (E) 직접 워크그룹 공유는 같은 데이터 두 그룹에 다른 권한 적용 어려움.

해설

【핵심 용어】 ▸ Glue Studio Evaluate Data Quality Transform — DQDL로 룰 정의 후 ETL 잡에 변환으로 추가. 임계값 검증 가능. 【정답 포인트】 ▸ 데이터 품질 룰을 ETL 잡 흐름에 직접 = Evaluate Data Quality 변환 + DQDL. 【오답 체크】 (A) SQL 직접 작성 = 코드 부담. (C) PyDeequ 직접 도입 = 라이브러리 관리·러닝 커브. (D) Great Expectations 직접 도입 = 동일.

해설

【핵심 용어】 ▸ FluentBit (로그) + OpenTelemetry (트레이스) — EKS 표준 관측성 콜렉터. ▸ OpenSearch — 로그 + 트레이스 상관관계 분석에 강한 통합 플랫폼. 【정답 포인트】 ▸ A(FluentBit + OpenTelemetry) + D(OpenSearch 상관관계) = 최소 개발 노력의 마이크로서비스 관측성 스택. 【오답 체크】 (B) Kinesis는 로그/트레이스 직접 모델 아님. (C) MSK 트레이스 수집은 비표준. (E) Glue는 ETL — 관측성 도구 아님.

해설

【핵심 용어】 ▸ DynamoDB Streams — 테이블 변경 캡처 → Lambda 트리거 → OpenSearch 인덱싱. near real-time. 【정답 포인트】 ▸ DynamoDB → OpenSearch near real-time = Streams + Lambda 패턴. 【오답 체크】 (A) Step Functions 주기적 export = 배치 지연. (B) Glue 잡 직접 DynamoDB → OpenSearch는 near real-time 보장 어려움. (D) 커스텀 OpenSearch 플러그인은 직접 구현·유지 부담.

해설

【핵심 용어】 ▸ Redshift AUTO Distribution — 워크로드와 테이블 크기 기반으로 자동 ALL ↔ EVEN 결정 + 모니터링. 【정답 포인트】 ▸ 적절한 키 컬럼 부재 + 최소 유지 부담 = AUTO. 데이터 양·접근 패턴 변화에 자동 적응. 【오답 체크】 (A) ALL은 큰 테이블에 비효율. (B) EVEN은 모든 조인에 셔플 발생. (D) KEY는 적절한 키 없는 시나리오에 부적합.