연습 문제

문제 1

(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에서 무엇을 볼 수 있는지를 제어한다는 점을 기억하세요.

문제 2

한 미디어 분석 회사가 온프레미스 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/처리 패턴을 명시적으로 요구할 때만 선택하라.

문제 3

데이터 엔지니어는 주거용 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를 사용하여 데이터 증가에 따른 비용과 성능을 제어하는 것입니다.

문제 4

(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/런타임에 관한 것이지 계획 수립에 관한 것이 아닙니다.

문제 5

모빌리티 분석 스타트업이 차량 텔레메트리를 평균 초당 2,800개의 JSON 이벤트(버스트 시 최대 11,000 events/s, 이벤트당 약 1.8 KB)로 Amazon MSK 클러스터에 수집하고 있으며, 운영 대시보드를 위해 이 데이터를 Amazon Redshift에서 1분 미만의 최신성(End-to-end SLA: 45초 미만)으로 사용할 수 있어야 합니다. 또한 스트리밍 소스 외부에 추가적인 내구성 있는 원시(raw) 사본을 두지 않아 스토리지 비용을 최적화하고 운영 오버헤드를 최소화하려고 합니다. 다음 중 최소한의 운영 노력으로 이러한 요구 사항을 가장 잘 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 스트리밍 소스(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를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

운송 물류 스타트업이 차량 텔레메트리와 주문 추적 이벤트를 provisioned capacity로 구성된 Amazon DynamoDB 테이블로 수집하고 있습니다. 트래픽은 매우 예측 가능하며, 매주 평일 06:45부터 10:00(현지 시간)까지 워크로드가 기준 대비 6배로 급증합니다. 반면 금요일 20:00부터 일요일 23:00까지 사용량은 평일 피크의 약 10% 수준으로 떨어집니다. 팀은 피크 시간대에 한 자릿수 밀리초 지연 시간을 유지하면서, 비업무 시간대에는 비용을 최소화해야 합니다. 다음 중 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 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 및 지연 시간 증가를 피하기 위해 스파이크 이전에 스케일링을 예약해야 한다는 점을 기억하세요.

문제 7

(2개 선택)

한 핀테크 스타트업이 두 개의 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하게 연결할 수 있도록 해야 합니다. 요구 사항을 충족하는 단계 조합은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 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는 피합니다.

문제 8

한 물류 회사는 Amazon Redshift에 shipments라는 1억 2천만 행 테이블을 저장하고 있으며, 이 테이블에는 port_code라는 컬럼이 포함되어 있습니다. 분석가들은 port_code가 'NY' 또는 'LA'로 시작하는 모든 행을 반환하는 SQL 쿼리가 필요합니다. 어떤 쿼리가 이 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 정규 표현식을 사용한 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의 정확성이 핵심입니다.

문제 9

해양 연구 선박이 24개의 선내 센서 어레이에서 진동, 염분, 자이로(gyro) 판독값을 스트리밍하며, 각 어레이는 12초마다 150 KB의 JSON을 선박 내 게이트웨이를 통해 TLS로 AWS에 전송한다. 운영 작업은 45초마다 Amazon S3 bucket을 폴링하여 집계를 위해 최신 파일을 가져오며, 처리량을 유지하면서 종단 간 지연 시간을 최소화하여 도착 데이터를 S3로 전달하는 수집 설계를 선택해야 한다. S3 bucket으로 데이터를 가장 낮은 지연 시간으로 전달할 솔루션은 무엇인가?

문제 분석

핵심 개념: 이 문제는 적당한 수집 속도를 유지하면서 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를 추가하는 솔루션은 제거하세요.

문제 10

(2개 선택)

IoT 분석 팀은 두 개의 AWS 계정에 걸쳐 여러 Amazon S3 버킷으로 유입되는 텔레메트리 파일을 위해 중앙 집중식 AWS Glue Data Catalog를 유지 관리하고 있으며, 사용자 지정 코드나 장시간 실행되는 인프라를 구축하지 않고도 새 객체가 쓰여진 후 10분 이내에 카탈로그를 증분 방식으로 업데이트된 상태로 유지해야 합니다. S3 이벤트 알림은 이미 카탈로그 업데이트 전용 Amazon SQS standard queue로 ObjectCreated 이벤트를 게시하도록 구성되어 있습니다. 이러한 요구 사항을 최소 운영 오버헤드로 충족하기 위해 팀이 수행해야 할 단계 조합은 무엇입니까? (두 개 선택)

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(8)

다른 모의고사

Practice Test #2

지금 학습 시작하기