AWS Certified Data Engineer - Associate (DEA-C01)

오답입니다. Lake Formation data filter는 Data Catalog table에 대한 권한 범위(행/열 필터링)를 제한하는 데 사용되며, S3 prefix를 data location으로 등록하는 용도가 아닙니다. data location 등록은 별도의 Lake Formation 작업(bucket 또는 prefix 등록)입니다. prefix를 등록할 수는 있지만, 그 메커니즘이 “data filter를 사용”하는 것은 아닙니다. 이 선택지는 서로 다른 Lake Formation 기능 두 가지를 혼동하고 있습니다.

오답입니다. Lake Formation data filter를 IAM role에 연결하지 않습니다. 대신 Lake Formation에서 data filter를 생성한 다음, 해당 filter를 참조하여 IAM principal(role/user)에 Lake Formation 권한을 grant합니다. IAM policy는 API action을 허용/거부할 수 있지만, 행/파티션 제한은 IAM role에 filter를 붙여서가 아니라 Lake Formation permission grant로 강제됩니다.

오답입니다. Region별로 별도의 S3 bucket을 만드는 것은 새 bucket과 데이터 중복을 피하라는 요구사항을 위반합니다. S3 prefix/bucket IAM policy로 구현하더라도, 이는 쿼리 시점의 행 수준 거버넌스가 아니라 object 수준의 거친 액세스 제어를 제공합니다. 또한 중앙 Lake Formation 거버넌스에 비해 운영 오버헤드(bucket 증가, replication/ingestion 변경, policy 증가)가 커집니다.

오답입니다. GZIP은 저장 및 전송 크기를 줄일 수 있지만, Spectrum에서는 핵심이 scan 효율과 parallelism입니다. GZIP으로 압축된 text 파일은 일반적으로 non-splittable이어서 parallel read를 제한하고 지연 시간을 증가시킵니다. 또한 파일당 1–5 GB는 최적의 parallelism과 복구 관점에서 종종 너무 큽니다. 더 나은 선택은 splittable compression(예: Snappy)을 사용하는 columnar Parquet/ORC와 적절한 파일 크기입니다.

오답입니다. 매우 작은 파일(<10 KB)이 많으면 small-file 문제가 발생합니다: S3 request overhead 증가, 과도한 metadata 작업, 비효율적인 task scheduling. Spectrum은 파일당 오버헤드를 줄이고 처리량을 개선할 수 있기 때문에 더 적고 더 큰 파일에서 더 잘 동작합니다. Parallelism은 중요하지만, 작은 object가 아니라 적절한 크기(종종 수백 MB)의 파일과 partitioning으로 달성해야 합니다.

오답입니다. non-splittable format/codec(예: GZIP이 적용된 CSV)은 일반적으로 parallel read를 제한하고 관련 없는 데이터를 효율적으로 건너뛰지 못하게 하므로 Spectrum 성능을 저하시킵니다. compression이 저장되는 byte를 줄이더라도, Spectrum은 predicate를 평가하기 위해 파일의 큰 부분을 읽고 decompress해야 할 수 있습니다. 가장 빠른 쿼리를 위해서는 columnar, splittable format(Parquet/ORC with Snappy/ZSTD)이 선호됩니다.

오답입니다. Glue Data Catalog에서 날짜 파티션이 없으면 쿼리 성능과 비용에 영향을 주어(Athena가 더 많은 데이터를 스캔) 실행 시간이 길어지거나 스캔 바이트가 증가하거나 타임아웃이 발생할 수는 있지만, 본질적으로 권한 실패를 유발하지는 않습니다. “Insufficient permissions”는 테이블 설계/파티션 전략보다는 IAM/S3/KMS 정책 문제를 가리킵니다.

오답입니다. SPICE vs Direct Query는 QuickSight가 데이터를 SPICE로 가져오는지 또는 Athena를 통해 라이브로 쿼리하는지를 바꿉니다. 그러나 새로 고침(SPICE ingestion)은 여전히 Athena 쿼리를 실행하고 S3 객체(결과 포함)를 읽고/쓰는 권한이 필요합니다. 따라서 SPICE 자체는 권한 오류의 근본 원인이 아니며, 누락된 S3/KMS 권한은 작업에 따라 두 모드 모두에서 문제를 일으킬 수 있습니다.

오답입니다. 기본이 아닌 Athena workgroup(wg-prod)을 사용하는 것 자체는 권한 문제를 의미하지 않습니다. workgroup은 설정(output location, 암호화, engine version)을 강제할 수 있고 IAM 권한(해당 workgroup에 대한 athena:StartQueryExecution 등)으로 제어될 수 있지만, 보기의 내용은 단지 primary가 아니라 wg-prod로 설정되었다는 것뿐이므로 추가 제약이 없는 한 “Insufficient permissions” 오류를 설명하지 못합니다.

데이터를 1일 후 S3 Glacier Deep Archive로 전환하면 Athena dashboard에서 활발하게 쿼리되는 데이터로는 적합하지 않게 됩니다. Athena는 먼저 object를 restore하지 않으면 Glacier Deep Archive의 데이터를 직접 분석할 수 없으며, 이는 큰 지연과 운영 복잡성을 초래합니다. 이는 dashboard를 15분마다 새로 고쳐야 한다는 요구 사항과 직접적으로 충돌합니다. 이 선택지는 analytics query 비용 최적화 전략이 아니라 archival 비용 전략입니다.

Athena query result reuse는 동일한 query text가 다시 실행되고 Athena가 이전 result set를 안전하게 재사용할 수 있을 때만 비용을 줄일 수 있습니다. dashboard 환경에서는 쿼리가 time window, filter, parameter 또는 생성된 SQL text에 따라 자주 달라지므로, reuse가 광범위한 절감을 제공한다고 보장할 수 없습니다. 또한 각 query pattern의 첫 번째 실행 비용은 줄이지 못하는 반면, Parquet는 모든 쿼리의 스캔 비용을 낮춥니다. 따라서 result reuse는 일부 경우에 도움이 되지만, 매우 큰 데이터셋에서 Athena 비용을 줄이기 위한 전반적인 최선의 솔루션은 아닙니다.

Amazon ElastiCache는 새로운 infrastructure를 도입하게 되며, 이는 문제에서 명시적으로 피하라고 한 사항입니다. 또한 provisioning, scaling, monitoring, cache invalidation 및 dashboard application과의 integration에 대한 운영 오버헤드도 추가됩니다. caching은 반복되는 query load를 줄일 수 있지만, 이 시나리오에서 운영 측면에서 가장 부담이 적은 선택지는 아닙니다. Parquet를 사용한 S3의 native data format 최적화가 더 단순하고 Athena 모범 사례에도 더 부합합니다.

Amazon Kinesis Data Streams는 shard 관리 또는 on-demand 모드를 통한 탄력적 스케일링을 제공하는 완전 관리형 스트리밍 서비스이지만, Kafka 호환이 아니다. Kafka/Debezium에서 마이그레이션하려면 producer/consumer를 Kinesis API로 리팩터링하고 offset/consumer group 및 partitioning 시맨틱을 재설계해야 한다. 처리량 요구는 충족할 수 있지만, replatform(리팩터링 아님) 전략에서 Kafka API를 보존해야 한다는 요구 사항을 위반한다.

Amazon MSK provisioned cluster는 Kafka API를 보존하며 Kafka lift-and-shift 마이그레이션의 일반적인 replatform 대상이다. 그러나 serverless보다 운영 관리가 더 필요하다. 브로커 인스턴스 타입/개수를 선택하고, 버스트를 위한 용량을 계획하며, 스케일링 작업을 관리하고, partition/broker 밸런싱 고려 사항을 처리해야 한다. 관리형(패치, 교체)이긴 하지만, 자동 스케일링이 명시적으로 요구될 때 최소 오버헤드 옵션은 아니다.

Amazon Kinesis Data Firehose는 선택적 버퍼링 및 변환과 함께 대상(S3, Redshift, OpenSearch, Splunk)으로 전달하기 위한 서비스로, 범용 Kafka 호환 스트리밍 플랫폼이 아니다. Kafka broker 시맨틱, topic/partition, consumer group 코디네이션을 제공하지 않는다. Firehose를 사용하면 CDC 파이프라인과 consumer 동작을 재설계해야 하므로 리팩터링이 필요하며 Kafka API 보존에도 적합하지 않다.

AWS Data Exchange는 AWS에서 서드파티 데이터셋을 찾고, 구독하고, 사용하는 서비스입니다. 워크플로 오케스트레이션, 스케줄링, DAG 실행을 제공하지 않습니다. 데이터 파이프라인이 외부 데이터셋을 소비할 수는 있지만, Data Exchange는 오케스트레이터가 아니며 온프레미스와 관리형 클라우드 서비스에서 동일한 오픈 소스 DAG 정의를 실행하는 요구사항을 충족할 수 없습니다.

Amazon SWF는 AWS 네이티브 워크플로 조정 서비스입니다. 작업을 오케스트레이션할 수는 있지만 Apache Airflow가 아니며 Airflow DAG 정의를 사용하지 않습니다. SWF를 사용하면 워크플로 로직과 애플리케이션 통합을 재설계해야 하므로 벤더 종속이 증가합니다. 또한 공유 DAG 코드로 온프레미스 오픈 소스 DAG 엔진의 “완전 관리형 동등 서비스”를 제공하지 않습니다.

AWS Glue는 crawlers, jobs, Glue Workflows를 갖춘 서버리스 데이터 통합(ETL/ELT) 서비스입니다. 그러나 Glue는 Apache Airflow가 아니며, 다시 작성 없이 온프레미스와 AWS에서 동일한 Airflow DAG를 실행할 수 없습니다. 또한 Glue는 온프레미스 Kubernetes 클러스터에 동일한 오픈 소스 엔진으로 배포할 수 없으므로 이식성과 종속 회피 요구사항을 충족하지 못합니다.

오답입니다. certificate를 수동으로 생성하고 스크립트와 cron job으로 교체하는 방식은 불필요한 운영 복잡성을 만들고, 갱신 시점에 outage가 발생할 위험을 높입니다. 또한 이 접근 방식은 validation, secure storage, deployment timing, rollback logic를 팀이 직접 처리해야 합니다. 이는 관리형 갱신과 원활한 배포를 위한 ACM의 CloudFront native integration을 활용하지 못합니다. 시험 문제에서 least operational overhead와 zero-downtime renewals를 강조한다면, 수동 프로세스는 ACM보다 분명히 열등합니다.

오답입니다. AWS Secrets Manager는 database credentials, API keys 및 기타 application secrets와 같은 secret을 저장하고 교체하는 용도로 설계되었으며, CloudFront viewer certificates의 기본 certificate lifecycle manager가 아닙니다. CloudFront는 public custom-domain certificate를 Secrets Manager에서 native하게 가져오지 않으므로, 이 설계는 여전히 certificate를 import하고 연결하기 위한 custom automation이 필요합니다. 이는 복잡성, 유지 관리 부담, 그리고 배포 오류나 downtime 가능성을 더합니다. 반면 ACM은 이 정확한 사용 사례에 대해 직접적인 certificate 발급, 갱신 및 CloudFront integration을 이미 제공합니다.

오답입니다. Amazon ECS Service Connect는 ECS workloads를 위한 service-to-service networking 기능으로, 내부 연결 패턴에는 도움이 될 수 있지만 CloudFront 또는 API Gateway custom domains용 public certificates 관리와는 관련이 없습니다. 문제의 아키텍처는 ECS-hosted services가 아니라 API Gateway와 CloudFront를 기반으로 합니다. 또한 mesh-style connectivity도 요구하지 않습니다. Service Connect는 client가 CloudFront에 연결할 때 사용되는 public edge certificate를 프로비저닝하거나 교체하지 않습니다. 따라서 제시된 TLS, renewal 또는 multi-Region certificate management 요구 사항을 해결하지 못합니다.

ALL distribution은 전체 테이블을 모든 노드에 복제하여 조인 시 재분배를 제거합니다. 그러나 이는 작은 dimension/lookup 테이블을 위한 것입니다. 약 3 TB까지 성장할 테이블을 4-노드 클러스터 전체에 복제하면 스토리지 사용량, 로드 시간, vacuum/유지보수 오버헤드가 크게 증가하고 성능에도 부정적 영향을 줄 수 있습니다. 이는 테이블이 확장될 때 지속적인 유지보수를 최소화해야 한다는 요구사항과 정면으로 충돌합니다.

EVEN distribution은 행을 slice 전반에 라운드로빈으로 분산하므로, 적절한 distkey가 없을 때 합리적인 기본값이며 skew를 피하는 데 도움이 됩니다. 하지만 이는 고정된 수동 선택입니다. 테이블이 커지고 쿼리 패턴이 진화하면, EVEN은 Redshift가 관리하는 결정(예: 작은 테이블에 대해 ALL을 선택하거나 전략을 조정하는 것)보다 최적이 아닐 수 있습니다. “지속적인 유지보수 최소화” 요구사항을 가장 잘 충족하지는 못합니다.

KEY distribution은 동일한 distkey 값을 가진 행을 같은 노드에 colocate하여, 테이블들이 동일한 조인 키를 공유하고 그 키가 균등 분포의 high cardinality일 때 조인 성능을 크게 향상시킬 수 있습니다. 그러나 프롬프트는 distribution key로 적합한 안정적인 조인 컬럼이나 균일하게 높은 cardinality 필드가 없다고 명시하므로, KEY는 데이터 skew, 불균등한 노드 활용, 향후 재작업을 유발할 가능성이 높아 유지보수 최소화와 반대입니다.

AWS Config rules는 AWS resources의 configuration state(예: bucket policy, public access settings)를 평가하고 시간 경과에 따른 compliance를 보고합니다. GetObject/PutObject 같은 개별 S3 object API call을 캡처하지 않으며, 거부된 각 요청에 대한 정확한 username도 제공하지 않습니다. Config는 거의 실시간의 요청 단위 위반 알림을 위해 설계되지 않았으므로 3분 미만, 사용자별 요구 사항을 충족할 수 없습니다.

S3에 대한 Amazon CloudWatch metrics(요청 metrics 포함)는 주로 집계된 count/latency이며, 정확한 username 또는 특정 AccessDenied 이벤트 컨텍스트 같은 요청 단위 세부 정보를 제공하지 않습니다. S3 request metrics를 활성화하더라도 특정 prefix에서 policy를 위반한 사용자가 누구인지 신뢰성 있게 식별할 수 없습니다. 따라서 attribution 요구 사항을 충족하지 못합니다.

S3 server access logs는 object-level requests를 보여줄 수 있지만, 전달이 거의 실시간이 아니며 logs는 일반적으로 상당한 지연(종종 수십 분에서 수 시간) 후에 전달됩니다. 또한 이를 CloudWatch Logs로 운영화하면 ingestion/processing 지연과 복잡성이 추가됩니다. requester 정보가 포함될 수는 있지만, 3분 미만이라는 시간 요구 사항이 이 옵션이 부적합한 주된 이유입니다.

bucket policy가 액세스를 차단할 수는 있지만, 프롬프트는 role에 s3:ListBucket 및 s3:GetObject가 있고 실패가 SSE-KMS로 암호화된 객체를 읽는 동안 발생한다고 구체적으로 말한다. 실제로도 동일한 role이 목록 조회와 읽기 시도를 할 수 있지만 KMS 때문에 복호화가 실패하는 경우가 많다. 문제에서 명시적인 bucket policy deny나 cross-account 제한을 언급하지 않는 한, KMS 권한 누락이 더 가능성이 높은 원인이다.

Athena engine version 문제는 보통 쿼리 문법/기능 비호환이나 성능 차이를 유발하지, S3에서 객체를 가져올 때 AccessDenied 오류를 만들지는 않는다. AccessDenied는 S3/KMS의 권한 부여 실패이며 compute engine 불일치가 아니다. 시험에서는 증상이 지원되지 않는 SQL 함수, Parquet reader 버그, 또는 문서화된 engine별 동작이 아닌 이상 “오래된 engine version”을 오답 유도 선택지로 보라.

Region 불일치는 지연 시간 때문에 AccessDenied로 나타나지 않는다. S3는 regional service이며 다른 Region의 버킷에 접근하는 것도 global endpoint/redirect 동작을 통해 가능하지만, 이는 권한 오류를 유발하지 않는다. Athena 쿼리는 특정 Region에서 실행되며 일반적인 구성에서는 데이터 소스와 Glue catalog가 같은 Region에 있어야 하지만, 설명된 오류(객체 읽기 중 AccessDenied)는 지연 시간이 아니라 권한을 가리킨다.

AWS Step Functions는 ETL 단계를 orchestration할 수 있지만, Glue 중심 파이프라인에 가장 자연스러운 기능이라기보다는 범용 workflow 서비스입니다. 이 시나리오에서는 파이프라인이 JDBC 소스 크롤링과 ETL job 실행 같은 Glue-native 기능에 이미 의존하고 있으므로, Step Functions를 추가하면 필요하지 않은 추가 orchestration 서비스를 도입하게 됩니다. Step Functions도 serverless이고 오버헤드가 낮지만, 시험 관점에서 가장 적절한 답은 워크플로가 주로 crawler에서 job으로 이어지는 순서를 다룰 때의 Glue-native orchestration 기능입니다. 따라서 Step Functions도 가능한 선택이지만, 제시된 보기 중 가장 비용 효율적이거나 직접적으로 맞는 선택은 아닙니다.

AWS Glue Studio는 Glue ETL jobs를 생성, 편집, 모니터링하기 위한 시각적 개발 인터페이스입니다. 데이터 엔지니어가 transformations를 설계하고 Glue job 코드를 생성하는 데 도움을 주지만, crawlers, jobs, 그리고 scheduled dependencies를 처음부터 끝까지 연결하는 기본 orchestration 기능은 아닙니다. 문제는 최소한의 오버헤드로 일일 일정에 따라 파이프라인을 orchestration할 서비스 또는 기능을 묻고 있으므로, Studio UI가 아니라 Glue workflows를 가리킵니다. Glue Studio를 선택하는 것은 job authoring과 workflow orchestration을 혼동한 것입니다.

Amazon MWAA는 여러 시스템 전반에서 복잡한 DAG 기반 orchestration을 위한 관리형 Apache Airflow를 제공하지만, 단일 일일 Glue 중심 ETL 파이프라인에는 보통 과도한 선택입니다. MWAA는 지속적으로 실행되는 Airflow 환경을 필요로 하므로, Glue workflows와 비교해 비용과 운영 복잡성이 모두 증가합니다. 문제는 관리형 서비스 오버헤드 최소화와 비용 통제를 강조하므로, MWAA는 적합하지 않습니다. 이는 이미 Airflow를 표준으로 사용하고 있거나 Glue-native 기능을 넘어서는 광범위한 custom orchestration이 필요한 조직에 더 적합합니다.

오답입니다. reading_date로 partitioning하는 것은 좋지만, Amazon Redshift를 사용하면 비용과 운영 오버헤드가 추가됩니다(S3에서 데이터 loading, 테이블 유지관리, vacuum/analyze, 또는 Redshift Serverless 비용). 주간 ad hoc KPI의 경우 S3의 partitioned Parquet에 대한 Athena가 보통 더 저렴하고 단순합니다. Redshift는 지속적으로 높은 concurrency/latency 요구나 복잡한 warehouse workload가 필요할 때 더 적합합니다.

오답입니다. ingestion_date로 partitioning하는 것은 reading_date 필터와 일치하지 않으므로, 추가적인 indexing/partitioning이 없으면 Spark job이 여전히 많은 데이터를 scan할 수 있습니다. EMR은 cluster 관리와 compute 비용도 발생하며, 이는 주간 ad hoc SQL KPI에 일반적으로 정당화되지 않습니다. Spark는 무거운 transformation/ML에 적합하며, 단순 date-filtered KPI query에 가장 cost-effective한 선택은 아닙니다.

오답입니다. Aurora는 OLTP relational database이며 S3에서 증가하는 Parquet 데이터셋에 대한 대규모 분석 scan을 위해 설계되지 않았습니다. 데이터를 Aurora 테이블로 ETL 및 load해야 하므로 비용과 복잡성이 증가하고, 수백 일치 데이터에 대한 query는 Athena로 partition-pruned Parquet를 scan하는 것만큼 cost-effective하지 않습니다. Aurora는 또한 지속적인 instance/storage 비용이 있습니다.

오답. SageMaker Data Wrangler는 data quality/insights report를 생성할 수 있지만, AWS Glue ETL job 내부에서 hard fail/pass gate를 강제하기보다는 interactive data preparation 및 ML workflow에 더 적합하다. 또한 기존 Glue pipeline 외부에 flow, processing job, scheduling 같은 운영 component를 추가하므로 “least operational overhead” 요구사항 및 Glue transform 단계에서 check를 강제해야 한다는 요구사항과 맞지 않는다.

오답. Custom SQL/PySpark transform(각 column별 null check + referential integrity를 위한 LEFT ANTI JOIN 로직)은 기능 요구사항을 충족할 수 있지만 운영 오버헤드를 증가시킨다. 작성/테스트/유지해야 할 코드가 더 많고, 대규모에서 성능 이슈 위험이 있으며, reporting/metric 표준화에도 추가 노력이 든다. 문제는 최소 운영 오버헤드를 명시하므로 bespoke validation 로직보다 managed Glue Data Quality rule이 더 적합하다.

오답. Data Wrangler에서 custom Python으로 null check와 referential integrity를 구현할 수는 있지만, Glue 네이티브 솔루션에 비해 추가 orchestration 및 runtime 관리가 필요하다. 또한 기존 Glue ETL transform 단계에 check를 내장하기보다 SageMaker processing job/flow 쪽으로 솔루션이 이동한다. 이는 일반적으로 Glue 내 Evaluate Data Quality를 사용하는 것보다 운영적으로 더 복잡하다.

오답. shard를 늘리면 aggregate capacity는 증가하지만 partition-key skew를 본질적으로 해결하지는 못합니다. merchantId가 partition key로 유지되면 flash-sale merchant의 record는 여전히 동일한 shard(또는 resharding 이후에도 소수 subset)로 hash되어 해당 shard는 계속 hot 상태로 throttling되고 다른 shard는 underutilized로 남습니다.

오답. producer를 초당 1,000 records로 throttling하면 ingestion throughput이 감소하여 동일한 전체 throughput을 유지해야 한다는 요구사항을 위반합니다. stream은 이미 aggregate capacity가 충분하며, 문제는 총 capacity 부족이 아니라 shard 간 불균등 분산입니다.

오답. record 크기를 줄이는 것은 shard가 1 MB/s limit에 걸릴 때는 도움이 될 수 있지만, hot shard는 shard당 1,000 records/s limit에도 제약을 받을 수 있습니다. 2 KB record의 경우 지배적인 merchant가 MB/s는 낮더라도 shard당 record-rate limit을 초과할 수 있습니다. 근본 원인은 record 크기가 아니라 partition-key skew입니다.

오답입니다. 팀/애플리케이션별로 별도의 S3 bucket을 생성하는 것은 동일한 S3 bucket을 계속 사용해야 하고 데이터 복제를 피해야 한다는 요구 사항을 위반합니다. 또한 bucket policy로 데이터 액세스를 제한하더라도 Athena 쿼리 실행 리소스, 저장된 쿼리, 쿼리 기록을 직접적으로 격리하지는 못합니다. S3 수준 격리는 데이터 액세스 제어 메커니즘이지 Athena 운영 격리 메커니즘이 아닙니다.

오답입니다. 별도의 IAM role을 생성하면 권한 분리에 도움이 될 수 있지만, role만으로는 Athena 쿼리 기록과 저장된 쿼리에 대한 요구된 격리를 제공하지 않습니다. 여러 role이 명시적으로 제한되지 않으면 동일한 default workgroup을 사용할 수 있으며, 문제는 리소스 tag 조건을 사용한 강제와 workgroup 범위 아티팩트의 격리를 구체적으로 요구하므로 Athena workgroup으로 달성하는 것이 가장 적합합니다.

오답입니다. AWS Glue Data Catalog 리소스 policy(또는 Lake Formation 권한)는 누가 어떤 database/table에 액세스할 수 있는지 제어할 수 있지만, Athena 쿼리 실행 리소스, 비용, 저장된 쿼리, 쿼리 기록을 격리하지는 못합니다. 이 옵션은 메타데이터/table 수준의 데이터 거버넌스를 다루며, 문제에서 요구하는 Athena 사용의 운영 격리를 다루지 않습니다.

운영 오버헤드가 높고 불필요하게 복잡합니다. MWAA는 Airflow environment(workers, schedulers, plugins, dependencies) 운영이 필요합니다. 상관 분석에 Lambda를 사용하고 오케스트레이션에 Step Functions를 사용하는 것은 오케스트레이션 책임을 중복시킵니다. 또한 100+ GB를 Lambda로 상관 분석하는 것은 실행 시간/메모리 제한과 분산 조인 필요 때문에 적합하지 않으며, Glue/Spark가 대규모 조인에 더 적합합니다.

AppFlow + Glue는 강력한 수집/ETL 접근이지만, MWAA를 추가하면 1일 1회 야간 파이프라인에 대해 Step Functions 대비 운영 오버헤드가 증가합니다. MWAA는 여전히 environment 관리, 스케일링, DAG 유지보수가 필요합니다. 회사가 이미 Airflow로 표준화했거나 복잡한 DAG 패턴/operator가 필요하지 않다면, Step Functions가 일반적으로 더 낮은 운영 부담의 오케스트레이션 선택입니다.

요구 사항에 비해 과도하게 설계되었습니다. Kinesis Data Streams와 Managed Service for Apache Flink는 실시간 streaming 수집 및 stream processing을 위해 설계되었습니다. 문제는 지속적인 상관 분석이 아니라 야간 배치 실행을 요구합니다. 또한 PostgreSQL에서 Kinesis로 가져오는 것은 간단하지 않으며, 종종 커스텀 producer 또는 CDC tooling이 필요해 Glue JDBC 추출보다 운영 부담이 증가합니다.

AWS Glue는 Data Catalog와 managed job execution을 제공하는 serverless ETL 서비스(Spark 기반)로, batch ETL과 schema discovery에 적합합니다. 그러나 managed Apache HBase 또는 Apache Oozie를 제공하지 않으며, 전체 Hadoop ecosystem을 lift-and-shift하도록 설계되지 않았습니다. Spark, Flink, HBase, Oozie를 함께 유지해야 한다는 엄격한 요구 사항 때문에 serverless 매력에도 불구하고 Glue는 불완전한 선택입니다.

AWS Lambda는 event-driven functions를 위한 serverless compute로, 짧은 실행 시간과 제한된 memory/runtime 제약이 있습니다. Spark/Flink 같은 분산 big data frameworks를 실행하기에 적합하지 않으며 HBase 또는 Oozie를 호스팅할 수도 없습니다. Lambda는 ETL 단계를 orchestration하거나 trigger하는 데는 사용할 수 있지만, 하루 수 PB 처리와 90초 미만 ETL 실행을 위한 Hadoop/Spark/Flink 실행 환경을 대체할 수는 없습니다.

Amazon Redshift는 SQL analytics에 최적화된 managed data warehouse이며, ELT 패턴(예: COPY, SQL transforms)을 수행하고 ingestion 도구와 통합할 수 있습니다. 그러나 Apache Spark, Flink, HBase, Oozie workflows를 직접 실행하지는 않습니다. Redshift는 정제된 데이터의 target store가 될 수는 있지만, 기존 Hadoop ecosystem 프레임워크와 운영 모델을 유지하는 ETL 서비스는 아닙니다.

이 선택지는 데이터 품질 및 변환 로직을 AWS Glue DataBrew에 배치하는데, 이는 RDS로 로드하는 운영형 예약 ETL 파이프라인보다는 대화형 시각적 데이터 준비에 더 초점이 맞춰져 있습니다. DataBrew도 profiling과 변환을 수행할 수 있지만, Glue 중심 ETL 워크플로에서 공식적인 규칙 기반 품질 검사를 위해서는 AWS Glue Data Quality가 더 직접적으로 관련된 서비스입니다. 이 선택지는 품질 결과를 저비용인 S3에 저장한다는 점에서 매력적이지만, 필요한 데이터 품질 구현에 더 적합한 서비스를 포기하게 됩니다. 예약 ETL과 명시적인 품질 규칙에 초점을 둔 시험 문제에서는 Glue ETL과 Glue Data Quality가 더 강력한 정답 패턴입니다.

이 선택지는 처리된 데이터셋을 향후 SQL 쿼리를 위해 단일 Amazon RDS for MySQL 인스턴스에 로드하는 대신 S3에 저장하므로 핵심 요구 사항을 충족하지 못합니다. S3는 로그와 중간 출력을 보관하는 데 비용 효율적이지만, 정제된 데이터셋의 명시된 대상 요구 사항은 충족하지 못합니다. 또한 더 적절한 Glue Data Quality 기능 대신 DataBrew를 품질 검사에 사용합니다. 필요한 대상 시스템을 충족하지 못하므로 정답이 될 수 없습니다.

이 선택지는 변환과 품질 검사 모두에 DataBrew를 사용한 다음, 정제된 데이터와 품질 결과를 모두 Amazon RDS for MySQL에 저장합니다. 이러한 설계는 비용 효율적이지 않은데, 상세한 품질 검사 로그는 더 높은 스토리지 및 백업 비용이 드는 관계형 데이터베이스보다 Amazon S3와 같은 저비용 객체 스토리지에 보관하는 것이 더 적합하기 때문입니다. 또한 규칙 기반 검증 요구 사항에 대해 Glue Data Quality 대신 DataBrew에 의존합니다. 그 결과, 서비스 적합성과 스토리지 비용 최적화 측면 모두에서 더 약한 선택지입니다.

오답입니다. Hive-style bucketing(자주 필터링되는 컬럼 기준으로 파일을 rebucket)은 특정 쿼리 패턴(예: joins/aggregations)에서 shuffle을 줄이고 병렬성을 개선하는 데 도움이 될 수 있지만, 핵심 문제인 AWS Glue Data Catalog의 수백만 파티션으로 인한 Athena 계획 수립 오버헤드를 해결하지는 않습니다. Bucketing은 파티션 내부의 파일 레이아웃을 바꾸는 것이지, 파티션 수나 파티션 메타데이터를 해석해야 하는 필요를 줄이지 않습니다.

오답입니다. Parquet로 변환하는 것은 columnar 형식이며 predicate pushdown을 지원하고 스캔 바이트를 줄여 런타임과 비용을 개선하므로 Athena에 대한 강력한 최적화입니다. 하지만 파티션 수를 본질적으로 줄이거나 Athena가 계획 수립 중 파티션 메타데이터를 해석해야 하는 필요를 없애지는 않습니다. 병목이 planning(스캔이 아님)이라면 Parquet만으로는 이를 제거할 수 없습니다.

오답입니다. 많은 작은 object를 더 큰 object로 결합하면 S3 요청 오버헤드를 줄이고 split 및 파일 open 작업 수를 줄여 Athena 런타임을 개선할 수 있습니다. 하지만 Glue 파티션 메타데이터의 양이나 계획 수립 시간을 유발하는 파티션 열거는 줄이지 못합니다. 이는 “small files problem”에 대한 최적화이지, “카탈로그에 파티션이 너무 많음”에 대한 해결책이 아닙니다.