AWS 데이터 분석 전문가 (DAS-C01) 실전 모의고사 65문제

A) Kinesis Data Firehose B) Kinesis Data Streams C) SQS FIFO Queue D) MSK (Amazon Managed Streaming for Kafka)

정답: B

설명: Kinesis Data Streams는 파티션 키 기반의 순서 보장, 최대 7일(기본 24시간) 데이터 보존, 실시간 재처리가 가능합니다. Firehose는 재처리 불가, SQS FIFO는 처리량 제한이 있습니다.

A) 샤드 수를 늘린다 B) Enhanced Fan-Out을 활성화한다 C) Provisioned 모드로 전환한다 D) GetRecords API 호출 빈도를 줄인다

정답: B

설명: Enhanced Fan-Out은 각 Consumer에게 샤드당 2MB/s의 독립적인 읽기 처리량을 제공합니다. 기본 GetRecords는 모든 Consumer가 샤드당 2MB/s를 공유하지만, Enhanced Fan-Out은 Consumer별로 전용 처리량을 할당합니다.

A) Lambda 변환 + 접두사 표현식 B) Format Conversion + Dynamic Partitioning C) Glue ETL 작업 연동 D) S3 Object Lambda 사용

정답: B

설명: Kinesis Data Firehose의 Format Conversion 기능으로 JSON을 Parquet/ORC로 변환하고, Dynamic Partitioning으로 레코드 내 특정 필드 값을 기반으로 S3 접두사를 동적으로 설정합니다. jq 표현식이나 인라인 파싱을 사용합니다.

A) AWS Glue ETL 작업으로 전체 테이블 주기적 복사 B) AWS DMS + 지속적 복제 태스크 C) Kinesis Data Streams + Lambda D) Snowball Edge로 초기 로드 후 Direct Connect

정답: B

설명: AWS DMS(Database Migration Service)는 소스 데이터베이스의 트랜잭션 로그를 읽어 CDC를 구현합니다. 초기 전체 로드 후 지속적 복제 태스크로 변경사항만 실시간으로 동기화합니다. Oracle에서 Redshift로의 이기종 마이그레이션은 SCT(Schema Conversion Tool)도 함께 사용합니다.

A) AWS Direct Connect 전용선 구축 B) AWS Snowball Edge Storage Optimized 다수 주문 C) AWS Snowmobile 사용 D) S3 Transfer Acceleration 활성화

정답: C

설명: 페타바이트 이상의 대용량 데이터는 Snowmobile(100PB 이상 적합)을 사용합니다. 수십 페타바이트는 Snowball을 여러 대 사용하거나 Snowmobile을 검토합니다. 인터넷/Direct Connect는 전송 시간이 너무 길고 비용이 높습니다. Snowball Edge는 최대 80TB로 페타바이트급에는 많은 수가 필요합니다.

A) Kinesis Data Streams — 확장성이 더 우수함 B) Amazon MSK — Kafka 호환성과 긴 보존 기간 지원 C) Kinesis Data Firehose — 완전 관리형 D) SQS — 메시지 보존이 더 오래됨

정답: B

설명: Amazon MSK는 Apache Kafka 완전 호환 서비스로 기존 Kafka 클라이언트 코드를 그대로 사용할 수 있습니다. 메시지 보존 기간을 무기한으로 설정할 수 있어 장기 보존에 유리합니다. Kinesis는 최대 365일이지만 Kafka API와 호환되지 않습니다.

A) 샤드 수를 두 배로 늘린다 B) 파티션 키에 랜덤 접두사를 추가하여 샤드 균등 분산 C) Enhanced Fan-Out 활성화 D) Kinesis Producer Library(KPL) Aggregation 비활성화

정답: B

설명: 핫 샤드(특정 파티션 키에 쓰기가 집중) 문제는 파티션 키를 분산시켜 해결합니다. 파티션 키 앞에 랜덤 접두사(예: 0~N 범위의 숫자)를 붙여 여러 샤드에 균등 분배합니다. 단, 읽기 시 fan-out으로 모든 샤드를 읽어야 합니다.

A) Tumbling Window B) Sliding Window C) Session Window D) Global Window

정답: B

설명: Sliding Window는 고정된 크기의 윈도우가 일정 간격으로 슬라이딩합니다. 예를 들어 30분 크기의 윈도우를 1분 간격으로 이동하면 항상 최근 30분 데이터를 기준으로 계산할 수 있습니다. Tumbling Window는 겹치지 않는 고정 구간입니다.

A) 단일 파티션: year/month/day B) 복합 파티션: year/month/day/region C) 파티셔닝 없이 Athena Partition Projection 사용 D) 모든 데이터를 단일 접두사에 저장하고 압축

정답: B

설명: 쿼리 패턴에 맞게 날짜와 지역 코드를 함께 파티셔닝하면 Athena가 스캔할 데이터를 최소화합니다. year/month/day/region 구조로 계층적 파티셔닝을 적용하면 두 필터 조건 모두 파티션 프루닝을 활용할 수 있습니다.

A) S3 버킷 정책으로 특정 접두사 접근 제한 B) Glue 카탈로그 리소스 기반 정책으로 테이블 수준 제한 C) Lake Formation 열 수준 보안(Column-level security) 구성 D) Athena 워크그룹별 쿼리 필터 설정

정답: C

설명: Lake Formation은 테이블, 열, 행 수준의 세밀한 접근 제어를 지원합니다. 열 수준 보안을 사용하면 특정 IAM 역할/사용자에게 특정 열만 표시되도록 제한할 수 있습니다. S3 버킷 정책은 파일 수준이라 열 단위 제어가 불가능합니다.

A) 두 테이블 모두 EVEN 분산 B) 두 테이블 모두 ALL 분산 C) 큰 팩트 테이블은 KEY 분산(조인 키), 작은 차원 테이블은 ALL 분산 D) 두 테이블 모두 AUTO 분산

정답: C

설명: 대형 팩트 테이블 간의 조인에서는 조인 키로 KEY 분산을 동일하게 적용하면 데이터를 각 노드에서 로컬로 조인할 수 있어 네트워크 전송이 최소화됩니다. 소규모 차원 테이블은 ALL 분산으로 모든 노드에 복사하면 브로드캐스트 조인 오버헤드를 줄입니다.

A) Scan 작업으로 FilterExpression 사용 B) Query 작업으로 KeyConditionExpression에 UserID와 OrderDate 범위 조건 C) GSI 생성 후 Query D) DynamoDB Streams + Lambda로 인덱스 유지

정답: B

설명: 기본 키의 파티션 키(UserID)와 정렬 키(OrderDate)를 사용한 Query는 가장 효율적입니다. KeyConditionExpression에서 UserID = :uid AND OrderDate >= :date 조건으로 특정 사용자의 특정 날짜 이후 주문을 효율적으로 조회합니다. Scan은 전체 테이블을 읽어 비효율적입니다.

A) 컴퓨팅과 스토리지를 독립적으로 확장하기 위해 B) 인메모리 캐싱으로 최고 쿼리 성능 달성 C) 자동으로 쿼리를 병렬 처리하기 위해 D) S3 데이터에 직접 접근하기 위해

정답: A

설명: Redshift RA3 노드는 컴퓨팅과 스토리지를 분리하여 독립적으로 확장할 수 있습니다. 자주 접근하는 데이터는 로컬 SSD 캐시에, 나머지는 S3 기반 Redshift Managed Storage(RMS)에 저장합니다. 데이터 증가에 따라 컴퓨팅 비용 증가 없이 스토리지만 확장 가능합니다.

A) 모든 데이터를 Hot 스토리지에 유지 B) Hot → UltraWarm → Cold 스토리지 계층 이동 C) 30일 이후 데이터는 S3로 내보내기 D) Index State Management로 30일 후 삭제

정답: B

설명: OpenSearch Service는 Hot(빠른 SSD, 자주 접근), UltraWarm(S3 기반, 비용 절감, 가끔 접근), Cold(더 저렴, 드물게 접근)의 스토리지 계층을 제공합니다. Index State Management(ISM)로 자동 계층 이동 정책을 설정하면 비용 최적화와 접근 패턴을 균형 있게 관리합니다.

A) 자동 파일 압축으로 스토리지 비용 절감 B) ACID 트랜잭션 지원과 자동 데이터 컴팩션 C) 실시간 스트리밍 데이터 수집 D) 열 수준 암호화 자동 적용

정답: B

설명: Lake Formation Governed Tables는 S3 데이터에 ACID 트랜잭션(원자성, 일관성, 격리성, 내구성)을 지원합니다. 동시 읽기/쓰기 작업에서 데이터 일관성을 보장하고, 자동 압축(compaction)으로 작은 파일 문제를 해결합니다. 행 수준 보안도 지원합니다.

A) S3 데이터를 CSV 형식으로 저장 B) S3 데이터를 Parquet 형식으로 저장하고 파티셔닝 적용 C) Redshift 클러스터 노드 수를 최대화 D) Spectrum 슬라이스당 파일 수를 1개로 제한

정답: B

설명: Redshift Spectrum은 Parquet나 ORC 같은 컬럼형 형식에서 최고 성능을 발휘합니다. 열 프루닝(필요한 열만 읽기)과 파티션 프루닝(필요한 파티션만 읽기)이 결합되면 스캔 데이터를 대폭 줄일 수 있습니다. CSV는 전체 파일을 읽어야 합니다.

A) 마스터, 코어, 태스크 노드 모두 Spot 사용 B) 마스터와 코어는 On-Demand, 태스크 노드만 Spot 사용 C) 마스터는 On-Demand, 코어와 태스크는 Spot 사용 D) 모든 노드를 Reserved 인스턴스로 구성

정답: B

설명: EMR에서 마스터 노드는 클러스터 관리를 담당하고, 코어 노드는 HDFS 데이터를 저장합니다. 마스터와 코어 노드는 On-Demand로 안정성을 보장하고, 태스크 노드(추가 컴퓨팅 전용)만 Spot으로 사용하면 Spot 중단 시 데이터 손실 없이 비용을 절감할 수 있습니다.

A) DynamicFrame은 스키마가 없어 모든 데이터 타입을 처리 B) DynamicFrame은 스키마 불일치(choice 타입)를 허용하고 relationalize 같은 AWS 전용 변환 제공 C) DataFrame이 항상 더 빠르므로 DynamicFrame은 사용하지 않는 것이 좋음 D) DynamicFrame은 구조화 스트리밍만 지원

정답: B

설명: AWS Glue DynamicFrame은 열 내에 여러 타입이 혼재하는 경우 choice 타입으로 표현합니다. resolveChoice(), relationalize() 같은 AWS 특화 변환 메서드를 제공합니다. 성능이 중요한 경우 DynamicFrame을 DataFrame으로 변환하여 처리 후 다시 DynamicFrame으로 변환할 수 있습니다.

A) Glue 크롤러를 매 1분마다 실행 B) Athena의 MSCK REPAIR TABLE 또는 ADD PARTITION 명령 사용 C) Lake Formation blueprints로 자동 파티션 관리 D) S3 이벤트 알림으로 Lambda를 통해 Glue 카탈로그 파티션 업데이트

정답: D

설명: S3 ObjectCreated 이벤트로 Lambda를 트리거하여 glue:BatchCreatePartition API를 호출하면 새 파티션만 효율적으로 추가됩니다. Athena의 MSCK REPAIR TABLE도 가능하지만 파티션이 많을수록 느립니다. Lambda를 통한 자동 파티션 등록이 가장 효율적입니다.

A) EMR Serverless는 영구적인 클러스터를 유지하고 EMR on EC2는 임시 클러스터 B) EMR Serverless는 클러스터 프로비저닝 없이 자동 스케일링되고 유휴 시 비용 발생 없음 C) EMR Serverless는 Hive만 지원하고 Spark는 지원하지 않음 D) EMR on EC2가 항상 더 비용 효율적

정답: B

설명: EMR Serverless는 클러스터를 직접 관리할 필요 없이 애플리케이션을 제출하면 자동으로 리소스를 프로비저닝합니다. 작업이 없을 때는 비용이 발생하지 않습니다. Spark, Hive 등을 지원하며, 간헐적인 배치 작업에 이상적입니다.

A) 대규모 분산 Spark ETL 처리 B) 코드 없는 시각적 데이터 준비 및 정제 C) 실시간 스트리밍 데이터 변환 D) 데이터 카탈로그 메타데이터 관리

정답: B

설명: AWS Glue DataBrew는 코드 작성 없이 시각적 인터페이스로 데이터를 탐색, 정제, 정규화할 수 있는 서비스입니다. 250개 이상의 사전 빌드된 변환을 제공하며, 데이터 품질 규칙 정의와 프로파일링도 지원합니다. 데이터 분석가나 데이터 사이언티스트에게 적합합니다.

A) Lambda 함수로 EMR 상태를 폴링하고 실패 시 재시작 B) Step Functions 상태 정의에 Retry 블록 추가 C) CloudWatch Alarm으로 EMR 실패 감지 후 SNS 알림 D) Glue Workflow로 EMR 작업을 래핑

정답: B

설명: Step Functions의 각 태스크 상태에 Retry 블록을 추가하면 지정된 오류 유형에 따라 자동 재시도합니다. 재시도 횟수, 재시도 간격, 백오프 비율을 설정할 수 있습니다. Catch 블록으로 최종 실패 시 대안 경로도 구성할 수 있습니다.

A) Glue 작업의 Worker 수를 줄임 B) coalesce() 또는 repartition()으로 출력 파티션 수 조절 후 쓰기 C) S3 Lifecycle 정책으로 작은 파일 자동 삭제 D) Kinesis Firehose로 파일 병합

정답: B

설명: Spark에서 coalesce(N)으로 파티션 수를 줄이거나 repartition(N)으로 균등하게 재분배한 후 쓰면 출력 파일 수를 제어할 수 있습니다. coalesce는 셔플 없이 파티션을 줄이지만 불균등할 수 있고, repartition은 균등하지만 셔플 비용이 발생합니다. 작은 파일 병합에는 coalesce가 일반적으로 적합합니다.

A) Lambda 함수의 메모리를 늘린다 B) 샤드당 병렬 처리(Parallelization Factor)를 늘린다 C) 배치 크기(Batch Size)를 줄인다 D) Lambda 예약 동시성을 늘린다

정답: B

설명: Kinesis-Lambda 이벤트 소스 매핑에서 Parallelization Factor(1~10)를 늘리면 각 샤드에서 동시에 여러 Lambda 호출이 처리됩니다. 기본값 1은 샤드당 1개의 동시 Lambda 실행입니다. Parallelization Factor 10으로 설정하면 동일 샤드에서 최대 10개의 Lambda가 병렬 실행됩니다.

A) Athena 쿼리 캐싱(Query Result Reuse) B) Athena 연합 쿼리(Federated Query) C) CTAS(Create Table As Select)로 결과 저장 D) Athena 워크그룹 쿼리 큐

정답: A

설명: Athena의 Query Result Reuse 기능을 활성화하면 동일한 쿼리에 대해 지정된 기간(최대 7일) 내 이전 결과를 재사용합니다. 스캔 비용이 발생하지 않아 반복 쿼리 비용을 크게 줄일 수 있습니다. 데이터가 변경되지 않는 경우에 효과적입니다.

A) 매시간 MSCK REPAIR TABLE 실행 B) Athena Partition Projection 설정 C) 매시간 ALTER TABLE ADD PARTITION 실행 D) Lake Formation으로 파티션 자동 관리

정답: B

설명: Athena Partition Projection을 사용하면 파티션 메타데이터를 Glue 카탈로그에 저장하지 않고 테이블 정의의 규칙으로 파티션을 동적으로 계산합니다. 규칙적인 패턴(날짜, 숫자 범위)의 파티션에 특히 효과적이며 파티션 등록 관리 오버헤드가 없습니다.

A) 두 테이블 모두 KEY 분산으로 조인 효율적 B) 한 테이블이 ALL 분산으로 모든 노드에 복사되어 조인 효율적 C) EVEN 분산으로 데이터 재분배 필요 D) 분산 키가 없어 브로드캐스트 조인 불가

정답: B

설명: DS_DIST_ALL_NONE은 조인의 한 테이블이 ALL 분산(모든 노드에 복사)으로 데이터 재분배(redistribution)가 필요 없음을 의미합니다. 이는 성능이 좋은 조인 패턴입니다. DS_DIST_ALL_INNER는 재분배 비용이 있음을 나타냅니다.

A) Direct Query 모드로 Redshift에 직접 연결 B) SPICE에 데이터 가져오기(Import) 후 예약 새로고침 설정 C) Athena를 통해 S3 데이터에 직접 쿼리 D) QuickSight Paginated Reports 사용

정답: B

설명: SPICE(Super-fast Parallel In-memory Calculation Engine)는 QuickSight의 인메모리 스토리지로 초고속 쿼리와 시각화를 지원합니다. 수억 행도 빠르게 처리합니다. 예약 새로고침으로 데이터를 주기적으로 업데이트할 수 있습니다. Direct Query는 실시간이지만 대용량에서 응답이 느릴 수 있습니다.

A) 클러스터에 노드를 추가 B) 짧은 쿼리 우선 처리(Short Query Acceleration) 활성화 C) 모든 쿼리에 동일한 우선순위 부여 D) 장시간 쿼리를 야간에만 실행 예약

정답: B

설명: Redshift의 Short Query Acceleration(SQA) 기능은 머신러닝을 사용하여 단시간 쿼리를 예측하고 별도 큐에서 우선 처리합니다. 별도 WLM 큐 설정 없이 간단하게 단/장시간 쿼리 혼재 환경을 최적화합니다. WLM 자동 큐로 추가 전환도 고려할 수 있습니다.

A) 각 영업 담당자마다 별도 데이터셋 생성 B) QuickSight RLS(Row-Level Security) 규칙을 데이터셋에 적용 C) IAM 정책으로 S3 데이터 접근 제한 D) Athena 뷰로 사용자별 데이터 필터링

정답: B

설명: QuickSight RLS는 사용자/그룹과 필터 값을 매핑한 규칙 파일(CSV 또는 다른 데이터셋)을 데이터셋에 연결합니다. 로그인한 사용자에 따라 자동으로 데이터가 필터링됩니다. 단일 데이터셋으로 여러 사용자에게 각자의 데이터만 표시할 수 있는 효율적인 방법입니다.

A) S3 데이터 레이크와 RDS, DynamoDB 등 이기종 데이터 소스를 단일 SQL로 조인 B) Redshift와 S3 데이터를 함께 쿼리 C) 여러 AWS 계정의 S3 버킷을 단일 쿼리로 처리 D) 실시간 스트리밍 데이터를 SQL로 분석

정답: A

설명: Athena Federated Query는 Lambda 기반 데이터 소스 커넥터를 사용하여 S3 이외의 데이터 소스(RDS, DynamoDB, ElastiCache, CloudWatch, Redis 등)에 SQL을 실행합니다. 여러 이기종 소스를 단일 쿼리에서 조인할 수 있어 데이터 통합 분석에 유용합니다.

A) Refresh Interval을 1초로 줄임 B) Bulk API 사용 및 Refresh Interval을 늘림 C) 각 문서마다 별도 Index API 호출 D) 샤드 수를 최대화

정답: B

설명: OpenSearch/Elasticsearch에서 대량 인덱싱 시 Bulk API로 여러 문서를 일괄 처리하면 네트워크 오버헤드를 줄입니다. Refresh Interval을 늘리면(기본 1초에서 30초 이상으로) 세그먼트 생성 빈도가 줄어 인덱싱 처리량이 크게 향상됩니다. 초기 대량 인덱싱 후 Refresh를 수동으로 호출하는 방법도 있습니다.

A) S3 버킷 정책만으로 세밀한 데이터 접근 제어 가능 B) Lake Formation 데이터 권한으로 테이블/열/행 수준 접근 제어 C) IAM 정책으로 Glue 카탈로그 접근 제어 D) S3 접근 포인트(Access Points)로 접두사별 접근 제어

정답: B

설명: Lake Formation은 Glue 데이터 카탈로그와 통합하여 논리적 테이블, 열, 행 수준의 세밀한 접근 제어를 제공합니다. 물리적 S3 파일 경로가 아닌 논리적 데이터 구조를 기반으로 권한을 부여합니다. S3 버킷 정책은 파일/접두사 수준만 제어 가능하여 열/행 수준 제어가 불가능합니다.

A) S3 서버 측 암호화(SSE-S3) 활성화 B) Kinesis 스트림에서 서버 측 암호화(SSE) 활성화 — AWS/kinesis KMS 키 선택 C) KMS 고객 관리 키(CMK) 생성 후 Kinesis에 연결 D) 클라이언트 측 암호화로 데이터 전송

정답: B

설명: Kinesis Data Streams는 서버 측 암호화(SSE)를 지원합니다. AWS 관리 키(aws/kinesis)를 선택하면 추가 설정 없이 모든 스트림 데이터가 KMS로 암호화됩니다. 고객 관리 키(CMK)를 사용하면 더 세밀한 키 정책 제어가 가능하지만 추가 구성이 필요합니다.

A) Redshift 클러스터에 퍼블릭 IP 할당 B) NAT Gateway를 통해 S3 접근 C) S3에 대한 VPC 엔드포인트(게이트웨이 엔드포인트) 구성 D) Direct Connect로 AWS 네트워크 연결

정답: C

설명: S3 게이트웨이 엔드포인트를 VPC에 구성하면 Redshift에서 S3로의 COPY/UNLOAD 작업이 AWS 프라이빗 네트워크를 통해 이루어집니다. 인터넷 게이트웨이나 NAT 게이트웨이 없이도 S3에 접근할 수 있어 보안이 강화되고 데이터 전송 비용도 절감됩니다.

A) S3 서버 측 암호화로 자동 처리됨 B) Glue 보안 구성(Security Configuration)에서 메타데이터 암호화 활성화 C) KMS 키를 Glue 카탈로그 테이블에 직접 연결 D) Lake Formation으로 메타데이터 접근 제어

정답: B

설명: AWS Glue Security Configuration에서 Glue 데이터 카탈로그 메타데이터 암호화를 활성화하면 KMS 키로 메타데이터를 암호화합니다. Glue ETL 작업의 데이터 암호화(전송 중, 저장 시), 작업 북마크 암호화도 Security Configuration에서 함께 설정합니다.

A) 분석 팀을 위해 PII 제거된 별도 S3 버킷 복사 유지 B) Lake Formation의 열 수준 보안 + S3 Object Lambda로 동적 마스킹 C) 분석 팀 IAM 역할에서 S3 버킷 전체 접근 거부 후 특정 접두사만 허용 D) Glue ETL로 매일 PII 제거된 데이터셋 생성

정답: B

설명: Lake Formation 열 수준 보안으로 PII 열을 차단하거나 S3 Object Lambda를 사용하면 데이터를 읽을 때 동적으로 PII를 마스킹할 수 있습니다. 이 방법은 원본 데이터를 복사하지 않아도 되고, 마스킹 로직을 중앙에서 관리할 수 있습니다.

A) CloudTrail로 Redshift API 호출 기록 B) Redshift 감사 로깅(Audit Logging)을 S3에 활성화 C) VPC Flow Logs로 Redshift 네트워크 트래픽 기록 D) CloudWatch Logs로 Redshift 연결 기록

정답: B

설명: Redshift 감사 로깅은 연결 로그, 사용자 활동 로그, 사용자 로그를 S3에 저장합니다. 사용자 활동 로그는 실행된 모든 SQL 쿼리를 기록합니다. 규정 준수 감사에 필요한 Who/What/When 정보를 완전히 제공합니다. CloudTrail은 Redshift API 호출만 기록합니다.

A) Kinesis Firehose → S3 → Athena (모든 요구사항 충족) B) Kinesis Data Streams → Lambda(실시간 사기탐지) + Firehose → S3(배치) + Glue + Redshift(리포트) C) MSK → Spark Streaming → DynamoDB D) SQS → Lambda → RDS → QuickSight

정답: B

설명: 실시간 처리(100ms)를 위해 Kinesis Data Streams에서 Lambda로 즉시 처리하고, 동시에 Firehose로 S3에 저장합니다. 배치 처리는 Glue ETL로 S3 데이터를 정제하고 Redshift에 로드하여 일별 리포트를 생성합니다. 3년 데이터는 S3 Intelligent-Tiering으로 비용 효율적으로 보관합니다.

A) S3 서버 측 암호화(KMS) 활성화 B) Redshift의 전송 중 암호화(SSL/TLS) 강제 C) CloudFront로 데이터 배포 D) 퍼블릭 S3 버킷에 데이터 저장 E) 암호화 없는 Kinesis 스트림 사용

정답: A, B

설명: HIPAA 준수를 위해 저장 시 암호화(S3 SSE-KMS)와 전송 중 암호화(SSL/TLS)가 필수입니다. 또한 VPC 내 배포, 접근 로깅, 감사 추적도 필요하지만 이 선택지에서는 A와 B가 핵심입니다. CloudFront는 배포 서비스로 HIPAA 요구사항과 직접 관련 없고, 퍼블릭 버킷과 암호화 없는 스트림은 위반입니다.

A) S3 DistCp로 데이터 복사, Glue 크롤러로 메타데이터 재생성 B) Snowball 가족으로 물리적 데이터 이전, SCT로 메타데이터 변환 C) AWS DataSync로 데이터 복사, Glue 카탈로그 import로 Hive 메타스토어 마이그레이션 D) DMS로 전체 마이그레이션

정답: C

설명: AWS DataSync는 온프레미스 HDFS에서 S3로 대용량 데이터를 효율적으로 전송합니다(병렬 전송, 자동 무결성 검증). Glue 카탈로그는 기존 Hive 메타스토어와 호환되며 import 기능으로 메타데이터를 마이그레이션할 수 있습니다. EMR은 기존 Hive 쿼리를 그대로 실행할 수 있습니다.

A) 파일 크기를 최소화하여 파일 수를 늘림 B) 파일 크기를 128MB~1GB로 최적화하여 분할 가능(splittable) 형식 유지 C) 압축을 비활성화하여 파일 읽기 속도 향상 D) 더 작은 파티션으로 세분화

정답: B

설명: Athena는 파일을 병렬로 읽을 때 각 파일을 분할합니다. Parquet 파일은 기본적으로 분할 가능하지만 최적 크기(128MB~1GB)로 유지해야 최대 병렬 처리가 가능합니다. 너무 작은 파일은 오버헤드를 늘리고, 너무 크면 병렬성이 감소합니다. Snappy나 ZSTD 압축을 함께 사용하는 것이 좋습니다.

A) Glue 작업의 실행 히스토리 추적 B) 이미 처리된 데이터를 추적하여 증분 처리 구현 C) Glue 작업의 비용 최적화 D) 데이터 품질 체크포인트 저장

정답: B

설명: Glue Job Bookmarks는 이전 실행에서 처리된 데이터를 추적합니다. 다음 실행 시 새로 추가된 데이터만 처리하여 중복 처리를 방지합니다. S3의 수정 시간과 파일 이름을 기반으로 처리 여부를 판단합니다. 전체 데이터 재처리 없이 효율적인 증분 ETL 파이프라인을 구현할 수 있습니다.

A) 모든 참조 데이터를 Flink 메모리에 로드 B) Flink Async I/O로 외부 데이터베이스에 비동기 조회 C) 참조 데이터를 Kinesis 스트림으로 전송하여 조인 D) Lambda 함수로 enrichment 후 Kinesis에 다시 전송

정답: B

설명: Flink Async I/O는 외부 데이터베이스(Redis, DynamoDB 등) 조회를 비동기로 처리하여 스트리밍 처리 지연을 최소화합니다. 동기 조회 시 외부 시스템 응답 대기로 처리량이 크게 떨어지지만, Async I/O는 여러 요청을 동시에 처리합니다. RocksDB State Backend와 함께 로컬 캐싱도 고려할 수 있습니다.

A) QuickSight 표준 사용자 계정을 각 외부 사용자에게 생성 B) QuickSight 임베디드 URL API + 익명 임베딩 또는 독자(Reader) 세션 C) QuickSight 공개 대시보드 링크 공유 D) S3에 대시보드 이미지를 내보내 웹에 표시

정답: B

설명: QuickSight 임베디드 분석 API를 사용하면 외부 사용자가 QuickSight 계정 없이도 대시보드를 볼 수 있습니다. 익명 임베딩(비인증 접근) 또는 독자 세션(한시적 URL)을 생성하여 웹 애플리케이션에 삽입합니다. 사용당 요금 모델이 적용됩니다.

A) 모든 레코드가 삭제됨 B) 처리 실패 레코드는 설정된 S3 접두사에 별도 저장 (처리 실패 접두사) C) Firehose가 자동으로 재시도 후 성공할 때까지 대기 D) 실패 레코드가 원본 소스로 반환됨

정답: B

설명: Kinesis Data Firehose Lambda 변환에서 실패한 레코드는 처리 실패(processing-failed) 접두사의 S3 경로에 저장됩니다. 성공한 레코드는 지정된 S3 대상에, 실패한 레코드는 별도 경로에 저장되어 나중에 재처리하거나 오류 분석에 활용할 수 있습니다.

A) 각 계정 S3 데이터를 중앙 계정으로 복사 B) Lake Formation 크로스 계정 데이터 공유 기능 사용 C) S3 크로스 계정 복제 설정 D) AWS Organizations SCP로 데이터 접근 통합

정답: B

설명: Lake Formation은 크로스 계정 데이터 공유를 지원합니다. 데이터 소유 계정에서 중앙 계정의 IAM 역할/사용자에게 Lake Formation 데이터 권한을 부여합니다. 중앙 계정에서 Athena나 Redshift Spectrum으로 다른 계정의 데이터 카탈로그를 쿼리할 수 있습니다. 데이터 이동 없이 중앙화된 거버넌스를 구현합니다.

A) Hive 쿼리를 자동으로 Spark로 변환 B) S3 데이터에 UPSERT/DELETE 및 증분 처리 지원 C) EMR 클러스터 자동 스케일링 D) HDFS와 S3 간 자동 데이터 동기화

정답: B

설명: Apache Hudi는 S3와 같은 데이터 레이크 스토리지에 UPSERT(삽입/업데이트), DELETE 작업을 지원하여 전통적인 데이터 레이크의 불변성 한계를 극복합니다. Copy-on-Write와 Merge-on-Read 테이블 타입을 제공하고, 증분 쿼리로 변경된 데이터만 효율적으로 처리할 수 있습니다.

A) Glue ETL 작업의 메모리 부족 문제 해결 B) 여러 데이터 소스의 데이터를 실시간으로 복제 및 통합하는 구체화된 뷰(Materialized View) 제공 C) Glue 크롤러의 스키마 탐지 오류 수정 D) Athena 쿼리 결과를 자동으로 캐싱

정답: B

설명: AWS Glue Elastic Views는 DynamoDB, Aurora, RDS 등의 소스 데이터를 OpenSearch, S3, Redshift 등 대상에 자동으로 복제하여 구체화된 뷰를 유지합니다. SQL 기반 뷰 정의로 복잡한 ETL 파이프라인 없이 데이터 통합을 구현합니다.

A) 모든 S3 작업을 자동으로 암호화 B) 접근 패턴을 자동으로 모니터링하여 비용 효율적인 스토리지 계층으로 자동 이동 C) S3 데이터에 대한 자동 백업 생성 D) 글로벌 데이터 복제 자동화

정답: B

설명: S3 Intelligent-Tiering은 접근 빈도를 모니터링하여 자주 접근하는 데이터는 Frequent Access, 30일 이상 미접근 데이터는 Infrequent Access, 90일 이상은 Archive Instant Access로 자동 이동합니다. 접근 패턴이 예측 불가능한 데이터 레이크에 특히 적합하며 모니터링 비용만 추가됩니다.

A) 불필요한 데이터베이스 연결 종료 B) 삭제/업데이트된 행을 정리하고 정렬 키 순서 재정렬 C) Redshift 클러스터 캐시 초기화 D) 테이블 통계 업데이트

정답: B

설명: Redshift VACUUM은 DELETE/UPDATE로 표시만 된 행을 실제로 제거하고 정렬 키 순서로 데이터를 재정렬합니다. 정기적인 VACUUM으로 스토리지를 회수하고 쿼리 성능을 유지합니다. ANALYZE는 테이블 통계를 업데이트합니다. Redshift Serverless와 최신 버전은 자동 VACUUM을 지원합니다.

A) 새 Consumer 그룹을 생성하면 처음부터 자동 재처리 B) GetShardIterator API에서 AT_TIMESTAMP 옵션으로 특정 시간부터 읽기 시작 C) Firehose를 통해 S3에서 재처리 D) 보존 기간 내 데이터를 새 스트림으로 복사

정답: B

설명: Kinesis GetShardIterator API의 ShardIteratorType을 AT_TIMESTAMP로 설정하고 원하는 타임스탬프를 지정하면 해당 시점부터 데이터를 읽을 수 있습니다. KCL(Kinesis Client Library)을 사용하는 경우 초기 위치를 타임스탬프로 설정할 수 있습니다.

A) 단일 메타데이터 레지스트리로 여러 분석 엔진 간 스키마 공유 및 일관성 유지 B) 데이터 처리 속도 향상 C) S3 저장 비용 절감 D) 자동 데이터 품질 검증

정답: A

설명: Glue 데이터 카탈로그는 AWS의 중앙 메타데이터 저장소입니다. Athena, Redshift Spectrum, EMR이 동일한 Glue 카탈로그를 참조하므로 테이블 정의, 파티션 정보, 스키마를 한 곳에서 관리합니다. 스키마 변경이 모든 분석 엔진에 자동 반영되어 일관성을 유지합니다.

A) CloudWatch Alarms로 S3 파일 크기 모니터링 B) AWS Glue Data Quality 규칙으로 자동 검증 C) Lambda로 수동 데이터 검증 스크립트 실행 D) SNS로 데이터 팀에 수동 검토 알림

정답: B

설명: AWS Glue Data Quality는 데이터셋에 품질 규칙(완전성, 유일성, 참조 무결성 등)을 정의하고 ETL 작업 중 자동으로 검증합니다. 품질 점수, 규칙 통과/실패 결과를 제공하며 CloudWatch와 통합하여 품질 저하 시 알림을 보낼 수 있습니다.

A) EMR on EC2보다 항상 비용이 저렴함 B) 기존 Kubernetes 인프라를 활용하여 Spark 작업을 실행하고 컨테이너 기반 워크로드 통합 C) HDFS 스토리지를 EKS 클러스터에 구성 가능 D) GPU 기반 딥러닝 전용

정답: B

설명: EMR on EKS는 기존 Amazon EKS 클러스터에서 Apache Spark를 실행합니다. Kubernetes 기반 인프라를 이미 사용하는 조직이 별도 EMR 클러스터 없이 데이터 처리 워크로드를 통합 관리할 수 있습니다. 컨테이너 격리, 리소스 공유, 기존 Kubernetes 도구(Helm, Argo Workflows 등) 통합이 이점입니다.

A) 클러스터 노드를 자동으로 추가하여 영구 확장 B) 쿼리 동시성이 최고점일 때 추가 클러스터 용량을 자동으로 프로비저닝하여 SLA 유지 C) Redshift 클러스터를 자동으로 업그레이드 D) 야간 일괄 처리를 자동으로 예약

정답: B

설명: Redshift Concurrency Scaling은 동시 쿼리 수가 증가하여 메인 클러스터가 포화 상태가 되면 추가 읽기 클러스터를 자동으로 시작합니다. 첫 24시간/일은 무료이며, 이후 초당 요금이 부과됩니다. 사용자는 지연 없이 일관된 쿼리 성능을 경험합니다.

A) 아니오, DMS가 스키마 변환을 자동으로 처리함 B) 예, Aurora MySQL과 Redshift는 다른 데이터베이스 엔진이므로 SCT로 스키마 변환 필요 C) 아니오, Aurora와 Redshift는 동일한 AWS 서비스이므로 불필요 D) SCT는 온프레미스 데이터베이스에서만 필요

정답: B

설명: DMS는 데이터 이동을 담당하고 SCT는 스키마(DDL, 프로시저, 함수 등) 변환을 담당합니다. Aurora MySQL(OLTP용)에서 Redshift(OLAP용)로의 이기종 마이그레이션은 데이터 타입, 테이블 구조 등의 변환이 필요하므로 SCT를 먼저 실행하여 Redshift 호환 DDL을 생성해야 합니다.

A) 각 팀에 별도 AWS 계정 생성 B) Athena 워크그룹(Workgroup)으로 팀별 쿼리 격리, 비용 추적, 데이터 사용량 제어 C) CloudWatch 비용 알림으로 팀별 예산 모니터링 D) IAM 태그로 쿼리 비용 추적

정답: B

설명: Athena 워크그룹은 팀/프로젝트별로 쿼리를 격리하고, 각 워크그룹의 쿼리 비용과 데이터 스캔량을 별도로 추적합니다. 워크그룹별 쿼리당 데이터 스캔 한도 설정, 결과 저장 위치 지정, CloudWatch 지표 통합이 가능합니다. 비용 할당 태그와 결합하여 팀별 비용 청구가 가능합니다.

A) 머신러닝 모델을 직접 훈련하고 배포 B) 시계열 데이터의 이상치, 예측, 자동 내러티브 생성 C) SageMaker 모델 결과를 QuickSight에 표시 D) A/B 테스트 결과 분석

정답: B

설명: QuickSight ML Insights는 코드 없이 시계열 이상치 탐지(Anomaly Detection), 판매 예측(Forecasting), 자동 내러티브(Auto-narratives) 기능을 제공합니다. Amazon Forecast와 Random Cut Forest 알고리즘을 내부적으로 사용하며, 데이터 사이언티스트 없이도 비즈니스 사용자가 ML 기반 인사이트를 얻을 수 있습니다.

A) 데이터 레이크 보안 정책 템플릿 B) 일반적인 데이터 소스(RDS, DMS 등)에서 S3 데이터 레이크로의 데이터 수집 워크플로 자동화 C) Glue ETL 작업 코드 자동 생성 D) QuickSight 대시보드 템플릿

정답: B

설명: Lake Formation Blueprints는 일반적인 데이터 수집 패턴(데이터베이스 스냅샷, 증분 데이터베이스, 로그 파일)에 대한 사전 구성된 워크플로를 제공합니다. 내부적으로 Glue 크롤러와 ETL 작업을 자동 생성하여 데이터 레이크 구축의 복잡성을 줄입니다.

A) Glue 작업을 Python Shell로 전환 B) groupFiles 옵션으로 작은 파일을 그룹화하고 Worker 수 증가 C) 데이터를 먼저 Redshift에 로드 후 Parquet로 언로드 D) Lambda 함수 체인으로 병렬 변환

정답: B

설명: Glue ETL의 groupFiles 설정으로 작은 파일들을 논리적으로 그룹화하여 처리 파티션 수를 최적화하고, Worker 수(DPU)를 늘려 병렬 처리를 향상시킵니다. Spark가 내부적으로 데이터를 병렬 파티션으로 처리하므로 충분한 DPU를 할당해야 병렬성이 활용됩니다.

A) CloudWatch 지표에서 CPUUtilization 확인 B) STL_QUERY, STL_EXPLAIN, SVL_QUERY_SUMMARY 시스템 테이블 분석 C) Redshift 감사 로그에서 쿼리 ID 검색 D) CloudTrail로 API 호출 추적

정답: B

설명: Redshift 시스템 테이블로 쿼리 성능을 분석합니다. STL_QUERY는 완료된 쿼리 정보, STL_EXPLAIN은 쿼리 계획, SVL_QUERY_SUMMARY는 각 단계별 실행 통계를 제공합니다. EXPLAIN 명령으로 실행 계획을 확인하고 데이터 분산, 조인 전략, 정렬 키 효율성을 분석합니다.

A) 두 조건 모두 충족되어야 S3에 데이터를 전송 B) 두 조건 중 먼저 충족되는 조건에 따라 S3에 데이터를 전송 C) Buffer Size만 기준으로 전송 D) Buffer Interval만 기준으로 전송

정답: B

설명: Kinesis Firehose는 Buffer Size(MB)와 Buffer Interval(초) 중 먼저 충족되는 조건에서 S3로 데이터를 전송합니다. 예를 들어 Buffer Size 5MB, Buffer Interval 60초 설정 시, 5MB가 쌓이거나 60초가 경과하면(먼저 도달하는 조건) 즉시 S3로 플러시합니다.

A) 테이블의 모든 읽기(Read) 작업 B) 테이블의 쓰기(Put, Update, Delete) 변경사항을 24시간 보존 C) 테이블 스캔 작업만 기록 D) GSI/LSI 생성 및 삭제 이벤트

정답: B

설명: DynamoDB Streams는 테이블의 항목 수준 변경사항(INSERT, MODIFY, REMOVE)을 캡처합니다. 변경 전/후 이미지를 최대 24시간 보존합니다. Lambda 트리거와 결합하여 이벤트 기반 아키텍처, 실시간 집계, 다른 시스템 동기화에 활용합니다.

A) 모든 데이터를 Redshift로 이동 후 분석 B) AWS Glue 카탈로그 + Athena 연합 쿼리 + Lake Formation 통합 거버넌스 C) 각 소스에 맞는 별도 분석 도구 사용 D) 모든 데이터를 DynamoDB로 통합

정답: B

설명: AWS Glue 카탈로그를 중앙 메타데이터 저장소로, Athena 연합 쿼리로 이기종 소스에 단일 SQL 실행, Lake Formation으로 통합 보안 및 거버넌스를 구현하는 것이 가장 포괄적인 솔루션입니다. 데이터 이동 없이 현재 위치에서 분석하고, 단일 접근 제어 정책을 적용할 수 있습니다.