실전 문제

문제 1

한 대도시 교통 당국은 도시 전역의 버스 및 경전철 네트워크를 운영하며, 6개의 독립 시스템(배차, 차량 텔레매틱스, 요금 수납, 정비, 역 제어, 사고 관리)에 걸친 다단계 운영 워크플로를 사용한다. 각 시스템은 최신 운행 상태를 기록하는 JDBC 호환 관계형 데이터베이스(MySQL 및 PostgreSQL 혼합)를 백엔드로 사용한다. 당국은 관제 센터가 전체 워크플로 전반에서 모든 차량의 운행 상태를 시간 단위로 가시화(신선도 ≤ 15분, 전체 시스템 합산 분당 약 5,000행 업데이트)하여 추적할 수 있어야 하며, 개발 노력을 최소화하면서 보고를 위해 다른 AWS Region에 데이터를 중앙화해야 한다. 이러한 요구 사항을 가장 적은 개발 오버헤드로 충족하는 솔루션은 무엇인가?

문제 분석

핵심 개념: 이 문제는 최소한의 개발 노력으로 여러 JDBC relational source에서 거의 실시간에 가까운 cross-Region change data capture (CDC)를 테스트합니다. 핵심 managed service는 AWS Database Migration Service (AWS DMS)이며, CDC를 사용해 업데이트를 지속적으로 복제하고, 운영 보고를 위해 빠른 upsert와 간단한 aggregation을 지원하는 low-ops 대상 저장소를 사용합니다. 정답인 이유: 요구 사항은 시간 단위 가시성, freshness ≤ 15분, 그리고 서로 독립적인 6개의 MySQL/PostgreSQL 시스템에서 분당 약 5,000건의 row update를 다른 AWS Region에 중앙 집중화하는 것입니다. AWS DMS는 database transaction log (CDC)를 읽고 낮은 지연 시간과 최소한의 custom code로 지속적인 변경 사항을 복제하도록 특별히 설계되었습니다. DMS는 여러 source를 단일 target(또는 여러 table)으로 통합할 수 있으며, Amazon DynamoDB에 쓸 수 있습니다. DynamoDB는 높은 write rate와 key 기반 access pattern(예: vehicleId+tripId)에 매우 적합하여 “latest trip state”를 유지하는 데 적합합니다. Amazon QuickSight를 사용하면 custom visualization stack을 구축하는 것보다 적은 dashboard 개발로 “reporting” 요구 사항을 충족할 수 있는 managed BI service를 활용할 수 있습니다. 주요 AWS 기능: - AWS DMS CDC: MySQL binlog와 PostgreSQL WAL을 사용하여 inserts/updates/deletes를 지속적으로 캡처합니다. - Cross-Region replication: target Region에서 DMS replication instance를 실행하고 network connectivity (VPN/Direct Connect/peering)를 통해 source에 연결하여 reporting이 수행되는 위치로 데이터를 중앙 집중화합니다. - “current state” 저장소로서의 DynamoDB: 높은 처리량, 낮은 지연 시간, 그리고 latest-state tracking을 위한 간단한 upsert semantics를 제공합니다. - QuickSight: Managed dashboard를 제공하며, reporting을 위한 운영 오버헤드를 최소화하기 위해 지원되는 connector/approach(일반적으로 Athena/Glue catalog 또는 기타 지원되는 ingestion pattern)를 통해 DynamoDB와 통합됩니다. 흔한 오해: - “ingestion”에 AWS Glue를 선택하고 싶을 수 있지만, Glue job은 일반적으로 batch/micro-batch ETL이며 6개의 OLTP 시스템 전반에서 일관된 ≤15분 freshness를 달성하려면 더 많은 custom development와 운영 튜닝이 필요합니다. - Redshift는 analytics에 매우 뛰어나지만, 여러 OLTP source로부터의 지속적인 CDC ingestion에는 일반적으로 추가 구성 요소(streaming ingestion pattern, staging, MERGE logic)가 필요하여 개발 노력이 증가합니다. - Grafana는 time-series/ops metrics에 강하지만, 요구 사항은 최소한의 노력으로 중앙 집중식 reporting을 구현하는 것입니다. business reporting에는 일반적으로 QuickSight가 더 적합한 managed BI 선택입니다. 시험 팁: “JDBC relational source + changed record + near-real-time + minimal development”를 보면 AWS DMS CDC를 떠올리세요. 높은 update rate에서 “latest state” 운영 뷰가 필요하다면, warehouse에 복잡한 MERGE pipeline을 구축하는 것보다 DynamoDB가 더 나은 low-ops target인 경우가 많습니다. 최소한의 오버헤드로 “reporting dashboard”를 구현하려면, 일반적으로 self-managed visualization stack보다 QuickSight가 선호됩니다.

문제 2

(2개 선택)

한 스트리밍 미디어 회사는 5개 AWS Region에 걸쳐 6개의 프로덕션 스튜디오를 운영하고 있으며, 각 스튜디오의 컴플라이언스 팀은 서로 다른 IAM role을 사용합니다. 또한 모든 원본 자막 파일과 QC 로그는 aws_region으로 파티셔닝된 단일 Amazon S3 data lake에 통합되어 있습니다(예: s3://media-lake/raw/aws_region=eu-central-1/). 데이터 엔지니어링 팀은 운영 오버헤드를 최소화하고 새 bucket을 만들거나 데이터를 중복하지 않으면서, 각 스튜디오가 Amazon Athena 같은 서비스를 통해 자신의 Region에 해당하는 레코드만 쿼리할 수 있도록 보장해야 합니다. 팀이 수행해야 할 단계 조합은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 Athena로 쿼리되는 S3 기반 data lake에 대해 AWS Lake Formation 거버넌스를 적용하는 것을 평가하며, 특히 데이터를 중복하거나 새 bucket을 만들지 않고 data filter(행/열 수준 보안)를 사용한 fine-grained access control(FGAC)을 다룹니다. 정답이 맞는 이유: 각 스튜디오를 자신의 Region 파티션(aws_region=...)으로만 제한하려면, 데이터 엔지니어링 팀은 Lake Formation을 사용해 공유 table에 대한 액세스를 중앙에서 거버닝해야 합니다. 먼저 데이터가 들어 있는 S3 bucket/prefix를 Lake Formation data location으로 등록해야 Lake Formation이 service-linked role을 통해 권한을 강제하고(또는 “data location permissions”를 통해) 액세스를 관리할 수 있습니다. 다음으로 FGAC를 활성화하고 Region 기반 data filter(예: filter expression aws_region = 'eu-central-1')를 생성한 뒤, 각 스튜디오의 IAM role에 해당 data filter를 사용하여 table 권한을 부여합니다. 이렇게 하면 Athena 쿼리 결과가 해당 Region의 행만 반환되며, 운영 오버헤드는 최소이고 데이터 중복도 없습니다. 주요 AWS 기능 및 구성: - Lake Formation data locations: data lake에서 사용하는 S3 bucket/prefix를 등록하여 Lake Formation이 기본 object에 대한 액세스를 제어할 수 있게 합니다. - Data filters(LF-Tags/data filters): data filter는 거버닝되는 table에 대해 행 수준 및 열 수준 필터링을 제공합니다. 파티셔닝된 데이터의 경우 filter를 통해 특정 파티션(예: aws_region)으로 액세스를 효과적으로 제한할 수 있습니다. - IAM principal에 대한 grant: 각 스튜디오의 IAM role에 Lake Formation 권한(SELECT, DESCRIBE 등)을 부여하되, data filter 범위로 제한합니다. - Athena 통합: Athena는 거버닝되는 table을 쿼리할 때 Glue Data Catalog/Lake Formation 권한을 사용하므로, role별 S3 policy가 아니라 중앙 거버넌스를 구현할 수 있습니다. 흔한 오해: A는 data filter와 prefix를 언급해 그럴듯하지만, “data filter를 사용해 prefix를 data location으로 등록”은 서로 다른 두 개의 개념을 섞은 것입니다. data filter는 S3 location을 등록하지 않습니다. C는 data filter를 IAM role에 연결하는 방식이 아니므로 틀립니다. E는 제약(새 bucket/중복 금지)을 위반하며, 쿼리 시점 FGAC가 아니라 거친(granular하지 않은) S3 prefix policy로 거버넌스를 옮기는 것입니다. 시험 팁: “단일 S3 data lake”, “Athena”, “각 팀이 행/파티션의 일부만 볼 수 있어야 함”을 보면, Lake Formation FGAC(data filters 또는 LF-Tags)와 S3 data location 등록을 떠올리세요. 또한 IAM은 누가 서비스를 호출할 수 있는지를 제어하고, Lake Formation은 data lake에서 무엇을 볼 수 있는지를 제어한다는 점을 기억하세요.

문제 3

(2개 선택)

미디어 스트리밍 스타트업이 하루에 약 3 TB의 원시 clickstream 로그를 Amazon S3에 적재하고, 선별된 집계 데이터를 Amazon Redshift RA3 cluster로 로드하며, 분석가들은 또한 AWS Glue Data Catalog에 의해 백업되는 external schema를 사용하여 Amazon Redshift Spectrum을 통해 가장 최신의 S3 데이터에 대해 낮은 지연 시간의 ad hoc query를 실행해야 합니다. 대부분의 필터가 event_date(YYYY-MM-DD)와 region에 적용되고 팀이 가장 빠른 Spectrum query 성능을 원한다면, 어떤 두 가지 조치를 취해야 합니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 AWS Glue Data Catalog를 사용하는 external schema를 통해 Amazon S3의 데이터를 직접 쿼리할 때 Amazon Redshift Spectrum 성능 최적화를 테스트합니다. Spectrum은 predicate를 S3/Glue metadata로 pushdown하고 S3 object를 스캔하며, 성능은 얼마나 많은 데이터를 읽어야 하는지와 얼마나 효율적으로 읽을 수 있는지에 의해 좌우됩니다. 정답이 맞는 이유: (B) S3 데이터를 columnar format(Parquet/ORC)으로 변환하는 것은 Spectrum에 대한 가장 영향이 큰 최적화 중 하나입니다. Columnar format은 데이터를 column 단위로 저장하고 통계(예: row group별 min/max)를 포함하여 predicate pushdown과 관련 없는 block을 건너뛰는 것을 가능하게 합니다. 일반적인 ad hoc analytics가 일부 column을 선택하고 event_date/region으로 필터링하는 경우, Spectrum은 row-based text format보다 훨씬 적은 byte를 읽습니다. (C) event_date와 region으로 partitioning하면 물리적 레이아웃과 Glue partition metadata가 가장 일반적인 WHERE predicate와 정렬됩니다. Spectrum은 Glue catalog를 사용해 partition을 pruning하여, 매칭되지 않는 partition의 object를 스캔하지 않고도 전체 partition을 제외할 수 있으므로, “가장 최신 데이터” 쿼리의 S3 I/O와 지연 시간을 크게 줄입니다. 주요 AWS 기능 / 모범 사례: - AWS Glue Data Catalog partition을 사용하는 Redshift Spectrum partition pruning. - Parquet/ORC를 통한 predicate pushdown 및 column pruning. - S3 data lake 레이아웃: Hive-style partitioning을 위한 s3://bucket/path/event_date=YYYY-MM-DD/region=.../. - small-file 문제를 피하고, 더 적고 더 큰 파일을 선호(Parquet의 경우 종종 100–1000+ MB)하여 S3 request overhead를 줄이고 scan 효율을 향상. 흔한 오해: 많은 작은 파일로 “더 많은 parallelism”을 얻으면 속도가 빨라진다고 생각하기 쉽지만, Spectrum과 S3 request overhead 때문에 작은 파일은 더 느리고 더 비쌉니다. 또 다른 함정은 CSV에 GZIP을 사용하는 것입니다. 저장되는 byte는 줄일 수 있지만, 일반적으로 non-splittable이라 효율적인 parallel read와 predicate 기반 건너뛰기를 방해하여 query latency를 악화시키는 경우가 많습니다. 시험 팁: Spectrum/Athena 스타일 엔진에서 가장 빠른 쿼리는 보통 (1) 자주 사용하는 필터 기준으로 partitioning하고 (2) splittable compression을 사용하는 columnar format을 선택할 때 나옵니다. date와 region에 대한 빈번한 필터가 보이면 해당 key로 partitioning을 선택하세요. ad hoc analytics가 일부 column만 선택하는 경우 Parquet/ORC를 선택하세요.

문제 4

(2개 선택)

AWS 계정 111122223333의 한 재무 분석가가 us-east-1에서 Amazon QuickSight Enterprise 대시보드를 열고, Amazon Athena를 통해 Amazon S3 버킷 s3://city-traffic-logs-2025(200 GB, 날짜 파티션됨)의 데이터를 쿼리하고 쿼리 결과를 s3://athena-results-prod-002에 기록하여 두 개의 데이터셋을 새로 고칩니다. 두 버킷은 모두 계정 444455556666이 소유하고 있으며 객체는 customer-managed AWS KMS key alias/traffic-cmk-01로 암호화되어 있습니다. 새로 고침을 시도하자 분석가는 'Insufficient permissions' 오류를 받았습니다. 이러한 권한 관련 오류를 유발할 수 있는 요인은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념 - 테스트되는 주요 AWS 서비스/개념: 이 문제는 Amazon QuickSight + Amazon Athena를 사용해 Amazon S3의 데이터를 분석하는 cross-account 액세스와, 관련된 2계층 권한 모델을 테스트합니다: (1) S3 객체(및 Athena 쿼리 결과)에 대한 data-plane 액세스, (2) 해당 객체를 암호화하는 customer-managed key(CMK)에 대한 AWS KMS 권한. cross-account 구성에서는 IAM/service role과 리소스 정책(S3 bucket policy, KMS key policy)이 모두 일치해야 합니다. 정답이 맞는 이유: A가 정답인 이유는 QuickSight가(서비스 role 및 Athena 통합을 통해) s3://city-traffic-logs-2025의 소스 데이터를 읽어야 하고, s3://athena-results-prod-002의 Athena 출력 파일도 읽어야 하기 때문입니다. QuickSight service role(또는 QuickSight를 대신해 Athena가 사용하는 role)에 s3:GetObject(그리고 일반적으로 관련 prefix에 대한 s3:ListBucket)가 없으면 새로 고침이 “Insufficient permissions”로 실패합니다. 특히 cross-account에서는 계정 444455556666의 bucket policy가 111122223333의 QuickSight 관련 principal을 명시적으로 허용해야 합니다. D가 정답인 이유는 S3 권한이 있더라도 CMK로 암호화된 객체는 KMS 권한이 필요하기 때문입니다. QuickSight/Athena는 CMK를 사용할 수 있어야 하며(읽기에는 kms:Decrypt, Athena 결과 쓰기에는 보통 kms:Encrypt/kms:GenerateDataKey도 필요), cross-account에서는 KMS key policy(및 IAM policy)가 외부 principal을 허용하지 않으면 액세스가 거부되어 데이터셋 새로 고침 중 권한 오류로 나타납니다. 주요 AWS 기능 / 구성: - 데이터 및 Athena 결과에 대한 cross-account 액세스를 위한 S3 bucket policy(ListBucket/GetObject; prefix 범위 지정). - kms:Decrypt(및 Athena 결과의 경우 kms:Encrypt/GenerateDataKey도) 권한을 위한 KMS CMK key policy + IAM 권한. - Athena는 output location이 필요하며, QuickSight 새로 고침은 해당 결과를 읽습니다. 흔한 오해: 파티셔닝(B)은 성능/비용 및 쿼리 계획에 영향을 주지만 권한과는 무관합니다. SPICE vs Direct Query(C)는 데이터가 저장/쿼리되는 위치를 바꾸지만, 새로 고침은 여전히 S3/Athena 및 KMS에 대한 액세스가 필요합니다. workgroup 선택(E)은 강제 설정(예: output location/암호화)에 영향을 줄 수 있지만, “wg-prod vs primary” 자체만으로는 권한 오류가 아닙니다. 시험 팁: S3 + KMS에서 “Insufficient permissions”를 보면 항상 두 계층을 모두 확인하세요: S3 작업 권한과 KMS key policy/IAM. Athena/QuickSight의 경우 권한을 부여해야 하는 S3 위치가 두 곳(소스 데이터 버킷과 Athena 쿼리 결과 버킷)이며, 두 위치의 CMK 암호화 객체에 대한 KMS 권한도 필요하다는 점을 기억하세요.

문제 5

미디어 분석 회사가 Amazon S3에 900TB의 이벤트 로그를 저장하고 Amazon Athena를 사용해 비즈니스 리포팅 대시보드를 구동하고 있습니다. AWS Glue 작업이 24시간마다 한 번(UTC 02:00)에 데이터를 컴팩션하고 새 데이터를 기록합니다. 회사 정책은 SLA를 충족하기 위해 대시보드가 15분마다 새로 고침되어야 한다고 요구합니다. 데이터 엔지니어링 팀은 새로운 인프라를 추가하지 않고 운영 오버헤드를 최소화하면서 Athena 비용을 줄이려 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

한 미디어 분석 회사가 온프레미스 Kafka 클러스터(브로커 3개, 파티션 24개, 평균 ingest 약 2 MB/s이며 최대 12 MB/s까지 버스트, 메시지 50 KB)와 온프레미스 MySQL에서 Debezium을 통해 방출되는 증분 CDC 업데이트를 처리하는 consumer 애플리케이션을 AWS로 lift-and-shift할 계획이다. 또한 팀은 운영 관리가 최소화되면서 Kafka API를 보존하고 자동 스케일링을 유지하는 replatform(리팩터링 아님) 전략을 고수한다. 이러한 요구 사항을 가장 적은 관리 오버헤드로 충족하는 AWS 서비스 선택은 무엇인가?

문제 분석

핵심 개념: 이 문제는 replatform(리팩터링 아님) 접근 방식에서 워크로드가 Kafka 프로토콜/API 호환성, 최소 운영 관리, 자동 스케일링을 요구할 때 관리형 스트리밍 ingest 서비스를 선택하는지를 평가한다. 정답이 맞는 이유: Amazon MSK Serverless가 최적의 선택인 이유는 Apache Kafka API(producer/consumer, topic/partition, consumer group)를 그대로 보존하면서 대부분의 클러스터 관리 작업(용량 계획, 브로커 사이징, 패치, 스케일링 작업)을 제거하기 때문이다. 회사는 Kafka 클러스터와 이미 Kafka를 사용하는 CDC consumer(Debezium이 Kafka topic으로 emit)를 lift-and-shift하고 있다. MSK Serverless로 replatform하면 애플리케이션과 Debezium 통합 패턴을 거의 변경하지 않으면서 “최소 운영 관리”와 “자동 스케일링” 요구 사항을 충족한다. ingest 프로파일(평균 약 2 MB/s, 최대 약 12 MB/s 버스트, 50 KB 메시지)은 일반적인 MSK Serverless의 탄력적 처리량 기대치 범위 내에 있으며, serverless는 사용량에 따라 읽기/쓰기 처리량과 스토리지를 자동으로 확장한다. 주요 AWS 기능: MSK Serverless는 Kafka 호환 엔드포인트, IAM 기반 인증(또는 구성에 따라 SASL/SCRAM), 전송 중 및 저장 시 암호화, 브로커 인스턴스를 관리하지 않고도 용량을 자동 확장하는 기능을 제공한다. Amazon CloudWatch와 통합되어 메트릭과 로깅을 제공하며, 일반적인 Kafka 툴링을 지원한다. CDC의 경우 Debezium은 Kafka topic으로 계속 produce할 수 있고, consumer는 Kafka client library와 consumer group 시맨틱을 계속 사용할 수 있다. 흔한 오해: Kinesis Data Streams와 Firehose는 “관리형 스트리밍”으로 자주 선택되지만, Kafka API/시맨틱을 노출하지 않기 때문에(partition vs shard, offset, consumer group이 다름) 리팩터링이 필요하다. MSK provisioned는 Kafka API를 보존하지만, 브로커 사이징, 스케일링 이벤트 관리, 용량 계획이 필요하므로 “자동 스케일링과 최소 관리 오버헤드” 요구 사항을 serverless만큼 강하게 충족하지 못한다. 시험 팁: “Kakfa API 보존”과 “최소 운영”이 보이면 MSK를 떠올려라. 또한 “자동 스케일링”과 “최소 관리”가 함께 요구되면 provisioned MSK보다 MSK Serverless를 우선하라. Kinesis는 API 변경/리팩터링이 허용되거나 Kinesis 네이티브 ingest/처리 패턴을 명시적으로 요구할 때만 선택하라.

문제 7

미디어 분석 회사는 200개 이상의 예약된 데이터 파이프라인을 위한 워크플로 오케스트레이터가 필요합니다. 이 파이프라인은 온프레미스 Kubernetes 클러스터(워커 노드 3대, 각 32 vCPU)와 us-east-1의 AWS 계정 전반에서 실행되며, 두 위치 모두에서 동일한 오픈 소스 DAG 정의를 사용해야 하고, 벤더 종속을 피해야 하며, 하루 최소 500회 이상의 task 실행을 지원해야 합니다. 팀이 온프레미스에서는 오픈 소스 엔진을 실행하고 클라우드에서는 완전 관리형 동등 서비스를 사용할 수 있도록 채택해야 할 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 온프레미스와 완전 관리형 AWS 서비스 모두에서 실행할 수 있는 오픈 소스 DAG 엔진을 사용하여 예약된 데이터 파이프라인을 위한 워크플로 오케스트레이션을 테스트합니다. 핵심은 이식성(동일한 DAG 정의), 벤더 종속 회피, 그리고 운영 확장성입니다. 정답이 맞는 이유: Amazon Managed Workflows for Apache Airflow (MWAA)는 Apache Airflow를 위한 AWS의 완전 관리형 서비스입니다. Airflow는 오픈 소스이며 온프레미스에서 Kubernetes에 배포되는 경우가 흔합니다. Airflow DAG를 표준으로 삼으면 회사는 동일한 DAG 코드를 두 곳에서 실행할 수 있습니다: (1) 온프레미스 Kubernetes 클러스터에서 자체 관리 Airflow, (2) us-east-1의 MWAA. 이는 “두 위치에서 동일한 오픈 소스 DAG 정의” 및 “온프레미스에서 오픈 소스 엔진을 실행하고 클라우드에서 완전 관리형 동등 서비스를 실행” 요구사항을 직접 충족합니다. 또한 MWAA는 하루 500회 이상의 task 실행을 훨씬 상회하는 일반적인 엔터프라이즈 스케줄링/오케스트레이션 요구를 지원합니다. 주요 AWS 기능: MWAA는 Airflow 컨트롤 플레인(scheduler, web server, workers)을 관리하고 IAM, VPC 네트워킹, CloudWatch logs/metrics, DAG/plugins/requirements를 위한 S3, 암호화를 위한 KMS를 통해 AWS 서비스와 통합됩니다. 또한 워커 용량 확장(environment class/worker scaling)을 지원하고 운영 부담(패치, 업그레이드, 고가용성)을 줄여줍니다. 하이브리드 패턴에서는 팀이 종종 DAG를 공유 repo에 두고 CI/CD를 통해 온프레미스 Airflow와 MWAA의 S3 DAG bucket에 배포합니다. 흔한 오해: AWS Glue는 관리형 ETL 서비스이며 workflows/triggers를 포함하지만, 온프레미스 오케스트레이터와 “동일한 오픈 소스 엔진”이 아니고 Glue를 온프레미스에서 네이티브로 실행할 수도 없습니다. Amazon SWF는 AWS 네이티브 워크플로 서비스(Airflow 호환 아님)로 DAG 로직을 다시 작성해야 하므로 종속성이 증가합니다. AWS Data Exchange는 서드파티 데이터셋 구독을 위한 서비스이지 오케스트레이션이 아닙니다. 시험 팁: “DAGs”, “Airflow”, “avoid vendor lock-in”, “managed equivalent in AWS”가 보이면 MWAA를 떠올리세요. 문제가 오케스트레이션 코드의 하이브리드 이식성을 강조한다면, 리팩터링이 필요한 AWS 네이티브 워크플로 엔진보다 오픈 소스 호환 관리형 서비스를 우선하세요.

문제 8

한 핀테크 스타트업은 us-east-1 및 eu-west-1에서 Amazon API Gateway (Regional)로 12개의 public REST API를 실행하고 있으며, custom domain이 있는 단일 Amazon CloudFront distribution 뒤에 두고 있습니다. 회사는 모든 클라이언트 연결에 대해 TLS 1.2+를 강제해야 하며, 최소 60일마다 zero-downtime certificate renewal이 필요합니다. 한 data engineer는 SSL/TLS certificate의 발급, 배포, rotation을 단순화하고, 운영 오버헤드를 최소화하면서 두 Region 전반에 걸쳐 자동으로 갱신 및 배포하는 솔루션을 구현해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Amazon CloudFront를 사용한 edge-terminated HTTPS에 대해 중앙 집중식 TLS certificate lifecycle management를 테스트하며, CloudFront와 함께 AWS Certificate Manager (ACM)를 올바르게 사용하는지를 묻습니다. 또한 CloudFront에서 ACM certificates에 대한 regional requirement와 ACM이 zero downtime으로 renewal을 처리하는 방식도 암묵적으로 테스트합니다. 정답인 이유: 모든 client connection이 CloudFront에서 종료되므로(사용자 지정 도메인이 있는 단일 distribution), 클라이언트에 대해 TLS 1.2+를 강제하는 데 중요한 certificate는 CloudFront viewer certificate입니다. CloudFront용 public certificate를 발급, 배포, 교체하는 가장 운영 부담이 적은 방법은 ACM입니다. CloudFront의 경우 ACM certificate는 us-east-1 (N. Virginia)에 있어야 합니다. distribution에 연결되면 ACM은 적격한 public certificate를 자동으로 갱신하고, CloudFront는 downtime이나 수동 재배포 없이 갱신된 certificate를 자동으로 사용합니다. 이는 “zero-downtime renewals”와 “least operational overhead” 요구 사항을 직접 충족합니다. 주요 AWS 기능: (1) ACM public certificates: 무료이며 관리형 발급 및 갱신을 제공합니다. (2) CloudFront viewer certificate integration: 사용자 지정 도메인에 대해 ACM cert(반드시 us-east-1)를 distribution에 연결합니다. (3) Security policy: 규정 준수 요구 사항을 충족하기 위해 CloudFront가 TLS 1.2+를 강제하도록 구성합니다(예: TLSv1.2_2021 이상). (4) Automatic renewal: ACM은 만료 전에 갱신합니다(정확히 60일 주기는 아님). 그래도 갱신이 자동으로 이루어지고 정책상 필요하면 짧은 유효 기간으로 발급할 수 있으므로 “at least every 60 days” 요구를 충족합니다. 운영 측면에서 ACM이 의도된 관리형 접근 방식입니다. 흔한 오해: 많은 사람들은 certificate를 각 Region의 모든 API Gateway Regional endpoint에 배포해야 한다고 생각합니다. 그러나 앞단에 CloudFront가 있으면 client-facing cert는 API Gateway가 아니라 CloudFront에 있습니다. 또 다른 함정은 cert를 여러 Region에 “복사”해야 한다고 생각하는 것입니다. 하지만 viewer certificate에 대한 CloudFront의 특별한 us-east-1 requirement 때문에 cross-Region 배포는 필요하지 않습니다. 시험 팁: “CloudFront + custom domain + least operational overhead”를 보면 기본적으로 ACM-managed public certificates를 떠올리세요. 규칙을 기억하세요: CloudFront는 us-east-1의 ACM certificates를 요구합니다. 또한 “viewer-side TLS”(CloudFront와 client 간)와 “origin TLS”(CloudFront와 API Gateway 간)를 구분하세요. 이 둘은 독립적으로 처리할 수 있습니다.

문제 9

스트리밍 분석 스타트업이 4-노드 Amazon Redshift RA3 (ra3.4xlarge) 클러스터를 운영하며, 230개 컬럼을 가진 비정규화된 이벤트 테이블을 모델링해야 합니다. 이 테이블은 9개월 내 300 GB에서 3 TB로 증가할 것으로 예상되며, 안정적인 조인 컬럼이나 distribution key로 적합한 균일하게 높은 cardinality 필드가 없습니다. 테이블이 확장됨에 따라 지속적인 유지보수를 최소화하려면 어떤 distribution style을 선택해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon Redshift 테이블 distribution style과 확장 가능한 성능을 위해 최소한의 운영 오버헤드로 이를 선택하는 방법을 평가합니다. Distribution은 행이 compute node/slice 전반에 어떻게 배치되는지를 결정하며, 조인 성능, 데이터 skew, 그리고 데이터가 증가할 때의 유지보수에 영향을 줍니다. 정답이 맞는 이유: 테이블은 300 GB에서 3 TB로 성장하는 크고 비정규화된 이벤트 테이블이며, 프롬프트에서 DISTKEY에 적합한 안정적인 조인 컬럼 또는 균일하게 높은 cardinality 필드가 없다고 명시합니다. 이런 상황에서는 수동 KEY distribution(스큐 위험 및 향후 재작업)과 ALL distribution(데이터를 모든 노드에 복제하므로 테이블이 커질수록 비현실적)을 피하는 것이 모범 사례입니다. RA3에서는 Redshift가 테이블 크기와 사용 패턴에 따라 distribution style(예: 작은 dimension 테이블에 대해 EVEN 또는 ALL)을 선택하고 조정할 수 있는 AUTO distribution을 지원합니다. 요구사항이 “테이블이 확장될 때 지속적인 유지보수를 최소화”하는 것이므로, AUTO가 가장 부합합니다. 테이블이 커지고 쿼리 패턴이 진화함에 따라 DISTSTYLE 결정을 다시 검토할 필요를 줄여줍니다. 주요 AWS 기능/모범 사례: DISTSTYLE AUTO는 Redshift가 distribution 선택을 자동으로 관리하도록 합니다. 이는 명확한 distkey가 없거나 워크로드가 변하는 경우 특히 유용합니다. RA3는 managed storage를 통해 compute와 storage를 분리하지만, distribution은 조인 및 집계 중 네트워크 재분배에 여전히 영향을 줍니다. AUTO는 수동 튜닝의 반복을 피하도록 돕고, 확신이 없거나 Redshift가 최적화하도록 하려는 경우 AUTO를 사용하라는 Redshift 가이드와 일치합니다. 흔한 오해: 적절한 distkey가 없을 때 EVEN이 자주 권장되지만, 이는 여전히 수동으로 고정된 선택이며 테이블이 커지거나 다른 테이블/쿼리가 변하면 최적이 아닐 수 있습니다. ALL은 조인 속도 측면에서 매력적으로 보일 수 있지만, 수 TB 규모의 fact/event 테이블이 아니라 작은 lookup/dimension 테이블에만 적합합니다. 시험 팁: 문제가 “최소 유지보수”, “알 수 없거나 불안정한 조인 키”, 또는 “진화하는 워크로드”를 강조하면 DISTSTYLE AUTO를 우선 선택하십시오. ALL은 작고 자주 조인되는 dimension 테이블에만 사용하십시오. KEY는 일반적인 조인과 정렬되며 skew를 유발하지 않는 안정적인 high-cardinality 키가 있을 때만 사용하십시오.

문제 10

한 바이오테크 기업이 lab-data-prd-042라는 이름의 Amazon S3 bucket에 마스킹된 실험실 보고서를 저장하고, AWS IAM Identity Center를 통해 5개 팀이 assume하는 IAM roles를 사용하여 엄격한 access policy를 적용하고 있습니다. 이 기업은 policy를 위반하여 어떤 사용자가 s3://lab-data-prd-042/restricted/ prefix에서 GetObject 또는 PutObject를 수행할 때마다 정확한 username을 포함하는 거의 실시간(3분 미만) 알림이 필요합니다. 다음 중 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Amazon S3 object-level access에 대한 감사(auditing)와 거의 실시간 알림을 테스트하며, 특히 policy에 의해 access가 거부될 때 정확한 human user를 식별(attribution)하는 것을 요구합니다. 올바른 도구 조합은 AWS CloudTrail S3 data events(object-level API activity)와 Amazon CloudWatch Logs/EventBridge로의 거의 실시간 전달을 통한 알림입니다. 정답이 맞는 이유: AWS CloudTrail은 특정 bucket, 심지어 특정 prefix(restricted/)에 대해 GetObject 및 PutObject에 대한 S3 data events를 기록할 수 있습니다. 이러한 events에는 identity context(userIdentity)가 포함되며, IAM Identity Center로 federated된 sessions의 경우 일반적으로 assumed role session 세부 정보와 원본 사용자(예: session name 및/또는 설정에 따라 principal tags)가 포함됩니다. CloudTrail events를 CloudWatch Logs로 전송(또는 EventBridge를 통해 라우팅)하면, 해당 prefix에서 AccessDenied/Unauthorized 작업을 매칭하는 metric filters 또는 event rules를 생성하여 몇 분 내에 alarm/notification을 트리거할 수 있으므로 3분 미만 요구 사항을 충족합니다. 주요 AWS 기능 / 구성 방법: 1) bucket lab-data-prd-042에 대해 CloudTrail data events를 활성화하고 restricted/ prefix로 범위를 제한합니다(advanced event selectors). 필요에 따라 management events를 포함할 수 있으나, GetObject/PutObject에는 data events가 필수입니다. 2) 낮은 지연 시간 처리를 위해 CloudTrail을 CloudWatch Logs로 전달(또는 EventBridge integration 사용)합니다. 3) eventName이 [GetObject, PutObject]이고, resources에 restricted/ prefix가 포함되며, errorCode가 AccessDenied인 이벤트를 매칭하는 CloudWatch Logs metric filter(또는 EventBridge rule)를 생성합니다. SNS, PagerDuty 등으로 트리거합니다. 4) Identity Center sessions가 사용자 attribution을 보존하도록 보장합니다: role session name 매핑 및/또는 principal tags를 사용하여 alert payload에 정확한 username이 포함되도록 이벤트에 해당 정보가 들어가게 합니다. 흔한 오해: AWS Config는 개별 API call이 아니라 resource configuration compliance를 평가하므로, username을 포함한 요청 단위 policy 위반을 감지할 수 없습니다. CloudWatch S3 metrics는 집계(aggregate) 데이터이며 사용자 identity를 요청 단위로 제공하지 않습니다. S3 server access logs는 지연(종종 수 시간)이 발생하므로 3분 미만 알림에는 적합하지 않습니다. 시험 팁: S3 objects에 대한 “누가 무엇을 했는지”(GetObject/PutObject)가 필요하면 CloudTrail data events를 떠올리십시오. 거의 실시간 알림이 필요하면 CloudTrail을 CloudWatch Logs metric filters 또는 EventBridge rules와 결합하십시오. 정확한 username이 요구되면, 집계 metrics나 지연된 access logs에 의존하지 말고 federated/assumed-role sessions에서 identity context(session name/principal tags)를 캡처하도록 구성해야 합니다.

문제 11

데이터 엔지니어가 us-west-2에서 Amazon Athena 쿼리를 실행하여 Amazon S3 버킷(s3://prod-logs-2024)을 가리키는 Glue Data Catalog 테이블을 조회하고 있다. 이 버킷에는 128-MB Parquet 파일이 고객 관리형 AWS KMS 키(alias/prod-logs-key)로 암호화되어 있으며, 쿼리에 사용된 IAM role에는 버킷에 대한 s3:ListBucket 및 s3:GetObject 권한이 있음에도 객체를 읽는 동안 AccessDenied로 쿼리가 실패한다. 가장 가능성이 높은 원인은 무엇인가?

문제 12

미디어 분석 스타트업이 온프레미스 Oracle 12c 데이터베이스를 1 Gbps Direct Connect 링크를 통해 AWS에 연결해 운영하고 있으며, 데이터 엔지니어는 JDBC를 통해 특정 테이블(~5천만 행, 30개 컬럼)을 크롤링하여 스키마를 카탈로그화한 다음, 데이터를 추출, 변환, 적재하여 Amazon S3 버킷에 파티셔닝된 Parquet(Snappy)로 매일 01:00 UTC 일정에 맞춰 저장해야 합니다. 또한 비용을 낮게 유지하기 위해 관리형 서비스 오버헤드를 최소화하면서 엔드투엔드 파이프라인을 오케스트레이션해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 AWS 서비스 또는 기능은 무엇입니까?

문제 분석

핵심 개념: 요구 사항은 JDBC를 통해 온프레미스 Oracle 테이블을 크롤링하고, 스키마를 카탈로그화하고, 데이터를 변환한 뒤, 이를 partitioned Parquet 형식으로 Amazon S3에 적재하는 일일 ETL 파이프라인을 위한 낮은 오버헤드와 비용 효율적인 orchestration 메커니즘입니다. 이 파이프라인은 Glue crawler 및 Glue ETL job과 같은 AWS Glue 구성 요소를 중심으로 자연스럽게 구성되므로, 가장 적절한 orchestration 기능은 AWS Glue workflows입니다. 정답인 이유: AWS Glue workflows는 Glue crawlers, Glue jobs, 그리고 triggers를 관리형 serverless 방식으로 orchestration하도록 특별히 설계되었습니다. 하루 한 번 실행되는 ETL 프로세스의 경우, Glue workflows는 별도의 orchestration 플랫폼 없이도 기본적인 dependency 처리, scheduling, retries, 그리고 status tracking을 제공합니다. 따라서 파이프라인이 이미 JDBC ingestion 및 스키마 cataloging을 위해 Glue를 중심으로 구축되어 있을 때 운영 오버헤드와 비용을 모두 낮게 유지할 수 있습니다. 주요 기능: Glue workflows는 crawler와 ETL job을 함께 연결할 수 있고, scheduled 또는 conditional triggers를 사용할 수 있으며, AWS Glue Data Catalog와 직접 통합됩니다. Glue는 Direct Connect를 통해 온프레미스 Oracle 데이터베이스에 대한 JDBC connections를 지원하고, Glue jobs는 Snappy compression이 적용된 partitioned Parquet를 S3에 쓸 수 있습니다. 따라서 Glue workflows는 추가 orchestration 서비스를 도입하는 대신 전체 파이프라인에 일관되게 잘 맞는 선택입니다. 흔한 오해: Step Functions는 강력한 범용 orchestrator이지만, 워크플로가 주로 Glue-native이고 crawler와 ETL job orchestration이 필요한 경우에는 가장 자연스럽거나 비용 효율적인 답은 아닙니다. Glue Studio는 시각적 authoring 인터페이스일 뿐이며, orchestration 메커니즘 자체는 아닙니다. MWAA는 단순한 일일 관리형 ETL 파이프라인에 비해 운영 부담과 비용이 훨씬 큽니다. 시험 팁: 문제에서 데이터 소스 크롤링, 스키마 cataloging, JDBC ingestion, 그리고 S3로의 ETL을 명시적으로 언급하면 먼저 AWS Glue를 떠올리세요. orchestration이 주로 Glue-native 구성 요소 간에 이루어진다면, 보통 Glue workflows가 가장 좋은 답입니다. Step Functions는 Glue가 더 큰 orchestration 패턴의 한 부분일 뿐인 더 광범위한 multi-service 워크플로에 사용하도록 구분하세요.

문제 13

데이터 엔지니어는 주거용 smart-meter 측정값을 처리하는 smart-utility analytics pipeline을 최적화해야 하며, Apache Parquet 파일이 매일 s3://utility-raw/consumption/ prefix 아래의 Amazon S3 bucket으로 전달됩니다. 매주 월요일 팀은 여러 기간(최근 7일, 30일, 180일)에 대해 reading_date로 필터링된 KPI를 계산하기 위해 ad hoc SQL을 실행합니다. 데이터셋은 현재 하루 약 15 GB씩 증가하며 1년 내에 하루 60 GB에 도달할 것으로 예상됩니다. 솔루션은 데이터 볼륨이 증가하더라도 query 성능이 저하되지 않도록 방지하면서 가장 cost-effective해야 합니다. 어떤 접근 방식이 이러한 요구 사항을 가장 cost-effectively 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS Glue Data Catalog를 통한 partitioning과 함께 serverless query engine(Amazon Athena)을 사용하여 Amazon S3에서 데이터를 cost-effectively 확장 가능하게 query하는 방법을 테스트합니다. 핵심 아키텍처 원칙은 데이터셋이 커질수록 query당 scan되는 데이터를 최소화하는 것입니다. 정답이 맞는 이유: 주간 KPI는 rolling window(7/30/180일)로 reading_date를 기준으로 필터링됩니다. Parquet 데이터셋을 reading_date(예: consumption/reading_date=YYYY-MM-DD/)로 partitioning하면 partition pruning이 가능해져, Athena가 전체 테이블을 scan하는 대신 date predicate와 일치하는 partition만 읽습니다. 일일 볼륨이 15 GB/day에서 60 GB/day로 증가하더라도, partition pruning은 전체 누적 데이터에 비례하여 query 성능과 비용이 선형적으로 악화되는 것을 방지합니다. Athena는 pay-per-query(스캔된 TB 기준)이므로, scan되는 바이트를 줄이는 것이 곧 가장 cost-effective한 접근입니다. 주요 AWS 기능: 1) Parquet + Athena: columnar Parquet는 column projection과 predicate pushdown을 통해 이미 scan 크기를 줄이며, partition과 결합하면 매우 효율적입니다. 2) AWS Glue Data Catalog: Athena가 사용하는 table/partition metadata를 저장합니다. Glue Crawlers, MSCK REPAIR TABLE, 또는 partition projection(대규모에서 수백만 partition 관리를 피하기 위해 종종 최선)을 통해 partition을 추가할 수 있습니다. 3) Partition 설계: ingestion_date가 아니라 reading_date(쿼리 필터)를 사용합니다. 필요하다면 partition 수를 제한하기 위해 year/month/day 같은 hierarchical partition을 고려합니다. 흔한 오해: Redshift는 빠른 SQL을 실행할 수 있지만, 항상 켜져 있는 cluster/serverless 비용과 데이터 loading/maintenance가 추가됩니다. S3 데이터에 대해 주 1회 ad hoc query를 실행하는 경우 Athena가 일반적으로 더 저렴합니다. EMR/Spark는 강력하지만 운영 부담이 크고 단순 SQL KPI에는 cost-effective하지 않습니다. Aurora는 S3의 Parquet에 대한 대규모 분석 scan에 적합하지 않으며 relational schema로 ETL/loading이 필요합니다. 시험 팁: 쿼리가 반복적으로 특정 필드(여기서는 reading_date)로 필터링된다면 그 필드로 partitioning하세요. S3 data lake에서 ad hoc SQL을 위한 가장 cost-effective한 패턴은 종종 partition pruning(및 필요 시 partition projection)과 함께 S3 + Parquet + Glue Catalog + Athena를 사용하여 데이터 증가에 따른 비용과 성능을 제어하는 것입니다.

문제 14

한 리테일 분석 팀이 Amazon S3 curated bucket에 쓰는 AWS Glue ETL job으로 시간당 약 300만 건의 point-of-sale 이벤트를 처리하고 있으며, 사용자들이 오전 7:00 일일 대시보드에서 데이터 누락을 보고하고 있다. 따라서 데이터 엔지니어는 데이터가 S3에 기록되기 전 transform 단계에서 (1) 8개의 필수 column 중 어느 하나라도 null 값을 포함하면 run을 실패 처리하고 (2) fact order 레코드(OrderId, CustomerId)와 AWS Glue Data Catalog에 등록된 일일 customer snapshot 간 referential integrity를 강제하는 자동화된 data quality check를, 운영 오버헤드를 최소화하여 추가해야 한다. 어떤 솔루션을 선택해야 하는가?

문제 분석

핵심 개념: 이 문제는 운영 오버헤드를 최소화하면서 ETL 중에 AWS Glue 네이티브 방식으로 data quality를 강제하는지를 평가한다. 핵심 기능은 Amazon S3에 curated data를 쓰기 전에 Glue job의 일부로 rule을 정의하고 실행하며 그 결과에 따라 동작할 수 있는 AWS Glue Data Quality(즉, Evaluate Data Quality transform)이다. 정답이 맞는 이유: 옵션 B는 Evaluate Data Quality transform을 사용하는 AWS Glue ETL job으로 (1) 8개의 필수 column 전반에 completeness(비-null)를 강제하고 (2) fact orders dataset과 AWS Glue Data Catalog에 등록된 customer snapshot table 간 referential integrity를 검증한다. 이는 transform 단계에서 check를 추가하고 rule 위반 시 run을 실패 처리해야 한다는 요구사항과 정확히 일치한다. customer snapshot이 Data Catalog에 있으므로, Glue는 custom validation code를 구축/유지하지 않고도 무결성 check를 위한 governed되고 discoverable한 dataset으로 이를 참조할 수 있다. 주요 AWS 기능: Evaluate Data Quality는 IsComplete(필수 column용) 및 ReferentialIntegrity(소스 dataset의 key가 참조 dataset에 존재하는지 보장) 같은 rule set을 지원한다. Glue Studio/Glue ETL script에 통합되며, 결과/metric을 publish할 수 있고, rule 결과에 따라 job failure 동작을 지원한다. 이 접근은 check를 표준화하고 bespoke 로직을 줄이며 quality 결과를 관측 가능하게 만들어 AWS Well-Architected의 operational excellence와도 부합한다. 흔한 오해: SageMaker Data Wrangler(A/D)는 data preparation과 quality profiling에 자주 연관되지만, 주로 interactive/ML 지향 workflow를 위해 설계되었고 Glue 중심 ETL pipeline에 추가 component(flow, processing job)를 도입하여 운영 오버헤드를 증가시킨다. Custom SQL/PySpark check(C)도 가능하지만, 지속적인 유지보수, edge case의 신중한 처리, 추가 개발/테스트가 필요해 managed rule 기반 transform보다 운영 부담이 크다. 시험 팁: 문제가 “least operational overhead”를 요구하고 pipeline이 이미 Glue에 있다면, custom code보다 Glue 네이티브 managed transform/feature를 우선하라. 또한 요구사항에 Data Catalog table과 integrity constraint가 명시되어 있다면, join과 null check를 수동으로 구현하기보다 Glue Data Quality rule(예: IsComplete, ReferentialIntegrity)을 찾아라.

문제 15

한 fintech 회사가 결제 이벤트 로그를 12개 shard가 있는 Amazon Kinesis Data Streams data stream으로 스트리밍하고 있습니다. 각 record는 2 KB이며 producer는 전체적으로 초당 약 5,000개의 record를 전송하지만, CloudWatch에서는 두 개 shard가 95% write utilization을 보이는 반면 다른 shard들은 10% 미만입니다. 또한 해당 hot shard들에 대해 PutRecords 호출이 ProvisionedThroughputExceeded를 반환합니다. Producer는 현재 merchantId를 partition key로 사용하고 있으며, flash sale 동안 단일 merchant가 이벤트의 약 70%를 생성하여 stream의 aggregate limit 미만의 총 throughput임에도 hot shard가 발생합니다. 동일한 전체 throughput을 유지하면서 throttling을 제거하려면 data engineer는 어떻게 해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon Kinesis Data Streams의 shard 단위 throughput과 partition key가 shard 할당을 어떻게 결정하는지 테스트합니다. 각 record는 partition key를 hashing하여 shard로 라우팅되므로, key 분포가 불균등하면 stream의 총(aggregate) capacity가 충분하더라도 “hot shard”가 발생합니다. 정답이 맞는 이유: 12개 shard가 있는 stream은 aggregate write capacity가 충분하지만, 한 merchant가 이벤트의 ~70%를 생성합니다. Producer가 merchantId를 partition key로 사용하기 때문에 대부분의 record가 동일한 shard(들)로 hash되어 해당 shard의 write utilization이 ~95%까지 올라가 ProvisionedThroughputExceeded가 발생합니다. 해결책은 hot merchant의 이벤트가 여러 shard로 퍼지도록 partition-key cardinality를 높이는 것입니다. 일반적인 패턴은 논리적 grouping을 위해 merchantId를 유지하되 random 또는 deterministic suffix(예: merchantId + “-” + (hash(eventId) % 128))를 추가하여 record가 shard 전반에 분산되도록 하면서 동일한 전체 throughput을 유지하는 것입니다. 주요 AWS 기능: Kinesis Data Streams는 shard당 limit(일반적으로 write 기준 1 MB/s 또는 1,000 records/s)를 강제합니다. shard가 어느 limit이든 초과하면 PutRecords가 throttling됩니다. Partition key가 분산을 제어하며, Kinesis는 hot key를 shard 간에 자동으로 rebalance하지 않습니다. 기법으로는 random suffix 추가, 더 높은 cardinality key(eventId) 사용, 또는(적절한 경우) explicit hash key 사용으로 라우팅을 제어하는 방법이 있습니다. 흔한 오해: “shard만 추가하면 된다”(옵션 B)고 생각하기 쉽습니다. 하지만 partition key가 merchantId로 그대로라면 hot merchant는 여전히 제한된 일부 shard로 hash되며, resharding은 총 capacity를 늘릴 뿐 hot key가 분산된다는 보장은 없습니다. 또 다른 오해는 record 크기를 줄이면(옵션 D) throttling이 해결된다는 것입니다. 그러나 hot shard는 MB/s가 충분하더라도 records/s limit(1,000 records/s)에 걸릴 수 있습니다. Producer를 throttling하는 것(옵션 C)은 throughput을 낮추므로 요구사항을 만족하지 못합니다. 시험 팁: 일부 shard만 hot이고 나머지가 idle이면 partition-key skew를 의심해야 합니다. 올바른 해결책은 shard scaling보다는 거의 항상 partition key 전략 변경(cardinality 증가 / salting 추가)입니다. 또한 shard limit 두 가지(MB/s와 records/s)를 모두 확인하세요. 작은 record는 종종 records/s limit에 먼저 도달합니다.

문제 16

한 연구 조직이 로그와 CSV 데이터셋을 저장하는 공유 Amazon S3 데이터 레이크에 대해 Amazon Athena로 일회성, 임시 SQL 쿼리를 실행합니다. 동일한 AWS 계정 내에서 8개의 제품 팀, 2개의 데이터 사이언스 샌드박스, 3개의 내부 애플리케이션이 모두 쿼리를 실행합니다. 조직은 동일한 S3 bucket을 계속 사용하면서도 각 팀 또는 애플리케이션이 자기 것만 보고 관리할 수 있도록 쿼리 실행 리소스, 비용, 저장된 쿼리, 쿼리 기록을 엄격하게 격리해야 합니다. 권한은 IAM 및 리소스 tag 조건으로 강제되어야 하며, S3 데이터 복제는 허용되지 않습니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Athena workgroup, IAM 권한 부여, tag 기반 액세스 제어(ABAC)를 사용한 Amazon Athena 멀티 테넌트 거버넌스를 테스트합니다. Workgroup은 동일한 AWS 계정 내에서 공유 S3 데이터를 계속 쿼리하면서도 쿼리 실행 설정, 쿼리 기록, 저장된 쿼리를 격리하기 위한 Athena의 주요 리소스입니다. 정답이 맞는 이유: 팀/애플리케이션별 전용 Athena workgroup을 생성하면 (1) 쿼리 실행 리소스 및 설정(예: 엔진 버전, 결과 구성, 스캔 바이트 제한), (2) 비용 귀속 및 제어(workgroup별 CloudWatch metric 및 선택적 bytes-scanned 제한), (3) 해당 workgroup 범위로 제한되는 저장된 쿼리 및 쿼리 기록 가시성을 엄격히 격리할 수 있습니다. 각 workgroup에 tag(예: Team=TeamA)를 지정하고 리소스 tag 조건(aws:ResourceTag/Team) 및/또는 principal tag(aws:PrincipalTag/Team)를 사용하는 IAM policy를 적용하면, principal이 자신의 workgroup에서만 쿼리를 시작하고, 쿼리를 나열하며, 저장된 쿼리를 관리하도록 강제할 수 있습니다. 이는 S3 데이터를 복제하지 않으면서 IAM 및 리소스 tag 조건으로 권한을 강제해야 한다는 요구 사항을 충족합니다. 주요 AWS 기능: - Athena Workgroups: 쿼리 실행 구성, 쿼리 기록, 저장된 쿼리를 위한 격리 경계 - IAM + ABAC: "athena:WorkGroup" 같은 조건과 리소스 tagging 조건(aws:ResourceTag/*)을 사용하여 특정 workgroup에 대한 액세스를 제한 - 비용 제어: workgroup별 데이터 스캔 제한(bytes) 및 중앙화된 결과 구성, 그리고 tag를 통한 비용 할당 - 공유 S3 데이터 레이크는 변경되지 않으며, 쿼리 작업의 거버넌스만 격리됨 흔한 오해: S3 bucket으로 격리(옵션 A)하고 싶을 수 있지만, 문제는 데이터 복제를 금지하고 동일한 bucket을 계속 사용해야 한다고 명시합니다. 또 다른 오해는 Glue Data Catalog 권한만으로(옵션 D) Athena 쿼리 기록/비용을 격리할 수 있다는 것인데, 그렇지 않습니다. Glue는 메타데이터/table 액세스를 관리할 뿐 Athena 운영 아티팩트는 관리하지 않습니다. IAM role(옵션 C)은 인증/권한 부여에 도움이 되지만, workgroup과 결합하지 않으면 Athena 쿼리 기록/저장된 쿼리에 대한 격리 경계를 본질적으로 제공하지 않습니다. 시험 팁: 동일 계정 내 여러 내부 테넌트 간에 Athena 쿼리 기록, 저장된 쿼리, 비용을 격리해야 한다는 요구 사항이 보이면 “Athena workgroups + IAM/ABAC”를 떠올리십시오. tag와 IAM 조건을 사용해 테넌트별 액세스를 강제하고, Glue policy는 데이터/메타데이터 액세스를 위한 것이지 Athena 운영 격리를 위한 것이 아님을 기억하십시오.

문제 17

미디어 플랫폼이 PostgreSQL database에 저장된 재생 로그를 분석해야 합니다. 회사는 Zendesk에서 추적되는 고객 이슈와 로그를 상관 분석하려고 합니다. 회사는 매일 2 GB의 새로운 재생 로그를 수신합니다. 회사는 100 GB의 과거 Zendesk 티켓을 보유하고 있습니다. 데이터 엔지니어는 로그와 티켓을 분석하고 상관 분석하는 프로세스를 개발해야 합니다. 프로세스는 매일 밤 한 번 실행되어야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 매일 밤 실행되는 상관 분석 작업을 위한, 운영 부담이 가장 낮은 serverless 배치 수집 + ETL/오케스트레이션 패턴을 선택하는지를 평가합니다. 여기서의 주요 managed services는 Amazon AppFlow(SaaS 수집), AWS Glue(managed Spark ETL 및 JDBC 수집), AWS Step Functions(serverless 오케스트레이션)입니다. 정답이 맞는 이유: 옵션 C는 운영해야 할 인프라를 최소화하는 목적 특화 managed services를 사용합니다. AppFlow는 Zendesk에 기본적으로 연결되며, 스케줄에 따라 100 GB의 과거 티켓(이후에는 증분 업데이트)을 Amazon S3로 적재할 수 있습니다. AWS Glue는 JDBC를 통해 PostgreSQL에서 재생 로그를 추출할 수 있으며(일반적으로 DB가 위치한 VPC/subnet/security group에 대한 Glue connection 사용), Zendesk 데이터세트와의 상관 분석 조인을 수행하고 정제된 결과를 S3(또는 warehouse)로 기록할 수 있습니다. Step Functions는 야간 실행을 오케스트레이션합니다: AppFlow 트리거(또는 AppFlow 스케줄링에 의존), Glue job 시작, 재시도/타임아웃 처리, 성공/실패 알림 게시. 주요 AWS 기능: - Amazon AppFlow: managed SaaS 수집, 스케줄링, (지원되는 경우) 증분 pull, S3로 직접 전달; 커스텀 API 코드 필요를 줄임. - AWS Glue: managed ETL, Glue Data Catalog, 증분 처리를 위한 job bookmarks(2 GB/일 로그에 유용), 데이터세트 상관 분석을 위한 확장 가능한 Spark join. - Step Functions: 내장 재시도, 오류 처리, service integrations를 갖춘 serverless workflow; Airflow environment를 운영하는 것보다 운영 부담이 낮음. 흔한 오해: - Airflow(MWAA)는 “managed”이지만 여전히 environment sizing, dependency 관리, DAG 운영, 지속적인 튜닝이 필요하며, 단순한 야간 파이프라인에서는 Step Functions보다 오버헤드가 더 큰 경우가 많습니다. - Kinesis/Flink는 streaming 상관 분석에 매력적이지만, 요구 사항은 1일 1회 야간 배치입니다. streaming은 불필요한 복잡성과 비용을 추가합니다. 시험 팁: “least operational overhead”와 단순한 스케줄 기반 workflow가 보이면, 완전한 serverless 오케스트레이션(Step Functions)과 managed 수집/ETL(AppFlow/Glue)을 우선 고려하십시오. MWAA는 복잡한 DAG 생태계, 많은 task/operator, 또는 Airflow 고유 기능이 필요한 경우에 사용하십시오. 워크로드가 명시적으로 배치인 경우 streaming services는 피하십시오. (참고: AWS Well-Architected Framework—Operational Excellence pillar; Amazon AppFlow, AWS Glue, AWS Step Functions의 managed integrations 및 오케스트레이션 관련 서비스 문서.)

문제 18

실시간 물류 플랫폼이 운영 오버헤드를 줄이기 위해 자체 관리형 Hadoop ecosystem에서 AWS로 마이그레이션하고 있으며, 가능한 경우 serverless에 관심이 있습니다. 기존 파이프라인은 Apache Spark, Apache Flink, Apache HBase, Oozie workflows를 사용하고, 매일 3.5 PB의 데이터를 변환하며, 개별 ETL 실행은 90초 이내에 완료되어야 합니다. 따라서 마이그레이션 후에도 이러한 프레임워크를 계속 사용하면서 동일하거나 더 나은 성능을 유지해야 합니다— 이러한 요구 사항을 가장 잘 충족하는 AWS extract, transform, and load (ETL) 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 특정 open-source big data frameworks(Spark, Flink, HBase, Oozie)를 계속 사용해야 하고, 극단적인 처리량/지연 시간 요구 사항을 충족해야 하는 상황에서 적절한 AWS-managed ETL/analytics 서비스를 선택하는지를 평가합니다. 정답이 맞는 이유: Amazon EMR이 가장 적합한 이유는 Apache Spark, Apache Flink, Apache HBase, Apache Oozie를 포함한 Hadoop ecosystem을 최소한의 운영 오버헤드로 실행하도록 설계된 AWS 서비스이면서, 프레임워크 호환성을 유지할 수 있기 때문입니다. “이 프레임워크를 계속 사용”해야 한다는 요구 사항이 핵심 판별 요소입니다. AWS Glue는 serverless ETL이지만 managed HBase 또는 Oozie를 제공하지 않으며, Glue의 실행 모델은 해당 구성 요소들을 그대로 사용하면서 하루 수 PB 규모에서 90초 미만의 초저지연 ETL을 수행하도록 의도된 것이 아닙니다. EMR은 적절한 instance family, storage(예: shuffle을 위한 instance store), scaling 전략을 통해 고성능으로 튜닝할 수 있습니다. 주요 AWS 기능: EMR은 batch/stream processing을 위한 Spark 및 Flink, HDFS/S3-backed 패턴에서 low-latency NoSQL을 위한 HBase, workflow scheduling을 위한 Oozie를 지원합니다. EMR managed scaling, auto scaling, EMR on EKS(Kubernetes 운영 활용), EMR Serverless for Spark를 통해 ops overhead를 줄일 수 있습니다(참고: EMR Serverless는 HBase/Oozie 같은 전체 세트를 커버하지 않으므로 classic EMR/EMR on EKS가 전제됩니다). 성능을 위해 Graviton/compute-optimized instances를 사용하고, Spark executors를 튜닝하며, shuffle을 위해 ephemeral NVMe를 활용하고, source/target 데이터를 Amazon S3에 저장하면서 EMRFS를 사용하십시오. 또한 partitioning과 columnar formats(Parquet/ORC)를 사용해 엄격한 SLA를 충족하십시오. 흔한 오해: “가능한 경우 serverless”라는 문구 때문에 Glue 또는 Lambda를 선택하도록 오도될 수 있습니다. 그러나 HBase와 Oozie 호환성 요구와 극단적인 SLA는 EMR을 강하게 시사합니다. Redshift는 data warehouse이지, 이러한 프레임워크를 위한 범용 ETL runtime이 아닙니다. 시험 팁: 문제에서 Hadoop ecosystem 구성 요소(HBase, Oozie)를 명시하고 이를 계속 사용해야 한다고 하면 기본적으로 Amazon EMR을 선택하십시오. 워크로드가 주로 Spark 기반 ETL이고 AWS-native orchestration이며 HBase/Oozie 같은 Hadoop daemons 요구가 없다면 Glue를 선택하십시오.

문제 19

미디어 분석 스타트업이 하루 약 200GB의 JSON clickstream 파일을 Amazon S3 landing bucket으로 수집하고 있으며, 파일을 추출하고 5가지 데이터 품질 검사(null 검사, 범위 검증, referential lookup)를 적용하고, 변환(column pruning 및 type casting)을 수행한 뒤, 향후 SQL 쿼리를 위해 처리된 데이터셋을 단일 Amazon RDS for MySQL 인스턴스에 저장하는 일일 스케줄 파이프라인이 필요합니다. 또한 90일 동안 상세한 품질 검사 결과 로그를 저비용 스토리지에 보관해야 합니다. 이러한 요구 사항을 충족하는 가장 비용 효율적인 솔루션은 무엇입니까?

문제 20

(2개 선택)

데이터 플랫폼 팀이 AWS Glue Data Catalog를 사용하여 Amazon Athena로 Amazon S3에 있는 시계열 텔레메트리를 쿼리하고 있지만, 단일 테이블에 약 120만 개의 파티션이 year/month/day/hour 기준으로 s3://prod-telemetry/tenant_id={t}/year={YYYY}/month={MM}/day={DD}/hour={HH} 같은 prefix 아래에 구성되어 있어 쿼리 계획 수립이 병목이 되고 있습니다. 데이터를 S3에 유지하면서, 어떤 솔루션이 병목을 제거하고 Athena 계획 수립 시간을 줄일 수 있습니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 AWS Glue Data Catalog에 매우 많은 파티션이 있는 테이블에서 Athena 쿼리 계획 수립 동작을 테스트합니다. 약 120만 개의 파티션이 있는 경우 병목은 scan/compute가 아니라 계획 수립 중 메타데이터 및 파티션 열거(enumeration)입니다. 목표는 데이터를 S3에 유지하면서 Athena가 나열/고려해야 하는 파티션 수를 줄이는 것입니다. 정답이 맞는 이유: A (Glue partition index + partition filtering)는 Data Catalog에서 파티션 조회를 가속화하여 계획 수립 병목을 해결합니다. partition index는 파티션 메타데이터를 인덱싱된 형태로 저장하므로, Athena가 거대한 파티션 집합을 스캔/나열하는 대신 predicate(예: tenant_id 및 시간 범위)에 일치하는 파티션을 빠르게 찾을 수 있습니다. partition filtering이 활성화/사용되면 Athena는 더 이른 단계에서 파티션을 prune하여 비용이 큰 전체 파티션 열거를 피합니다. C (Athena partition projection)는 AWS Glue Data Catalog에 수백만 개의 파티션 엔트리를 저장하고 조회할 필요 자체를 제거합니다. 대신 파티션 스키마(tenant_id/year/month/day/hour)와 유효 범위/패턴을 정의하면, Athena가 쿼리 시점에 파티션 값과 해당 S3 경로를 계산합니다. 이는 “partition explosion” 메타데이터 오버헤드를 제거하며, 시계열 레이아웃에서 일반적으로 계획 수립 시간 감소 효과가 가장 큽니다. 주요 AWS 기능 / 모범 사례: - AWS Glue Data Catalog partition indexes: 파티션 수가 매우 큰 경우 파티션 조회 성능을 개선합니다. - Athena partition projection: projection type(integer, enum, date) 및 storage.location.template을 정의하여 파티션 값을 S3 prefix에 매핑하며, 파티션 관리 작업(예: MSCK REPAIR TABLE)을 줄이거나 제거합니다. - Predicate 설계: pruning/projection이 효과적이도록 쿼리에 partition column(tenant_id, year/month/day/hour 또는 파생된 timestamp filter)을 포함하도록 합니다. 흔한 오해: - Parquet로 변환(D)은 scan 효율과 비용을 개선하지만, 계획 수립 시 파티션 열거를 직접적으로 해결하지는 않습니다. - 작은 파일을 결합(E)하면 런타임 성능(S3 GET 감소, split 감소)은 좋아지지만, 파티션 메타데이터 기반 계획 수립 오버헤드는 줄지 않습니다. - Bucketing(B)은 일부 엔진에서 join/aggregation 성능에 도움이 될 수 있지만, 여기서 Athena의 주요 계획 수립 병목은 파일 분포가 아니라 파티션 메타데이터 규모입니다. 시험 팁: Athena/Glue에서 “수백만 개의 파티션”과 “planning time bottleneck”이 보이면 메타데이터 최적화를 떠올리세요: partition projection(카탈로그 파티션 회피)과 partition indexes(카탈로그 파티션 조회 가속). 파일 형식 및 small-file 해결은 보통 scan/런타임에 관한 것이지 계획 수립에 관한 것이 아닙니다.