
65개 문제와 130분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
한 스트리밍 미디어 회사는 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에 해당하는 레코드만 쿼리할 수 있도록 보장해야 합니다. 팀이 수행해야 할 단계 조합은 무엇입니까? (두 개 선택)
오답입니다. Lake Formation data filter는 Data Catalog table에 대한 권한 범위(행/열 필터링)를 제한하는 데 사용되며, S3 prefix를 data location으로 등록하는 용도가 아닙니다. data location 등록은 별도의 Lake Formation 작업(bucket 또는 prefix 등록)입니다. prefix를 등록할 수는 있지만, 그 메커니즘이 “data filter를 사용”하는 것은 아닙니다. 이 선택지는 서로 다른 Lake Formation 기능 두 가지를 혼동하고 있습니다.
정답입니다. S3 bucket 또는 특정 prefix를 Lake Formation data location으로 등록하는 것은 기본 object에 대해 Lake Formation이 거버닝되는 액세스를 제공하기 위한 선행 조건입니다. 이를 통해 Lake Formation이 service-linked role을 통해 액세스를 관리하고 Athena 같은 서비스에 대해 권한을 강제할 수 있습니다. 이 단계는 새 bucket을 만들거나 데이터를 중복하지 않고 중앙 거버넌스를 지원합니다.
오답입니다. 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로 강제됩니다.
정답입니다. fine-grained access control을 활성화하고 Region 기반 data filter(예: aws_region = 'us-east-1')를 생성하면, Lake Formation이 행 수준 제한을 강제하여 각 스튜디오의 Athena 쿼리가 해당 Region의 레코드만 반환하도록 할 수 있습니다. 적절한 filter를 사용해 각 스튜디오의 IAM role에 권한을 부여하는 것은 운영 오버헤드를 최소화하고 새 bucket 또는 데이터 중복을 피한다는 요구사항을 충족합니다.
오답입니다. Region별로 별도의 S3 bucket을 만드는 것은 새 bucket과 데이터 중복을 피하라는 요구사항을 위반합니다. S3 prefix/bucket IAM policy로 구현하더라도, 이는 쿼리 시점의 행 수준 거버넌스가 아니라 object 수준의 거친 액세스 제어를 제공합니다. 또한 중앙 Lake Formation 거버넌스에 비해 운영 오버헤드(bucket 증가, replication/ingestion 변경, policy 증가)가 커집니다.
핵심 개념: 이 문제는 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에서 무엇을 볼 수 있는지를 제어한다는 점을 기억하세요.
한 미디어 분석 회사가 온프레미스 Kafka 클러스터(브로커 3개, 파티션 24개, 평균 ingest 약 2 MB/s이며 최대 12 MB/s까지 버스트, 메시지 50 KB)와 온프레미스 MySQL에서 Debezium을 통해 방출되는 증분 CDC 업데이트를 처리하는 consumer 애플리케이션을 AWS로 lift-and-shift할 계획이다. 또한 팀은 운영 관리가 최소화되면서 Kafka API를 보존하고 자동 스케일링을 유지하는 replatform(리팩터링 아님) 전략을 고수한다. 이러한 요구 사항을 가장 적은 관리 오버헤드로 충족하는 AWS 서비스 선택은 무엇인가?
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 보존에도 적합하지 않다.
Amazon MSK Serverless는 가장 낮은 운영 부담으로 Kafka API 호환성을 제공한다. 처리량과 스토리지를 자동으로 확장하여 브로커를 사이징하고 관리할 필요를 없애면서도 Kafka client, topic, partition, consumer group을 지원한다. 이는 최소 관리와 자동 스케일링으로 Kafka 기반 CDC 파이프라인(Debezium + Kafka consumer)을 AWS로 replatform하는 요구 사항과 직접적으로 부합하므로 최선의 선택이다.
핵심 개념: 이 문제는 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/처리 패턴을 명시적으로 요구할 때만 선택하라.
데이터 엔지니어는 주거용 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 충족합니까?
정답입니다. reading_date로 partitioning하면 query predicate와 정렬되어 Athena partition pruning이 가능해지므로 최근 7/30/180일에 해당하는 partition만 scan합니다. Parquet를 사용하면 Athena는 columnar read와 predicate pushdown의 이점도 얻어 scan되는 바이트와 비용을 줄입니다. Glue Data Catalog는 table/partition metadata를 제공합니다. 이는 serverless이며 pay-per-scan이므로 주간 ad hoc query에 매우 cost-effective합니다.
오답입니다. 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 비용이 있습니다.
핵심 개념: 이 문제는 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를 사용하여 데이터 증가에 따른 비용과 성능을 제어하는 것입니다.
데이터 플랫폼 팀이 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 계획 수립 시간을 줄일 수 있습니까? (두 개 선택)
정답입니다. Glue partition index는 파티션 수가 매우 많은 테이블에서 파티션 메타데이터 조회 성능을 개선합니다. 쿼리에 partition key(tenant_id, year/month/day/hour)에 대한 predicate가 포함되면, Athena는 인덱스를 사용해 일치하는 파티션을 더 빠르게 찾고 계획 수립 중 일치하지 않는 파티션을 prune할 수 있습니다. 이는 AWS Glue Data Catalog에서 거대한 파티션 목록을 열거하거나 스캔하면서 발생하는 쿼리 계획 수립 병목을 직접적으로 겨냥합니다.
오답입니다. Hive-style bucketing(자주 필터링되는 컬럼 기준으로 파일을 rebucket)은 특정 쿼리 패턴(예: joins/aggregations)에서 shuffle을 줄이고 병렬성을 개선하는 데 도움이 될 수 있지만, 핵심 문제인 AWS Glue Data Catalog의 수백만 파티션으로 인한 Athena 계획 수립 오버헤드를 해결하지는 않습니다. Bucketing은 파티션 내부의 파일 레이아웃을 바꾸는 것이지, 파티션 수나 파티션 메타데이터를 해석해야 하는 필요를 줄이지 않습니다.
정답입니다. Partition projection은 정의된 스키마(date range, enum, integer)로부터 Athena가 파티션을 계산하고 location template을 통해 이를 S3 경로에 매핑하도록 합니다. 이로써 AWS Glue Data Catalog에 120만 개의 파티션 엔트리를 저장할 필요가 없어지고, 계획 수립 중 비용이 큰 파티션 listing을 피할 수 있습니다. 예측 가능한 파티션 패턴과 매우 높은 파티션 수를 가진 시계열 데이터에 대한 모범 사례 기능입니다.
오답입니다. Parquet로 변환하는 것은 columnar 형식이며 predicate pushdown을 지원하고 스캔 바이트를 줄여 런타임과 비용을 개선하므로 Athena에 대한 강력한 최적화입니다. 하지만 파티션 수를 본질적으로 줄이거나 Athena가 계획 수립 중 파티션 메타데이터를 해석해야 하는 필요를 없애지는 않습니다. 병목이 planning(스캔이 아님)이라면 Parquet만으로는 이를 제거할 수 없습니다.
오답입니다. 많은 작은 object를 더 큰 object로 결합하면 S3 요청 오버헤드를 줄이고 split 및 파일 open 작업 수를 줄여 Athena 런타임을 개선할 수 있습니다. 하지만 Glue 파티션 메타데이터의 양이나 계획 수립 시간을 유발하는 파티션 열거는 줄이지 못합니다. 이는 “small files problem”에 대한 최적화이지, “카탈로그에 파티션이 너무 많음”에 대한 해결책이 아닙니다.
핵심 개념: 이 문제는 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/런타임에 관한 것이지 계획 수립에 관한 것이 아닙니다.
모빌리티 분석 스타트업이 차량 텔레메트리를 평균 초당 2,800개의 JSON 이벤트(버스트 시 최대 11,000 events/s, 이벤트당 약 1.8 KB)로 Amazon MSK 클러스터에 수집하고 있으며, 운영 대시보드를 위해 이 데이터를 Amazon Redshift에서 1분 미만의 최신성(End-to-end SLA: 45초 미만)으로 사용할 수 있어야 합니다. 또한 스트리밍 소스 외부에 추가적인 내구성 있는 원시(raw) 사본을 두지 않아 스토리지 비용을 최적화하고 운영 오버헤드를 최소화하려고 합니다. 다음 중 최소한의 운영 노력으로 이러한 요구 사항을 가장 잘 충족하는 솔루션은 무엇입니까?
정답입니다. Amazon Redshift는 external schema와 stream에 대한 materialized view를 사용하여 Amazon MSK와 같은 Kafka-compatible 소스의 streaming ingestion을 지원합니다. 이를 통해 Redshift는 topic에서 직접 record를 수집하고, 운영 대시보드에 적합한 낮은 지연 시간으로 SQL analytics에 사용할 수 있도록 합니다. 또한 요구 사항에서 비용과 아키텍처 단순성을 위해 명시적으로 피하고자 하는 Amazon S3를 중간의 durable store로 도입하지 않아도 됩니다. 별도의 consumer, ETL job, 또는 event-driven loader를 구축하고 유지 관리할 필요가 없으므로 운영 노력도 최소화됩니다.
오답입니다. Parquet file을 Amazon S3에 쓰는 AWS Glue streaming ETL job은 streaming source 외부에 추가적인 durable raw copy를 생성하므로, 추가 storage 비용을 피해야 한다는 요구 사항과 직접적으로 충돌합니다. 특히 hourly partition을 사용하는 것은 45초 미만의 freshness SLA를 훨씬 초과하는 지연 시간을 유발하므로 더욱 문제가 됩니다. 또한 Redshift Spectrum을 통한 query는 낮은 지연 시간의 운영 대시보드보다는 lake 스타일 analytics에 더 적합합니다. 이 설계는 job 관리, partition 처리, 그리고 S3 file lifecycle 관련 문제를 통해 운영 오버헤드도 추가합니다.
오답입니다. external schema 자체는 streaming source에 대한 연결 계층일 뿐이며, 설명된 것처럼 일반적인 Redshift table이 단순히 stream을 직접 참조할 수 있음을 의미하지는 않습니다. Redshift streaming ingestion에서 지원되는 패턴은 external streaming source 위에 materialized view를 정의하여 Redshift가 stream 데이터를 적절히 수집하고 저장할 수 있도록 하는 것입니다. 이 메커니즘이 없으면 해당 선택지는 불완전하며 기술적으로도 오해의 소지가 있습니다. 따라서 낮은 지연 시간의 대시보드 접근을 위한 유효하거나 모범 사례에 해당하는 솔루션이 아닙니다.
오답입니다. 먼저 stream을 Amazon S3로 보내는 것은 문제에서 명시적으로 피하고자 하는 추가 durable copy를 생성합니다. 또한 S3 event와 AWS Lambda를 사용하여 record를 Redshift에 삽입하는 방식은 상당한 운영 복잡성을 추가하며, 제시된 지속 및 burst event rate에서 효율적인 loading 패턴도 아닙니다. Lambda 기반의 object별 또는 소규모 batch insert는 Redshift에 대해 scaling, retry, 그리고 transaction 측면의 비효율을 초래할 수 있습니다. 따라서 이 아키텍처는 더 복잡할 뿐만 아니라 sub-minute SLA를 안정적으로 충족할 가능성도 더 낮습니다.
핵심 개념: 이 문제는 스트리밍 소스(Amazon MSK/Kafka)에서 Amazon Redshift로의 준실시간 ingest를 최소 운영 오버헤드로 수행하고, 스트리밍 소스 외부(예: Amazon S3)에 추가적인 내구성 있는 “raw” 사본을 만들지 않는 것을 테스트합니다. 이는 external schema와 materialized view를 사용하는 최신 Redshift streaming ingestion 패턴과 맞닿아 있습니다. 정답이 맞는 이유: 옵션 A는 Redshift가 external schema를 통해 Kafka/MSK와 직접 통합한 뒤 materialized view로 데이터를 Redshift 관리 스토리지로 지속적으로 ingest/refresh할 수 있으므로, end-to-end 45초 미만의 최신성 SLA를 가장 잘 충족합니다. 이는 별도의 ingest 파이프라인(Glue/Lambda)을 구축·운영할 필요가 없고, ingest만을 위해 S3에 두 번째 내구성 있는 raw 데이터셋을 저장하지 않아도 됩니다. 운영 대시보드 관점에서도 데이터가(materialized view를 통해) Redshift에 적재되어 낮은 지연으로 쿼리할 수 있습니다. 주요 AWS 기능 / 모범 사례: - external schema를 사용한 Kafka/MSK로부터의 Redshift streaming ingestion(인증은 일반적으로 AWS Secrets Manager 사용). - incremental refresh/continuous ingestion 의미론을 제공하는 materialized view로 1분 미만 가용성 달성. - 구성 요소 최소화: S3 스테이징 없음, 커스텀 consumer 없음, 마이크로 배치 오케스트레이션 없음. - Lambda-per-object 패턴보다 버스트에 대해 더 예측 가능하게 확장되며 small-file 문제를 회피. 흔한 오해: - S3를 랜딩 존으로 사용하는 방식(옵션 B, D)은 흔하지만, 추가 내구성 사본을 만들고(문제에서 회피 요구), 파티셔닝 주기/파일 커밋 타이밍/이벤트 트리거로 인해 지연이 발생해 45초 SLA를 위반할 수 있습니다. - external schema만으로는(옵션 C) 스트리밍 데이터를 Redshift 테이블로 자동 materialize하지 않습니다. 대시보드에 적합한 성능을 위해서는 materialized view 같은 ingest/refresh 메커니즘이 필요합니다. 시험 팁: “sub-minute freshness”, “least operational effort”, “avoid extra durable raw copy” 같은 요구 사항이 보이면, DIY 파이프라인(Glue/Lambda + S3)보다 네이티브 관리형 통합(Redshift streaming ingestion / materialized view)을 우선 고려하세요. 또한 시간 단위 파티션 같은 마이크로 배치 간격이나 이벤트 기반 fan-out을 도입해 운영 복잡도와 지연을 키우는 선택지를 경계하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
운송 물류 스타트업이 차량 텔레메트리와 주문 추적 이벤트를 provisioned capacity로 구성된 Amazon DynamoDB 테이블로 수집하고 있습니다. 트래픽은 매우 예측 가능하며, 매주 평일 06:45부터 10:00(현지 시간)까지 워크로드가 기준 대비 6배로 급증합니다. 반면 금요일 20:00부터 일요일 23:00까지 사용량은 평일 피크의 약 10% 수준으로 떨어집니다. 팀은 피크 시간대에 한 자릿수 밀리초 지연 시간을 유지하면서, 비업무 시간대에는 비용을 최소화해야 합니다. 다음 중 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?
provisioned capacity를 피크 기준으로 영구 설정하면 성능은 보장되지만 비용 효율적이지 않습니다. 10:00 이후와 주말에는 사용량이 크게 감소(평일 피크의 ~10%)하는데도 24/7 최대 RCU/WCU 비용을 지불하게 됩니다. 이는 비업무 시간대 비용 최소화 요구와 정면으로 충돌합니다. 흔히 ‘안전한’ 선택이지만 대부분의 시간에 용량을 낭비합니다.
두 테이블로 분할한다고 해서 비용이 본질적으로 줄거나 지연 시간이 개선되지는 않습니다. 동일한 총 읽기/쓰기 볼륨을 처리하려면 동일한 총 RCU/WCU가 필요하므로, 대체로 비용은 비슷하거나 더 늘고 복잡성만 증가합니다(이중 쓰기/읽기, 라우팅 로직, 테이블별 hot-key 문제 가능성, 운영 오버헤드). 이는 예측 가능한 시간 기반 수요에 대한 표준 DynamoDB 비용 최적화 기법이 아닙니다.
AWS Application Auto Scaling을 통한 scheduled scaling은 예측 가능한 트래픽 패턴에 이상적입니다. 평일 06:45 직전에 RCU/WCU를 증가시켜 스파이크에 대비한 용량을 준비(낮은 지연 시간 유지)하고, 10:00 이후에는 감소시킨 뒤 주말 동안 낮은 용량을 유지하여 비용을 절감할 수 있습니다. 이는 피크 동안의 예측 가능한 성능과 비업무 시간대의 비용 최소화라는 요구 사항을, 피크 요금을 지속적으로 지불하지 않고 정확히 충족합니다.
on-demand capacity mode는 명시적 프로비저닝 없이 트래픽을 자동으로 수용하며 낮은 지연 시간을 유지할 수 있지만, 일반적으로 예측 불가능하거나 변동성이 큰 워크로드에서 가장 비용 효율적입니다. 매우 예측 가능한 일정과 긴 비피크 기간이 있는 경우, provisioned capacity에 scheduled scaling을 결합하는 편이 보통 더 저렴합니다. on-demand는 운영 측면에서는 더 단순하지만, 여기서는 가장 비용 효율적인 선택이 아닙니다.
핵심 개념: 이 문제는 Amazon DynamoDB capacity mode(provisioned vs on-demand)와 예측 가능한 낮은 지연 시간 성능을 유지하면서 비용을 최적화하는 방법을 평가합니다. 또한 DynamoDB를 위한 AWS Application Auto Scaling 기능, 특히 알려진 트래픽 패턴에 대한 scheduled scaling을 중점적으로 다룹니다. 정답이 맞는 이유: 워크로드는 평일 오전 스파이크(기준 대비 6배)와 주말 저점(평일 피크의 ~10%)처럼 명확한 시간 구간을 가진 매우 예측 가능한 패턴입니다. provisioned mode에서는 사용량과 무관하게 할당된 RCU/WCU에 대해 비용을 지불하므로, 가장 비용 효율적인 접근은 필요한 시점에 필요한 만큼만 프로비저닝하는 것입니다. AWS Application Auto Scaling scheduled actions를 사용하면 월–금 06:45 이전에 용량을 선제적으로 증가시켜 스파이크 동안 한 자릿수 밀리초 지연 시간을 보장하고, 10:00 이후에는 용량을 줄인 뒤 주말 동안 낮게 유지하여 비용을 최소화할 수 있습니다. 이는 반응형 스케일링 지연을 피하고 수요 발생 전에 용량이 준비되도록 보장합니다. 주요 AWS 기능: - DynamoDB Provisioned Capacity: 용량이 충분할 때 예측 가능한 성능 제공. - Application Auto Scaling Scheduled Actions: 특정 시간에 테이블 또는 GSI의 RCU/WCU를 조정하는 시간 기반(크론 유사) 스케일링. - (자주 함께 사용) Target Tracking Scaling: 창 내의 소폭 변동에는 여전히 사용할 수 있지만, 알려진 스파이크에는 scheduled actions가 핵심. - 모범 사례: GSI는 별도의 용량을 가지므로, 각 GSI도 독립적으로 스케일링하는 것을 고려. 흔한 오해: - “On-demand가 항상 가장 저렴하다”: on-demand는 예측 불가능하거나 스파이크가 큰 워크로드에 매우 적합하지만, 매우 예측 가능한 패턴에서는 provisioned + scheduled scaling이 일반적으로 더 비용 효율적입니다. - “그냥 최대 용량으로 설정하면 된다”: 성능은 보장하지만 긴 비피크 기간 동안 비용이 낭비됩니다. - “테이블을 나누면 부하가 분산된다”: 필요한 총 용량이 줄지 않으며 운영 복잡성만 증가합니다. 시험 팁: DynamoDB에서 예측 가능한 시간 기반 피크와 비용 최소화 요구가 보이면 “provisioned + scheduled scaling”을 떠올리세요. 트래픽이 미지/예측 불가능하거나 capacity planning을 완전히 피하고 싶을 때 on-demand를 선택합니다. 또한 GSI를 고려하고, throttling 및 지연 시간 증가를 피하기 위해 스파이크 이전에 스케일링을 예약해야 한다는 점을 기억하세요.
한 핀테크 스타트업이 두 개의 private subnet(subnet-10.0.1.0/24 in us-east-1a 및 subnet-10.0.2.0/24 in us-east-1b)에서 Amazon Aurora MySQL-Compatible DB cluster(포트 3306)를 실행하고 있으며, internet gateway로의 route가 없습니다. DB security group(sg-db)은 현재 TCP 3306에서 자기 자신으로부터의 inbound만 허용합니다. 또한 한 개발자가 기본 네트워킹( VPC 없음)으로 AWS Lambda function을 생성하여 행을 insert/update/delete하려고 합니다. 팀은 public internet을 경유하거나 NAT를 사용하지 않고, 운영 오버헤드를 최소화하면서 function이 cluster endpoint에 private하게 연결할 수 있도록 해야 합니다. 요구 사항을 충족하는 단계 조합은 무엇입니까? (두 개 선택)
오답입니다. Aurora에서 “Publicly accessible”을 활성화하는 것은 public 네트워크에서의 접근을 위한 것이며, 일반적으로 public subnet 및 internet gateway로의 라우팅이 필요합니다. public internet을 경유하지 않고 private하게 연결해야 한다는 요구 사항을 위반하며 공격 표면도 증가시킵니다. 또한 cluster는 현재 IGW route가 없는 private subnet에 있으므로, 이 변경만으로는 필요한 연결성이 제공되지 않습니다.
오답입니다. Security group에는 “Lambda function invocations”라는 inbound source selector가 없습니다. Security group rule은 source를 CIDR, prefix list 또는 다른 security group으로 지정합니다. Lambda를 허용하려면 invocation 기반 권한 개념(이는 Lambda permissions에 해당하며 VPC network access가 아님)에 의존하는 대신, Lambda ENI의 security group을 참조(또는 동일 SG 사용)해야 합니다.
정답입니다. 기본 네트워킹으로 생성된 Lambda function은 VPC 외부에서 실행되며 private VPC 전용 endpoint에 직접 도달할 수 없습니다. function이 동일한 VPC 및 private subnet에서 실행되도록 구성하면 Lambda가 해당 subnet에 private IP를 가진 ENI를 생성하여, NAT나 public internet 경유 없이 VPC local network를 통해 Aurora cluster endpoint로 private 라우팅이 가능해집니다.
정답입니다. DB security group은 현재 TCP 3306에서 자기 자신으로부터의 inbound만 허용합니다. 동일한 security group(sg-db)을 Lambda function의 ENI에 연결하고 sg-db에 3306에 대한 self-referencing inbound rule을 유지하면, 최소한의 rule 관리로 Lambda에서 Aurora로의 연결을 허용할 수 있습니다. 이는 범위를 엄격히 제한한 intra-SG 통신을 위한 일반적인 least-ops 패턴입니다.
오답입니다. 이 시나리오에서는 network ACL 변경이 필요하지 않으며 운영 오버헤드를 증가시킵니다. NACL은 stateless이므로 inbound와 outbound rule을 모두 필요로 하고, ephemeral port 처리 및 지속적인 유지보수가 필요합니다. 기본 NACL은 보통 모든 트래픽을 이미 허용하며, 여기서의 실제 차단 요인은 Lambda가 VPC 안에 있지 않다는 점과 DB SG가 self-referenced inbound 트래픽만 허용한다는 점입니다.
핵심 개념: 이 문제는 AWS Lambda에서 private subnet에 있는 Amazon Aurora MySQL DB cluster로의 private 연결을 테스트하며, VPC 네트워킹, security group, 그리고 Lambda가 elastic network interface(ENI)를 통해 VPC 접근 권한을 얻는 방식을 중점적으로 다룹니다. 정답이 맞는 이유: Aurora cluster가 internet gateway로의 route가 없는 private subnet에 있고, 요구 사항에서 public internet 경유 및 NAT를 금지하므로, Lambda function은 private cluster endpoint에 도달하기 위해 동일한 VPC(또는 연결된 네트워크) 내부에서 실행되어야 합니다. Lambda에 VPC access를 구성(옵션 C)하면 Lambda가 지정된 subnet에 ENI를 생성하여 private IP를 부여받고, VPC의 local routing을 통해 Aurora endpoint로 private하게 라우팅할 수 있습니다. 하지만 라우팅만으로는 충분하지 않습니다. DB security group은 현재 TCP 3306에서 자기 자신으로부터의 inbound만 허용합니다. 운영 오버헤드를 최소화하면서 Lambda ENI가 연결할 수 있도록 하려면, 동일한 security group(sg-db)을 Lambda ENI에 연결하고 sg-db에 TCP 3306에 대한 self-referencing inbound rule을 유지하면 됩니다(옵션 D). Lambda와 Aurora가 모두 sg-db를 사용하면, self-referencing rule이 포트 3306에서 sg-db에 연결된 어떤 리소스에서든 sg-db에 연결된 다른 리소스로의 트래픽을 허용합니다. 주요 AWS 기능 및 모범 사례: - Lambda VPC integration: private subnet 및 security group을 선택하면 Lambda가 ENI를 생성하고 관리합니다. - Security group은 stateful이므로, 일반적으로 DB SG에 inbound rule만 필요합니다(응답 트래픽은 자동으로 허용). - SG-to-SG referencing( self-referencing 포함)은 VPC 내부 접근 제어에서 운영 부담이 적은 일반적인 패턴입니다. 흔한 오해: - DB를 “Publicly accessible”로 만드는 것은 요구 사항을 충족하지 않으며 IGW/NAT/public routing이 필요하고, 노출도도 증가합니다. - 이 패턴에서는 network ACL 변경이 거의 필요하지 않습니다. NACL은 stateless이며 운영 복잡도를 증가시킵니다. - Security group에는 “Lambda invocations”라는 native inbound rule 유형이 없습니다. 접근 제어는 IP/CIDR 또는 security group reference로 수행됩니다. 시험 팁: Lambda가 private 리소스(RDS/Aurora, ElastiCache, internal ALB)에 도달해야 할 때의 일반적인 답은 다음과 같습니다: Lambda를 대상에 라우팅 가능한 VPC subnet에 배치한 다음, 대상 SG를 Lambda SG에 대해 열어줍니다(또는 self-reference가 있는 동일 SG 사용). Lambda가 outbound internet access(예: public API 호출)가 필요하지 않다면 NAT는 피합니다.
한 물류 회사는 Amazon Redshift에 shipments라는 1억 2천만 행 테이블을 저장하고 있으며, 이 테이블에는 port_code라는 컬럼이 포함되어 있습니다. 분석가들은 port_code가 'NY' 또는 'LA'로 시작하는 모든 행을 반환하는 SQL 쿼리가 필요합니다. 어떤 쿼리가 이 요구 사항을 충족합니까?
오답입니다. "$(NY|LA).*"는 "$"를 사용하며, 이는 매치를 문자열의 시작이 아니라 끝에 앵커링합니다. 즉, 패턴이 끝 위치에서 발생할 때만 매치하려고 하며(또한 나머지 표현식도 그 의도와 일관되지 않습니다). 따라서 “port_code가 NY 또는 LA로 시작”을 구현하지 못합니다. alternation "(NY|LA)" 자체는 맞지만, 앵커가 잘못되었습니다.
정답입니다. "^(NY|LA).*"는 "^"를 사용해 port_code의 시작에서 매치를 앵커링한 다음, alternation "|"를 통해 "NY" 또는 "LA"를 매치합니다. 뒤의 ".*"는 접두사 이후의 어떤 문자든 허용합니다. 이는 "~" 연산자를 사용할 때 Redshift에서 “NY 또는 LA로 시작”을 표현하는 표준 regex 형태입니다.
오답입니다. "^"(문자열 시작 앵커) 대신 "$"(문자열 끝 앵커)를 사용하므로 “시작”을 강제할 수 없습니다. 또한 "&"는 regex에서 OR 연산자가 아니며, alternation은 "|"입니다. 작성된 그대로는 NY 또는 LA로 시작하는 값을 올바르게 매치하지 못하며 Redshift의 POSIX regex 엔진에서 의도대로 동작하지 않을 수 있습니다.
오답입니다. "^"를 사용해 시작에 앵커링한 점은 맞지만, alternation에 "|" 대신 "&"를 잘못 사용했습니다. “either/or”를 위한 regex alternation은 "|"입니다. "^(NY&LA).*"는 “NY 또는 LA”가 아니라 리터럴 시퀀스 "NY&LA"를 매치하려고 시도하거나(또는 regex 해석에 따라 실패할 수 있으며), 요구 사항을 충족하지 못합니다.
핵심 개념: 이 문제는 정규 표현식을 사용한 Amazon Redshift SQL 패턴 매칭을 테스트합니다. Redshift에서 POSIX 정규 표현식 매치 연산자는 "~"입니다. 대규모 테이블에서 올바른 필터를 작성하려면 regex 앵커(문자열 시작/끝)와 alternation을 이해하는 것이 중요합니다. 정답이 맞는 이유: 요구 사항은 다음과 같습니다: port_code가 'NY' 또는 'LA'로 시작하는 행을 반환. 올바른 regex는 매치를 문자열의 시작에 고정하고 두 접두사 중 하나를 허용해야 합니다. 옵션 B는 "^(NY|LA).*"를 사용하며, 여기서 "^"는 문자열의 시작을 앵커링하고, "(NY|LA)"는 NY 또는 LA를 의미하며, ".*"는 문자열의 나머지 부분을 매치합니다. 이는 “NY 또는 LA로 시작”을 정확히 구현합니다. 주요 AWS 기능 / 모범 사례: Amazon Redshift에서는 WHERE 절에서 regex 조건을 사용할 수 있지만, 더 단순한 연산자보다 CPU 비용이 더 클 수 있습니다. 접두사 확인의 경우 LIKE가 더 명확하고 더 효율적일 수 있습니다(예: port_code LIKE 'NY%' OR port_code LIKE 'LA%'). 하지만 이 문제는 regex 옵션을 구체적으로 제공하므로, 올바르게 앵커링된 regex를 선택하는 것이 목표입니다. 매우 큰 테이블(1억 2천만 행)에서는 테이블 설계도 고려해야 합니다: 적절한 sort key(예: port_code가 자주 필터링된다면 port_code에 설정)와 distribution style을 선택해 스캔 비용을 줄이고, compression encoding을 사용하십시오. 이는 쿼리 성능과 스토리지 레이아웃에 영향을 주기 때문에 Data Store Management 고려 사항입니다. 흔한 오해: 자주 발생하는 실수는 "$"(문자열 끝 앵커)와 "^"(문자열 시작 앵커)를 혼동하는 것입니다. "$"를 사용하면 문자열 끝에서 패턴을 매치하려고 하므로 “시작” 조건을 만족하지 못합니다. 또 다른 오해는 "&"를 OR로 사용하는 것입니다. regex에서 alternation은 "|"이며, "&"는 POSIX regex에서 표준 OR 연산자가 아니므로 “NY 또는 LA”를 표현하지 못합니다. 시험 팁: regex 앵커를 암기하십시오: "^" = starts with, "$" = ends with. “X 또는 Y로 시작”의 경우 "^(X|Y)"를 찾으십시오. 시험에서 LIKE 기반 정답이 제공된다면, regex가 명시적으로 요구되지 않는 한 단순한 접두/접미 매칭에는 LIKE를 선호하십시오. 또한 이 문제가 결과의 정확성인지 성능인지 항상 확인하십시오. 여기서는 regex의 정확성이 핵심입니다.
해양 연구 선박이 24개의 선내 센서 어레이에서 진동, 염분, 자이로(gyro) 판독값을 스트리밍하며, 각 어레이는 12초마다 150 KB의 JSON을 선박 내 게이트웨이를 통해 TLS로 AWS에 전송한다. 운영 작업은 45초마다 Amazon S3 bucket을 폴링하여 집계를 위해 최신 파일을 가져오며, 처리량을 유지하면서 종단 간 지연 시간을 최소화하여 도착 데이터를 S3로 전달하는 수집 설계를 선택해야 한다. S3 bucket으로 데이터를 가장 낮은 지연 시간으로 전달할 솔루션은 무엇인가?
이것이 가장 좋은 정답인 이유는 Kinesis Data Firehose가 최소한의 운영 오버헤드와 near-real-time 동작으로 streaming data를 Amazon S3에 전달하도록 설계된 AWS 서비스이기 때문입니다. 유입 속도는 약 300 KB/second에 불과하며, 이는 Kinesis Data Streams와 Firehose의 처리 용량 범위 내에 충분히 들어갑니다. 쓰기 전에 명시적으로 10초 동안 buffering하는 custom KCL 옵션과 비교하면, Firehose의 managed delivery 경로가 선택지 중 가장 낮은 지연 시간을 제공하는 유효한 S3 적재 옵션입니다. 또한 custom consumer application을 구축, 확장, checkpointing, error-handling하는 복잡성도 피할 수 있습니다.
이 옵션은 아키텍처적으로 잘못되었습니다. Amazon Kinesis Data Streams는 자체적으로 record를 Amazon S3에 직접 전달하지 않습니다. KCL application, AWS Lambda 또는 다른 processing service 같은 consumer가 stream에서 읽고 데이터를 S3에 써야 합니다. 처리량 측면에서는 4 shards면 충분하지만, S3로 전달하는 메커니즘이 없기 때문에 이 옵션은 유효하지 않습니다. 시험에서는 consumer 없이 Streams가 직접 S3에 쓴다고 주장하는 답은 제거해야 합니다.
이것은 동작 가능한 아키텍처이지만, 제시된 선택지 중 가장 낮은 지연 시간의 선택은 아닙니다. 이 옵션은 KCL consumer가 10초 application buffer를 두고 S3에 쓴다고 명시하고 있으므로, record가 S3 object가 되기 전까지 최대 그만큼 기다리게 됩니다. 또한 custom consumer는 scaling, checkpointing, retry, object naming, failure handling 측면의 운영 부담도 추가합니다. Firehose는 S3 delivery를 위해 특별히 설계되었고 이러한 명시적인 10초 application 지연을 피하므로, 이 옵션은 최선의 정답이 아닙니다.
이 옵션은 데이터를 S3에 적재하기 전에 stream transformation, enrichment 또는 analytics가 필요하다는 요구 사항이 없는데도 Amazon Managed Service for Apache Flink를 추가합니다. 또한 Firehose를 60초 buffer interval로 구성하고 있어, 다른 유효한 선택지보다 end-to-end latency를 분명히 증가시킵니다. 추가 processing layer는 명시된 비즈니스 요구를 해결하지 않으면서 복잡성과 잠재적 지연만 더합니다. 따라서 목표가 S3로 가장 낮은 지연 시간의 delivery일 때는 적절하지 않습니다.
핵심 개념: 이 문제는 적당한 수집 속도를 유지하면서 streaming data를 Amazon S3에 가장 낮은 지연 시간으로 적재하는 방법을 테스트합니다. 핵심 비교 대상은 streaming data를 S3로 전달하도록 특별히 설계된 Amazon Kinesis Data Firehose와, S3 object를 쓰기 전에 record를 batch 처리해야 하는 Amazon Kinesis Data Streams의 custom consumer입니다. 정답인 이유: 선박은 12초마다 24 arrays × 150 KB를 생성하므로, 총 약 300 KB/second입니다. 이 처리량은 Kinesis 서비스에서 쉽게 지원됩니다. S3로 전달할 때 Firehose는 S3로 near-real-time delivery를 위해 특별히 설계된 managed service이며, 시간과 크기를 기준으로 buffering할 수 있습니다. 기본 buffering을 사용하더라도, 쓰기 전에 명시적으로 10초를 기다리는 custom KCL consumer보다 더 낮은 지연 시간을 제공합니다. 따라서 제시된 옵션 중에서는 Kinesis Data Streams + Firehose 패턴이 가장 낮은 지연 시간의 S3 delivery에 가장 적합합니다. 주요 기능: Kinesis Data Streams는 streaming record를 위한 내구성 있고 확장 가능한 ingestion을 제공합니다. Kinesis Data Firehose는 consumer application을 직접 구축하고 운영할 필요 없이 S3로 기본적으로 전달하며, batching, retry, scaling을 자동으로 처리합니다. 이를 통해 운영 오버헤드를 줄이면서도 near-real-time delivery를 제공합니다. 흔한 오해: 흔한 함정은 custom KCL application이 더 많은 제어를 제공하므로 항상 더 낮은 지연 시간을 가진다고 가정하는 것입니다. 실제로는 S3에 효율적으로 쓰기 위해서도 여전히 batching이 필요하며, 해당 옵션은 쓰기 전에 10초 application buffer를 명시하고 있으므로, 이 맥락에서 S3 delivery를 위한 Firehose의 기본 저지연 buffering 동작보다 느립니다. 또 다른 오해는 Kinesis Data Streams가 consumer 없이 직접 S3에 쓸 수 있다고 생각하는 것인데, 이는 사실이 아닙니다. 시험 팁: 대상지가 S3이고 문제에서 나열된 아키텍처 중 가장 낮은 지연 시간을 묻는다면, 다른 옵션이 더 짧고 유효한 buffering 구성을 명확히 지정하지 않는 한 native managed delivery service를 우선 고려하세요. 또한 옵션이 아키텍처적으로 완전한지도 확인하세요. Kinesis Data Streams만으로는 S3에 전달되지 않습니다. transformation 요구 사항이 없는데도 Flink 같은 불필요한 processing layer를 추가하는 솔루션은 제거하세요.
IoT 분석 팀은 두 개의 AWS 계정에 걸쳐 여러 Amazon S3 버킷으로 유입되는 텔레메트리 파일을 위해 중앙 집중식 AWS Glue Data Catalog를 유지 관리하고 있으며, 사용자 지정 코드나 장시간 실행되는 인프라를 구축하지 않고도 새 객체가 쓰여진 후 10분 이내에 카탈로그를 증분 방식으로 업데이트된 상태로 유지해야 합니다. S3 이벤트 알림은 이미 카탈로그 업데이트 전용 Amazon SQS standard queue로 ObjectCreated 이벤트를 게시하도록 구성되어 있습니다. 이러한 요구 사항을 최소 운영 오버헤드로 충족하기 위해 팀이 수행해야 할 단계 조합은 무엇입니까? (두 개 선택)
정답입니다. AWS Glue는 Amazon S3용 event-driven crawlers를 지원하며 Amazon SQS를 통해 전달되는 object event notifications를 소비합니다. S3 buckets가 이미 전용 SQS queue로 ObjectCreated events를 게시하고 있으므로, 이는 사용자 지정 코드 없이 새로운 쓰기에 반응해야 한다는 요구 사항을 직접 충족합니다. 이는 운영 오버헤드를 최소화하는 managed integration이며, 필요한 시간 창 내에서 catalog를 최신 상태로 유지할 수 있습니다.
정답입니다. crawler는 모든 데이터를 반복적으로 recrawl하는 대신 incremental catalog maintenance를 수행하도록 구성되어야 합니다. crawler의 incremental update 동작을 사용하면 새로 추가된 folders, partitions 또는 변경된 metadata만 처리하므로 runtime이 줄어들고 10분 freshness target을 충족하는 데 도움이 됩니다. 이는 운영 부담이 적은 Glue-native 솔루션의 일부이며 대규모 telemetry datasets에 대한 불필요한 전체 스캔을 방지합니다.
오답입니다. AWS Lambda는 serverless이지만, 이 옵션은 SQS messages를 파싱하고, S3 object events를 해석하며, Glue Data Catalog APIs를 올바르게 호출하기 위한 사용자 지정 코드가 필요합니다. 그러면 여러 accounts 전반에서 retries, idempotency, schema evolution, error handling에 대한 지속적인 유지 관리가 발생합니다. 문제는 명시적으로 사용자 지정 코드를 구축하지 않고 최소 운영 오버헤드로 해결하는 방안을 요구합니다.
오답입니다. crawler를 수동으로 시작하는 것은 운영 집약적이며 새로운 객체가 기록될 때마다 10분 이내 업데이트를 안정적으로 보장할 수 없습니다. 이는 여러 buckets와 accounts 전반에서 빈번하게 도착하는 telemetry에 대해 확장되지 않습니다. 이는 자동화 및 낮은 오버헤드 요구 사항과 직접적으로 충돌합니다.
오답입니다. AWS Step Functions는 orchestration 복잡성을 추가하며, 추가적인 사용자 지정 작업이나 integrations 없이는 Data Catalog를 자체적으로 업데이트할 수 없습니다. 팀은 SQS messages를 처리하기 위해 state machines, permissions, retries, 그리고 아마도 Lambda functions나 기타 구성 요소를 관리해야 합니다. 이는 native Glue crawler event-driven capability를 사용하는 것보다 운영 부담이 더 큽니다.
핵심 개념: 이 문제는 가장 관리형이며 운영 부담이 적은 방식으로 새로운 S3 객체에 대해 AWS Glue Data Catalog를 최신 상태로 유지하는 것에 관한 것입니다. 핵심은 사용자 지정 처리 로직을 구축하는 대신, Amazon SQS의 event-driven crawling과 incremental catalog updates를 지원하는 AWS Glue crawler 기능을 사용하는 것입니다. 정답인 이유: event-driven crawler는 SQS queue의 기존 S3 ObjectCreated notifications를 사용할 수 있으며, crawler를 incremental updates로 구성하면 새로 추가된 데이터나 partitions만 효율적으로 처리합니다. 주요 기능: AWS Glue는 Amazon SQS를 event source로 사용하는 S3 event-driven crawlers를 지원하며, crawlers는 전체 recrawl을 수행하는 대신 Data Catalog를 incrementally update하도록 구성할 수 있습니다. 흔한 오해: scheduled crawler만 사용하는 방식은 event-driven이 아니며 freshness target을 놓치거나 불필요한 반복 스캔을 유발할 수 있고, Lambda 또는 Step Functions는 사용자 지정 코드와 더 많은 운영 책임을 추가합니다. 시험 팁: 문제에서 사용자 지정 코드 없음과 최소 운영 오버헤드를 강조하면 orchestration이나 맞춤형 API updates보다 SQS에서 Glue crawler가 이벤트를 소비하고 crawler recrawl/update settings를 사용하는 native managed integrations를 우선 고려하세요.
학습 기간: 1 month
문제 제대로 이해하고 풀었으면 여러분들도 합격 가능할거에요! 화이팅
학습 기간: 1 month
I passed the AWS data engineer associate exam. Cloud pass questions is best app which help candidate to preparer well for any exam. Thanks
학습 기간: 1 month
시험하고 문제 패턴이 비슷
학습 기간: 2 months
813/1000 합격했어요!! 시험하고 문제가 유사한게 많았어요
학습 기간: 1 month
해설까지 있어서 공부하기 좋았어요. 담에 또 올게요
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.