AWS 1: Data Preparation for ML and AI: 308 practice questions

12 of the 308 1: Data Preparation for ML and AI questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Consume transaction records continuously and write feature: Which TWO ingestion designs meet these requirement

Select two. More than one option is correct — every correct one is ticked below.

1. Refresh the online profile features from the complete S3 dataset each Sunday.

   A weekly refresh uses a supported ingestion pattern but leaves changed profiles stale beyond the stated hourly deadline.
2. Consume transaction records continuously and write feature updates with PutRecord. ✓

   A continuously running consumer can transform transaction events and update online feature records within the required latency.
3. Deliver transaction records to S3 and process the accumulated files every night.

   Nightly processing is executable but cannot update transaction features within seconds of receiving each event.
4. Run a daily Athena aggregation of transactions and load its results into the online store.

   Daily aggregated features can be ingested, but that schedule cannot satisfy the seconds-level update requirement.
5. Run an hourly Processing job that converts profile rows into feature records. ✓

   The scheduled job reads the Parquet dataset, transforms its rows, and ingests feature records on the required hourly cadence.

Continuous transaction ingestion and hourly profile processing satisfy the two independent freshness requirements without confusing files with feature records.

2. Store encrypted Parquet objects in S3 and scan only: Which approach best meets these requirements?

1. Store encrypted Parquet files on EFS for shared training access.

   EFS supports shared filesystem access, but the stated durable analytical object workload is better suited to S3.
2. Store encrypted CSV files in S3 and scan every field during training.

   CSV is row-oriented, and scanning every field prevents efficient column pruning for selective analytical queries.
3. Store encrypted Parquet objects in S3 and scan only required columns. ✓

   S3 provides durable object storage, Parquet supports column pruning, and server-side encryption protects the objects.
4. Store encrypted Parquet files on EBS volumes attached to training instances.

   EBS is attached block storage and is less suitable than S3 for a durable, shared, historical object dataset.

Encrypted Parquet in S3 supports durable storage, column pruning, and server-side encryption.

3. Distribute objects across additional prefixes and adjust: What should the engineer do first?

1. Convert all objects to EFS files without changing the ingestion readers.

   Changing storage services alone does not diagnose the concentrated request pattern or guarantee compatible reader behavior.
2. Distribute objects across additional prefixes and adjust the reader concurrency gradually. ✓

   Spreading requests across prefixes and tuning concurrency addresses concentrated request load while validating ingestion behavior.
3. Increase the model endpoint instance count before investigating ingestion metrics.

   Endpoint capacity does not resolve S3 prefix throttling occurring before data reaches the model.
4. Increase worker memory because throttling responses indicate insufficient processing memory.

   Throttling responses identify service request pressure, not a worker-memory shortage, especially with normal CPU and object sizes.

Retries and throttling on one prefix indicate concentrated S3 request pressure; redistribute objects and tune concurrency.

4. Use Kinesis Data Streams with each camera assigned: Which design meets these requirements?

1. Write images to EBS and scan the volume periodically.

   EBS does not provide ordered stream records, retention-aware consumer progress, or managed consumer scaling.
2. Use Kinesis Data Streams with each camera assigned a stable partition key. ✓

   A consistent partition key preserves ordering for a camera within its shard; checkpoints support replay and other shards allow parallel consumption.
3. Store images in EFS and have workers watch for new files.

   EFS provides shared files, not shard ordering, stream retention, or consumer checkpointing.
4. Place images in S3 and repeatedly list the prefix.

   S3 polling adds discovery delay and does not provide native stream ordering or consumer checkpoint semantics.

Kinesis Data Streams supplies ordered, retained records and scalable consumers.

5. Apache Parquet: Which format should be used for the training dataset?

1. Apache Parquet ✓

   Parquet is columnar, enabling efficient column pruning when training jobs read only selected metadata fields.
2. JSON Lines

   JSON Lines is flexible for records but remains less efficient than Parquet for repeated selective analytical scans.
3. Apache ORC with every field duplicated as a separate file

   ORC can support columnar analytics, but duplicating every field into separate files adds unnecessary complexity and storage management.
4. CSV

   CSV is row-oriented, so selecting a few columns generally still requires reading complete rows from each file.

Parquet supports column pruning, reducing data read when training jobs select only portions of structured metadata.

6. Use a left join from preferences to purchase history: Select TWO actions.

Select two. More than one option is correct — every correct one is ticked below.

1. Append both datasets by row position and select the first record for each output row.

   Appending by position does not establish customer relationships and can associate unrelated records incorrectly.
2. Use a left join from preferences to purchase history and resolve duplicate purchase records. ✓

   A left join preserves customers lacking purchases, while deduplication prevents multiple output rows per customer.
3. Use an inner join and retain only customers appearing in both sources.

   An inner join removes customers without purchases, violating the requirement to retain all preference records.
4. Normalize identifier casing and formatting before joining the datasets. ✓

   Standardizing join keys makes logically identical customer identifiers match across sources despite capitalization and formatting differences.
5. Join on the original identifiers and let unmatched records receive null recommendations.

   Unnormalized identifiers cause false mismatches, so valid cross-source customer relationships remain unresolved.

Normalize keys before joining, then use a left join with deduplication to preserve customers and produce one row each.

7. Use an Amazon OpenSearch Service vector index configured: Which configuration is most appropriate?

1. Create a 512-dimensional index and truncate each 768-dimensional embedding before insertion.

   Truncation changes the representation and conflicts with the required embedding dimensionality and model semantics.
2. Use an Amazon OpenSearch Service vector index configured for 768 dimensions and cosine similarity. ✓

   OpenSearch supports vector indexing, and matching dimensions and cosine similarity align the index with generated embeddings.
3. Use an exact Euclidean-distance scan because similarity configuration does not affect retrieval quality.

   Distance metric affects nearest-neighbor results, and exhaustive scans do not meet the scalable approximate-search requirement.
4. Store vectors as JSON objects in Amazon S3 and compare every object during each query.

   S3 stores objects but does not automatically provide scalable approximate nearest-neighbor vector search over those objects.

Configure a vector index with the model’s 768 dimensions and cosine similarity for scalable approximate retrieval.

8. Store source objects in S3 with tenant-scoped IAM access: Which design should be used?

1. Store all binary content as rows in a DynamoDB table with one item per byte.

   Byte-level item storage creates inefficient fragmentation and does not suit independent large-object management.
2. Place every tenant’s files in one EBS volume and separate access through directory names.

   EBS is attached block storage and does not naturally provide scalable shared object retrieval for multiple tenants.
3. Convert images and audio into CSV rows before storing them in Amazon S3.

   CSV is unsuitable for preserving arbitrary binary media as independently retrievable native objects.
4. Store source objects in S3 with tenant-scoped IAM access and linked structured metadata. ✓

   S3 retains the original files, linked metadata supports indexing, and tenant-scoped permissions enforce access rather than relying on names alone.

S3 natively stores heterogeneous objects and supports tenant-oriented organization and batch retrieval without shared filesystem requirements.

9. Configure both stores and stream hourly updates by calling: Which configuration is appropriate?

1. Configure only the online store and export its latest records weekly for training.

   The online store retains only the latest records, so it cannot provide the complete historical record required for training.
2. Configure only the offline store and query it directly for millisecond online inference.

   The offline store supports historical training and batch workloads, not low-latency online feature reads.
3. Configure both stores and stream hourly updates by calling PutRecord. ✓

   The online store serves current values, the offline store retains history, and PutRecord supports streaming feature updates.
4. Create separate online-only feature groups for teams and duplicate hourly updates manually.

   Separate online-only groups add duplication and still fail to provide the shared historical offline store needed for weekly training.

Use both stores and stream hourly updates with PutRecord for current serving and historical training.

10. Run a SageMaker batch transform job using the S3 input: Which AWS approach should be used?

1. Deploy a persistent SageMaker real-time endpoint and invoke it once for every document.

   A persistent endpoint is unnecessary for scheduled asynchronous inference and adds ongoing serving infrastructure.
2. Upload all documents into a Feature Store online store before invoking the model.

   Feature Store online storage is intended for current feature retrieval, not large document batch inference.
3. Run a SageMaker batch transform job using the S3 input and output locations. ✓

   Batch Transform processes large S3 datasets without a persistent endpoint and writes corresponding inference outputs to S3.
4. Run each document through a Lambda function and store individual predictions in EBS.

   This creates unnecessary per-document orchestration and EBS is not the required durable shared output destination.

SageMaker Batch Transform is designed for large S3 datasets, asynchronous inference, and output written to S3.

11. Ingest streaming updates by calling the synchronous: Which TWO actions satisfy these requirements?

Select two. More than one option is correct — every correct one is ticked below.

1. Store feature definitions only in each consuming model’s training notebook.

   Notebook-local definitions reduce sharing and can create inconsistent transformations between training and inference.
2. Run a nightly Processing job that batches all sensor readings into the feature group.

   Nightly batching delays feature availability and therefore fails the requirement for updates as soon as they are detected.
3. Ingest streaming updates by calling the synchronous PutRecord API. ✓

   PutRecord supports streaming ingestion and makes newly detected feature values available without waiting for batch processing.
4. Create a SageMaker Feature Store feature group with both online and offline stores. ✓

   The online store supports latest low-latency values, while the offline store preserves historical records for training.
5. Configure only an offline store and query historical records during every inference request.

   An offline store is intended for training and batch inference, not low-latency real-time feature retrieval.

Use both Feature Store stores and PutRecord so current values serve inference while history supports training.

12. Use SageMaker Batch Transform with SplitType set to Line: Which configuration should the engineer choose?

1. Set SplitType to None so each complete file is sent in one request.

   Whole-file requests can exceed payload expectations and do not exploit the stated line-delimited record structure.
2. Deploy a persistent real-time endpoint and send each transcript in an individual request.

   A persistent endpoint adds unnecessary operational overhead when the workload is scheduled, asynchronous, and stored in S3.
3. Use SageMaker Batch Transform with SplitType set to Line and write results to Amazon S3. ✓

   Batch Transform handles large S3 datasets without a persistent endpoint, and line splitting preserves corresponding record order.
4. Use a streaming transform with AssembleWith set to Line to merge all files.

   AssembleWith concatenates records within output files; it does not merge separate input files or replace Batch Transform.

Batch Transform with line splitting fits asynchronous S3 inference and maintains input-to-output record ordering.

Other AWS domains

• 2: ML Model and Foundation Model (FM) Development — 264 questions →
• 3: Deployment and Orchestration of ML and AI Workflows — 264 questions →
• 4: Operating, Monitoring, and Securing ML and AI Solutions — 264 questions →
• All 1100 AWS questions →
• AWS certification: requirements, cost and exam format →