Data Preparation for ML and AI practice questions

DynamoDB export to Amazon S3 builds full or incremental exports from point-in-time recovery data without touching table capacity.

DynamoDB's export to S3 feature requires point-in-time recovery to be enabled and writes the table's data to an S3 prefix in DynamoDB JSON or Amazon Ion format. Because it reads from the continuous backup, it uses no read capacity and needs no paging code. The export has no built-in schedule, so a scheduler such as EventBridge Scheduler starts it each week. A Glue scan job also lands the data in S3, but it reads the live table and competes with production. Streams miss existing items, and a restored backup is another table rather than S3 data.

1. Note the constraints: full copy in S3, no read capacity, no paging code.
2. Recall that table exports read from point-in-time recovery backups.
3. Eliminate scans (consume capacity) and streams (miss existing items).
4. Enable PITR and start an export to S3 each week from a scheduler.

Exam tip: Full DynamoDB copy in S3 without read capacity: PITR plus export to S3.

RDS and Aurora snapshot export to Amazon S3 writes table data as Apache Parquet without querying the running instance.

Exporting a DB snapshot to S3 extracts data from the snapshot, so the production instance serves no extra queries, and the output is Parquet, which Athena can query efficiently. pg_dump and a DMS full load both read from the production instance. A read replica does not put columnar files in S3 at all.

1. Note the two requirements: columnar files in S3 and no queries on production.
2. Recall that snapshot export works from a snapshot and outputs Parquet.
3. Eliminate options that read from the live instance.
4. Choose snapshot export to S3.

Exam tip: RDS data to S3 as Parquet without touching the instance: export a snapshot.

S3 Intelligent-Tiering suits data with unknown or changing access patterns: it tiers objects automatically with no retrieval fees.

When access patterns are unpredictable, a fixed lifecycle transition guesses wrong for some objects. Intelligent-Tiering monitors access per object and moves it between tiers, keeping millisecond access in its default tiers, with a small monitoring charge but no retrieval fees. Standard-IA and One Zone-IA charge per-GB retrieval, and Glacier Flexible Retrieval is not readable in milliseconds.

1. Note the access pattern: heavy at first, then unpredictable.
2. Note the constraints: millisecond reads and no retrieval charges.
3. Eliminate IA classes (retrieval fees) and Glacier Flexible Retrieval (restore delay).
4. Choose S3 Intelligent-Tiering.

Exam tip: Unpredictable access, millisecond reads, no retrieval fees: S3 Intelligent-Tiering.

FSx for Lustre as a SageMaker AI training data source: S3-linked, high-throughput, VPC-attached, single-AZ.

FSx for Lustre is built for throughput-bound training: it serves files in parallel at high throughput, links to an S3 bucket through a data repository association, and is mounted by the job at start-up regardless of dataset size. Two configuration facts come with it: the training job must run in a VPC, and because the file system is in one Availability Zone, the job's subnet should be in that zone. EFS in bursting mode is not the high-throughput choice, larger EBS volumes keep the per-job download, and a directory bucket read in File mode still copies the data for every job.

1. Identify the bottleneck: data loading from S3 on every epoch and job.
2. Pick the storage built for high-throughput training reads that syncs with S3.
3. Recall its networking requirement: a VPC subnet in the file system's Availability Zone.
4. Eliminate options that keep a full download per job or lack throughput.

Exam tip: GPU-starved training on S3 data: FSx for Lustre linked to the bucket, job in a VPC subnet in its AZ.

Compliance storage on S3: Object Lock compliance vs governance mode, and SSE-KMS customer managed keys vs SSE-S3.

Two separate requirements need two controls. For immutability that even administrators cannot bypass, Object Lock must use compliance mode; governance mode can be bypassed with a specific permission. For key control and auditing, SSE-KMS with a customer managed key gives the company the key policy and logs every encrypt and decrypt call in CloudTrail; SSE-S3 keys are managed by S3. Versioning alone does not stop deletion.

1. Split the requirements: key control with audit, and undeletable retention.
2. For keys, choose a customer managed KMS key over S3 managed keys.
3. For retention, compare Object Lock modes: only compliance mode binds administrators.
4. Reject versioning, which does not block deletes.

Exam tip: No one can delete it: Object Lock compliance mode. Company controls and audits keys: SSE-KMS customer managed key.

Kinesis Data Streams partition keys: a low-cardinality key creates hot shards that more shards cannot fix.

Kinesis hashes each partition key to one shard, and each shard has its own write limit. With three region codes, writes land on at most three shards, so one shard throttles while the stream as a whole is mostly idle. Adding shards, by count or through on-demand mode, does not change where a given key lands. Enhanced fan-out is a consumer-side feature. Spreading writes with a high-cardinality key fixes the imbalance.

1. Note the symptom: throttling on one shard while total traffic is low.
2. Look at the partition key: three distinct values.
3. Recall that one key value always maps to one shard.
4. Choose a high-cardinality partition key.

Exam tip: Throttling on one shard with spare stream capacity: fix the partition key, not the shard count.