Scenario practice questions

A team built a SageMaker Pipeline that includes a training step and a model evaluation step. They want to automatically register a model in SageMaker Model Registry only if the evaluation metric (accuracy) exceeds 0.9. Which pipeline step should be used to implement this conditional logic?

Trap 1: RegisterModel step

RegisterModel registers a model version unconditionally once reached; it holds no conditional logic to check accuracy against 0.9. It is tempting because registration is the desired outcome, but that would be correct only when the pipeline already guarantees the metric threshold upstream.

Trap 2: Processing step

A Processing step runs a containerised script over data or artefacts; it cannot branch pipeline execution on a condition. It is tempting because it can read evaluation output, but that would be correct for feature engineering or post-processing, not for gating registration with ConditionStep logic.

Trap 3: Transform step

A Transform step runs batch inference against a model and produces predictions; it cannot evaluate a metric or branch the pipeline. It is tempting because it consumes a trained model, which would be correct for generating batch predictions, not for conditionally registering a model.

A
RegisterModel step
Why it fails: RegisterModel registers a model version unconditionally once reached; it holds no conditional logic to check accuracy against 0.9. It is tempting because registration is the desired outcome, but that would be correct only when the pipeline already guarantees the metric threshold upstream.
B
Condition step
A condition step evaluates a property such as the evaluation metric against a threshold and gates downstream steps accordingly. Placing the register step inside its true branch means registration occurs only when accuracy exceeds 0.9, exactly as the stem requires.
C
Processing step
Why it fails: A Processing step runs a containerised script over data or artefacts; it cannot branch pipeline execution on a condition. It is tempting because it can read evaluation output, but that would be correct for feature engineering or post-processing, not for gating registration with ConditionStep logic.
D
Transform step
Why it fails: A Transform step runs batch inference against a model and produces predictions; it cannot evaluate a metric or branch the pipeline. It is tempting because it consumes a trained model, which would be correct for generating batch predictions, not for conditionally registering a model.

Question 2mediummultiple choice

A company uses SageMaker JumpStart to deploy a foundation model for a summarization task. They want to minimize costs while still meeting a latency requirement of under 2 seconds. Which option should they consider?

Trap 1: Deploy the model on a serverless endpoint

Serverless endpoints cold-start and queue requests, so sub-two-second latency is not guaranteed for a foundation model. It is tempting because serverless bills per invocation and scales to zero, making it the right choice for intermittent, latency-tolerant summarisation where cost minimisation outweighs response-time guarantees.

Trap 2: Enable auto-scaling to handle variable traffic

Auto-scaling adjusts instance count to traffic volume; it does not reduce the per-request latency of a single inference, so the two-second requirement is unaddressed. It is tempting because auto-scaling genuinely cuts cost under variable load, and would be correct where traffic fluctuates and the latency target is already met by the instance type.

Trap 3: Use the largest GPU instance to ensure fast inference

A larger GPU instance raises hourly cost without addressing the latency target, since summarisation latency depends on model size, token count and endpoint configuration rather than raw GPU capacity alone. It is tempting because oversized instances do reduce per-token inference time, and would suit throughput-heavy batch workloads where latency dominates and cost is secondary.

A
Use SageMaker Inference Recommender to select the cheapest instance that meets latency
SageMaker Inference Recommender runs automatic load tests across instance types and returns the cheapest instance satisfying the sub-2-second latency constraint, directly optimising the cost-versus-latency trade-off. Manual instance selection risks over-provisioning or breaching latency, so this satisfies both the cost-minimisation and latency requirements in the stem.
B
Deploy the model on a serverless endpoint
Why it fails: Serverless endpoints cold-start and queue requests, so sub-two-second latency is not guaranteed for a foundation model. It is tempting because serverless bills per invocation and scales to zero, making it the right choice for intermittent, latency-tolerant summarisation where cost minimisation outweighs response-time guarantees.
C
Enable auto-scaling to handle variable traffic
Why it fails: Auto-scaling adjusts instance count to traffic volume; it does not reduce the per-request latency of a single inference, so the two-second requirement is unaddressed. It is tempting because auto-scaling genuinely cuts cost under variable load, and would be correct where traffic fluctuates and the latency target is already met by the instance type.
D
Use the largest GPU instance to ensure fast inference
Why it fails: A larger GPU instance raises hourly cost without addressing the latency target, since summarisation latency depends on model size, token count and endpoint configuration rather than raw GPU capacity alone. It is tempting because oversized instances do reduce per-token inference time, and would suit throughput-heavy batch workloads where latency dominates and cost is secondary.

Question 3hardmultiple choice

A machine learning team is developing a deep learning model for image classification. They observe that the training loss decreases rapidly but the validation loss starts increasing after a few epochs. Which strategy should they implement to address this issue?

Trap 1: Increase the batch size

Larger batch sizes can stabilize training but are less effective against overfitting; they may even reduce generalization.

Trap 2: Add more convolutional layers

Adding more layers increases model capacity, likely increasing overfitting further.

Trap 3: Increase the learning rate

Increasing learning rate may cause divergence and does not address overfitting.

A
Increase the batch size
Why it fails: Larger batch sizes can stabilize training but are less effective against overfitting; they may even reduce generalization.
B
Add more convolutional layers
Why it fails: Adding more layers increases model capacity, likely increasing overfitting further.
C
Increase the learning rate
Why it fails: Increasing learning rate may cause divergence and does not address overfitting.
D
Apply dropout regularization
Dropout randomly deactivates neurons during each training pass, which directly counteracts the overfitting causing validation loss to rise while training loss falls. By forcing the network to learn redundant, generalisable features rather than memorising the training images, it restores the validation-loss trajectory the stem requires.

Question 4easymultiple choice

A machine learning engineer at a retail company is monitoring a production model that predicts inventory demand. The model's prediction accuracy has dropped significantly over the past week. The engineer checks the model's input data and notices a new product category was introduced with a different distribution. Which concept is most likely causing the performance degradation?

Trap 1: Concept drift

Concept drift concerns the relationship between inputs and the target changing, whereas the stem describes a new input category with a different distribution — covariate shift. Concept drift would be correct if demand patterns for existing products changed while inputs stayed stable.

Trap 2: Data leakage

Data leakage is contamination during training, such as target information appearing in features, producing inflated offline metrics rather than a live accuracy drop. It would be the answer if the model scored unrealistically well in evaluation but failed immediately in production.

Trap 3: Model decay

Model decay describes gradual degradation as the relationship between features and target changes over time, not a sudden shift caused by a new input category. It would fit a model slowly losing accuracy months after training without any identifiable distribution change in incoming data.

A
Concept drift
Why it fails: Concept drift concerns the relationship between inputs and the target changing, whereas the stem describes a new input category with a different distribution — covariate shift. Concept drift would be correct if demand patterns for existing products changed while inputs stayed stable.
B
Covariate shift
Covariate shift occurs when input feature distributions change between training and production while the underlying relationship remains. The new product category alters the input distribution, so the model encounters patterns unlike its training data, degrading prediction accuracy.
C
Data leakage
Why it fails: Data leakage is contamination during training, such as target information appearing in features, producing inflated offline metrics rather than a live accuracy drop. It would be the answer if the model scored unrealistically well in evaluation but failed immediately in production.
D
Model decay
Why it fails: Model decay describes gradual degradation as the relationship between features and target changes over time, not a sudden shift caused by a new input category. It would fit a model slowly losing accuracy months after training without any identifiable distribution change in incoming data.

Question 5easymultiple choice

A company is using Amazon SageMaker Ground Truth to create a labeled dataset for object detection in images. The team wants to minimize labeling costs while maintaining high accuracy. Which feature should they use to achieve this?

Trap 1: Use a private workforce of internal employees

A private workforce of internal employees gives higher accuracy and data privacy, but internal annotators still cost salary time and scale poorly. Ground Truth's cost minimisation relies on automatic labelling plus active learning, which sends only low-confidence images to human labellers.

Trap 2: Use a larger initial training set with pre-labeled public datasets

Pre-labelled public datasets supply initial training data, but Ground Truth's cost reduction comes from automatic labelling and active learning, which label only uncertain samples. Public datasets may not match the target domain, and this adds no labelling-cost mechanism within Ground Truth itself.

Trap 3: Reduce the number of label categories

Fewer label categories reduces annotation effort per image but does not lower Ground Truth's labelling cost mechanism, and it can harm accuracy by collapsing distinct object classes. Automatic labelling with active learning is the feature that cuts human labelling volume while preserving accuracy.

A
Use a private workforce of internal employees
Why it fails: A private workforce of internal employees gives higher accuracy and data privacy, but internal annotators still cost salary time and scale poorly. Ground Truth's cost minimisation relies on automatic labelling plus active learning, which sends only low-confidence images to human labellers.
B
Enable automated data labeling with active learning
Automated data labeling with active learning uses a model to label high-confidence objects and routes only uncertain images to human annotators, reducing the volume of manual labelling required while sustaining accuracy, thereby lowering overall Ground Truth labelling costs.
C
Use a larger initial training set with pre-labeled public datasets
Why it fails: Pre-labelled public datasets supply initial training data, but Ground Truth's cost reduction comes from automatic labelling and active learning, which label only uncertain samples. Public datasets may not match the target domain, and this adds no labelling-cost mechanism within Ground Truth itself.
D
Reduce the number of label categories
Why it fails: Fewer label categories reduces annotation effort per image but does not lower Ground Truth's labelling cost mechanism, and it can harm accuracy by collapsing distinct object classes. Automatic labelling with active learning is the feature that cuts human labelling volume while preserving accuracy.

Question 6mediummultiple choice

A company has 200 small PyTorch models that are each used infrequently but need to be available for real-time inference. To minimize costs, they want to host all models on a single endpoint. Which SageMaker feature should they use?

Trap 1: Multi-container endpoint

Multi-container endpoints run several containers behind one endpoint but each container serves its own model on a shared instance, so 200 models cannot share one container's memory. It suits hosting a handful of distinct frameworks together, not many small models loaded dynamically on demand.

Trap 2: Batch Transform job

Batch Transform processes an entire dataset offline in a job, returning no persistent real-time endpoint for on-demand inference. It is tempting because it is cost-effective for infrequent work, and would be correct if predictions could be generated in bulk ahead of time rather than served interactively.

Trap 3: Asynchronous inference endpoint

Asynchronous inference queues requests and returns results via Amazon S3, so callers cannot receive an immediate synchronous response. It is tempting for large payloads or long processing times, and would be correct when near-real-time queued inference with extended runtimes is acceptable.

A
Multi-model endpoint (MME)
Multi-model endpoint hosts many models on one endpoint, loading each from S3 on invocation and caching it in memory. Because the PyTorch models are infrequent, this satisfies the single-endpoint and cost-minimisation constraints without provisioning per-model hosting.
B
Multi-container endpoint
Why it fails: Multi-container endpoints run several containers behind one endpoint but each container serves its own model on a shared instance, so 200 models cannot share one container's memory. It suits hosting a handful of distinct frameworks together, not many small models loaded dynamically on demand.
C
Batch Transform job
Why it fails: Batch Transform processes an entire dataset offline in a job, returning no persistent real-time endpoint for on-demand inference. It is tempting because it is cost-effective for infrequent work, and would be correct if predictions could be generated in bulk ahead of time rather than served interactively.
D
Asynchronous inference endpoint
Why it fails: Asynchronous inference queues requests and returns results via Amazon S3, so callers cannot receive an immediate synchronous response. It is tempting for large payloads or long processing times, and would be correct when near-real-time queued inference with extended runtimes is acceptable.

Question 7easymultiple choice

A machine learning engineer needs to split a dataset for binary classification where the positive class represents only 2% of the data. Which data splitting strategy ensures that both training and test sets maintain the same class proportion as the original dataset?

Trap 1: Time-series split respecting the timestamp order

A time-series split partitions chronologically, preserving temporal order to prevent leakage, but it does not enforce matching class ratios between train and test. It is tempting because it is mandatory when observations are autocorrelated, yet stratification is the requirement here.

Trap 2: Simple random split with a 80/20 ratio

A simple random split samples independently, so with a 2% positive rate the test set can easily contain very few or zero positives, and proportions drift between splits. It is tempting because it is the default, and it suffices when classes are balanced and the dataset is large.

Trap 3: K-fold cross-validation without stratification

Unstratified K-fold draws folds randomly, so a 2% positive class can be absent or over-represented in individual folds, breaking the required proportion match. Stratified K-fold preserves class ratios per fold. Plain K-fold suits balanced datasets where random partitioning already mirrors the overall distribution.

A
Stratified sampling based on the target variable
Stratified sampling partitions rows so each split preserves the original 2% positive-class prevalence, preventing a random split from yielding a test set with zero or distorted minority cases. This directly satisfies the stem's constraint that training and test sets mirror the dataset's class proportion, which matters acutely at severe imbalance.
B
Time-series split respecting the timestamp order
Why it fails: A time-series split partitions chronologically, preserving temporal order to prevent leakage, but it does not enforce matching class ratios between train and test. It is tempting because it is mandatory when observations are autocorrelated, yet stratification is the requirement here.
C
Simple random split with a 80/20 ratio
Why it fails: A simple random split samples independently, so with a 2% positive rate the test set can easily contain very few or zero positives, and proportions drift between splits. It is tempting because it is the default, and it suffices when classes are balanced and the dataset is large.
D
K-fold cross-validation without stratification
Why it fails: Unstratified K-fold draws folds randomly, so a 2% positive class can be absent or over-represented in individual folds, breaking the required proportion match. Stratified K-fold preserves class ratios per fold. Plain K-fold suits balanced datasets where random partitioning already mirrors the overall distribution.

Question 8hardmultiple choice

A company needs to deploy a large language model (LLM) on SageMaker with the Triton Inference Server to maximize GPU utilization and reduce latency. They have an NVIDIA A100 GPU. Which SageMaker inference option supports Triton?

Question 9easymultiple choice

A company wants to deploy a trained XGBoost model for batch inference on a large dataset stored in S3. The inference job should be cost-effective and does not require real-time responses. Which SageMaker inference option should they use?

Trap 1: SageMaker real-time endpoint

A real-time endpoint holds compute continuously and returns synchronous responses, so it bills for idle capacity while processing a large S3 dataset that needs no immediate answers. Batch Transform reads from S3 and shuts down after the job. Real-time endpoints suit low-latency interactive predictions.

Trap 2: SageMaker Asynchronous Inference

Asynchronous Inference queues requests and returns results via S3, but it targets large payloads or long processing times needing near-real-time retrieval, not whole-dataset scoring. Batch Transform handles the full S3 dataset cost-effectively. Asynchronous suits requests exceeding synchronous payload limits.

Trap 3: SageMaker Serverless Inference

Serverless Inference scales to zero and suits intermittent, unpredictable traffic with latency tolerance, but it caps payload size and duration, making it unsuitable for scoring a large S3 dataset. Batch Transform processes the entire dataset in one job. Serverless suits spiky, low-volume request patterns.

A
SageMaker Batch Transform
SageMaker Batch Transform runs inference over large S3 datasets on managed instances that terminate when the job completes, avoiding the cost of a persistently running endpoint. This satisfies the stem's cost-effectiveness requirement and its lack of any real-time response need.
B
SageMaker real-time endpoint
Why it fails: A real-time endpoint holds compute continuously and returns synchronous responses, so it bills for idle capacity while processing a large S3 dataset that needs no immediate answers. Batch Transform reads from S3 and shuts down after the job. Real-time endpoints suit low-latency interactive predictions.
C
SageMaker Asynchronous Inference
Why it fails: Asynchronous Inference queues requests and returns results via S3, but it targets large payloads or long processing times needing near-real-time retrieval, not whole-dataset scoring. Batch Transform handles the full S3 dataset cost-effectively. Asynchronous suits requests exceeding synchronous payload limits.
D
SageMaker Serverless Inference
Why it fails: Serverless Inference scales to zero and suits intermittent, unpredictable traffic with latency tolerance, but it caps payload size and duration, making it unsuitable for scoring a large S3 dataset. Batch Transform processes the entire dataset in one job. Serverless suits spiky, low-volume request patterns.

Question 10hardmultiple choice

A company uses SageMaker Model Monitor for data quality. They notice that monitoring jobs are failing intermittently with constraint violations. Upon review, they see that some features have different data types in production compared to the baseline (e.g., string instead of integer). Which type of drift is this?

Trap 1: Concept drift

Concept drift describes a change in the relationship between features and the target, altering what correct predictions look like. Here the schema itself changed — a string where the baseline held an integer — so the data quality constraint on column type fails, which is data drift.

Trap 2: Statistical drift

Statistical drift covers distribution shifts in numeric feature values, detected by metrics such as KL divergence or Jensen-Shannon distance. A column changing from integer to string is a schema or data type mismatch, which Model Monitor flags as a data quality constraint violation, not a statistical one.

Trap 3: Bias drift

Bias drift measures shifts in predicted outcomes across demographic groups, not feature data types. SageMaker Model Monitor's data quality baseline compares schema and types; a string replacing an integer triggers a data type constraint violation, which is data drift, not bias drift.

A
Schema drift
Schema drift occurs when the structure or data types of incoming features diverge from the baseline, such as a string arriving where an integer was expected. This mismatch triggers the constraint violations the monitoring jobs report.
B
Concept drift
Why it fails: Concept drift describes a change in the relationship between features and the target, altering what correct predictions look like. Here the schema itself changed — a string where the baseline held an integer — so the data quality constraint on column type fails, which is data drift.
C
Statistical drift
Why it fails: Statistical drift covers distribution shifts in numeric feature values, detected by metrics such as KL divergence or Jensen-Shannon distance. A column changing from integer to string is a schema or data type mismatch, which Model Monitor flags as a data quality constraint violation, not a statistical one.
D
Bias drift
Why it fails: Bias drift measures shifts in predicted outcomes across demographic groups, not feature data types. SageMaker Model Monitor's data quality baseline compares schema and types; a string replacing an integer triggers a data type constraint violation, which is data drift, not bias drift.

Question 11hardmultiple choice

A machine learning engineer is performing feature selection for a regression model with 200 features. The dataset has 10,000 samples. The engineer wants to remove irrelevant features while keeping those that have a strong non-linear relationship with the target. Which feature selection method is best suited for this requirement?

Trap 1: Lasso regularization (L1)

Lasso's L1 penalty shrinks coefficients under a linear model, so it selects on linear contribution and misses non-linear effects. It is tempting because it performs embedded selection efficiently on wide datasets, and would be correct if the target relationship were linear.

Trap 2: Recursive feature elimination (RFE) with a linear model

RFE with a linear estimator ranks features by linear coefficients, so it cannot capture non-linear dependence and may discard genuinely predictive features. It is tempting because RFE handles high-dimensional sets well, and would suit this data if relationships were linear rather than non-linear.

Trap 3: Pearson correlation coefficient

Pearson correlation measures only linear association, so features with strong non-linear relationships to the target score near zero and get dropped. It is tempting because it is fast and interpretable for 200 features, and would be correct if the requirement were linear relationships.

A
Lasso regularization (L1)
Why it fails: Lasso's L1 penalty shrinks coefficients under a linear model, so it selects on linear contribution and misses non-linear effects. It is tempting because it performs embedded selection efficiently on wide datasets, and would be correct if the target relationship were linear.
B
Recursive feature elimination (RFE) with a linear model
Why it fails: RFE with a linear estimator ranks features by linear coefficients, so it cannot capture non-linear dependence and may discard genuinely predictive features. It is tempting because RFE handles high-dimensional sets well, and would suit this data if relationships were linear rather than non-linear.
C
Pearson correlation coefficient
Why it fails: Pearson correlation measures only linear association, so features with strong non-linear relationships to the target score near zero and get dropped. It is tempting because it is fast and interpretable for 200 features, and would be correct if the requirement were linear relationships.
D
Mutual information
Mutual information captures arbitrary non-linear dependence between each feature and the target, unlike correlation-based filters that detect only linear relationships. With 10,000 samples across 200 features it remains computationally practical, satisfying the non-linear relevance requirement.

Question 12hardmultiple choice

A data scientist is preparing a large dataset (50 GB) for training a TensorFlow model on SageMaker. The dataset consists of many small CSV files. Training is slow due to I/O bottlenecks. Which data preparation strategy most effectively accelerates training?

Trap 1: Convert the dataset to Parquet format and use Apache Arrow for…

Parquet with Arrow reduces per-file overhead and enables columnar, zero-copy reads, but the stem's bottleneck is many small CSV files; consolidation into fewer larger objects addresses that directly. Parquet suits column-selective analytical scans, not the per-object overhead dominating this workload.

Trap 2: Compress the CSV files and decompress during data loading

Compression shrinks bytes on disk but adds decompression CPU cost and leaves the many-small-files overhead intact, so I/O latency persists. It is tempting because compression reduces transfer volume, which helps bandwidth-bound transfers, yet here per-object read overhead, not volume, is the constraint.

Trap 3: Use a larger instance type with more vCPUs

More vCPUs raise compute throughput but leave the many-small-CSV I/O bottleneck untouched, since each file still incurs per-object overhead. Larger instances are tempting when CPU-bound training is slow, yet here the fix is consolidating files into fewer, columnar objects to cut read operations.

A
Convert the dataset to TFRecord format and use tf.data pipeline with prefetching
TFRecord stores records in a compact binary format, eliminating per-file parsing overhead from thousands of small CSVs. The tf.data pipeline with prefetching overlaps data loading with GPU computation, directly resolving the I/O bottleneck constraining training throughput. This satisfies the scenario's requirement to accelerate training on a 50 GB dataset.
B
Convert the dataset to Parquet format and use Apache Arrow for loading
Why it fails: Parquet with Arrow reduces per-file overhead and enables columnar, zero-copy reads, but the stem's bottleneck is many small CSV files; consolidation into fewer larger objects addresses that directly. Parquet suits column-selective analytical scans, not the per-object overhead dominating this workload.
C
Compress the CSV files and decompress during data loading
Why it fails: Compression shrinks bytes on disk but adds decompression CPU cost and leaves the many-small-files overhead intact, so I/O latency persists. It is tempting because compression reduces transfer volume, which helps bandwidth-bound transfers, yet here per-object read overhead, not volume, is the constraint.
D
Use a larger instance type with more vCPUs
Why it fails: More vCPUs raise compute throughput but leave the many-small-CSV I/O bottleneck untouched, since each file still incurs per-object overhead. Larger instances are tempting when CPU-bound training is slow, yet here the fix is consolidating files into fewer, columnar objects to cut read operations.

Question 13mediummultiple choice

A company wants to serve 200 different PyTorch models. Each model is small (under 1 GB) and only a fraction are used at any time. To minimize cost and management overhead, which SageMaker inference option should be used?

Trap 1: Use batch transform for all models

Batch transform runs offline, job-based inference against stored data, so it cannot serve interactive requests from 200 models. It is tempting because batch transform avoids persistent endpoint costs, but the stem requires on-demand serving with minimal overhead, which multi-model endpoints provide by loading models on invocation.

Trap 2: Create a separate real-time endpoint for each model

Separate real-time endpoints per model leave 200 always-on instances billing continuously, even though only a fraction receive traffic. It is tempting because real-time endpoints give low-latency interactive inference, but the stem's cost and management constraints favour a multi-model endpoint hosting many models behind one endpoint.

Trap 3: Use a multi-container endpoint

Multi-container endpoints run several containers concurrently on one instance for pipelines or ensembles, not hundreds of selectable models. It is tempting because it consolidates workloads onto shared infrastructure, but the stem needs models loaded on demand; multi-model endpoints store many models in Amazon S3 and load them dynamically.

A
Use batch transform for all models
Why it fails: Batch transform runs offline, job-based inference against stored data, so it cannot serve interactive requests from 200 models. It is tempting because batch transform avoids persistent endpoint costs, but the stem requires on-demand serving with minimal overhead, which multi-model endpoints provide by loading models on invocation.
B
Create a separate real-time endpoint for each model
Why it fails: Separate real-time endpoints per model leave 200 always-on instances billing continuously, even though only a fraction receive traffic. It is tempting because real-time endpoints give low-latency interactive inference, but the stem's cost and management constraints favour a multi-model endpoint hosting many models behind one endpoint.
C
Use a multi-container endpoint
Why it fails: Multi-container endpoints run several containers concurrently on one instance for pipelines or ensembles, not hundreds of selectable models. It is tempting because it consolidates workloads onto shared infrastructure, but the stem needs models loaded on demand; multi-model endpoints store many models in Amazon S3 and load them dynamically.
D
Use a multi-model endpoint
Multi-model endpoints load models on demand from S3 into shared container memory and unload idle ones, so hosting 200 small PyTorch models costs far less than 200 endpoints. This satisfies the minimise-cost and management-overhead constraint given only a fraction are used concurrently.

Question 14easymulti select

A company ingests daily log data into an S3 bucket. They need to update the existing ML training dataset with new data without reprocessing the entire history. Which two strategies should they adopt? (Choose two.)

Trap 1: Store all data in a single large file and use append operations

S3 objects are immutable, so append operations are impossible; each update rewrites the entire large file, which is exactly the full reprocessing the scenario forbids. It is tempting because a single file simplifies downstream reads, and appending would be correct for a mutable store such as a database or log file.

Trap 2: Manually copy new files to the same S3 bucket

Copying files manually into the same prefix gives no incremental ingestion mechanism, so the training pipeline cannot detect which objects are new and must rescan the whole bucket. It is tempting because S3 is the correct storage layer, but manual copying suits one-off uploads, not scheduled incremental dataset refreshes.

Trap 3: Overwrite the entire existing dataset with the new data

Overwriting discards all historical data, so the model loses prior examples and cannot learn from the full history. It is tempting when only the newest data matters, but incremental strategies such as appending new partitions or merging with existing datasets preserve history without full reprocessing.

A
Store all data in a single large file and use append operations
Why it fails: S3 objects are immutable, so append operations are impossible; each update rewrites the entire large file, which is exactly the full reprocessing the scenario forbids. It is tempting because a single file simplifies downstream reads, and appending would be correct for a mutable store such as a database or log file.
B
Use AWS Glue to incrementally process new partitions
AWS Glue incrementally processes only newly arrived S3 partitions, satisfying the requirement to update the training dataset without reprocessing the entire history. By tracking partition metadata in the Data Catalog, Glue reads just the fresh daily logs, cutting compute cost and runtime compared with full-dataset reprocessing.
C
Use a partition key such as date to add new partitions
Partitioning S3 data by date lets downstream jobs target only the newest partition prefix. New daily logs land in their own partition, so the existing training dataset is extended without scanning or reprocessing historical data.
D
Manually copy new files to the same S3 bucket
Why it fails: Copying files manually into the same prefix gives no incremental ingestion mechanism, so the training pipeline cannot detect which objects are new and must rescan the whole bucket. It is tempting because S3 is the correct storage layer, but manual copying suits one-off uploads, not scheduled incremental dataset refreshes.
E
Overwrite the entire existing dataset with the new data
Why it fails: Overwriting discards all historical data, so the model loses prior examples and cannot learn from the full history. It is tempting when only the newest data matters, but incremental strategies such as appending new partitions or merging with existing datasets preserve history without full reprocessing.

Question 15hardmultiple choice

A data scientist is building a time-series forecasting model for daily sales data. The data spans two years. To evaluate the model's performance, the data scientist needs to simulate a realistic rolling forecast scenario. Which data splitting strategy should be used?

Trap 1: Random 80/20 train-test split

Random splitting shuffles daily observations, so training rows sit chronologically after test rows, leaking future information into the model and inflating measured accuracy. It is tempting because it is the default for independent records, and would be correct for non-sequential data such as customer churn.

Trap 2: Stratified k-fold cross-validation

Stratified k-fold shuffles observations across folds, leaking future values into training and destroying temporal order, so it cannot simulate rolling forecasts. It tempts because stratification balances class proportions in cross-validation, which suits classification, not time-series forecasting.

Trap 3: Hold-out split based on time (e.g., train on first 18 months, test…

A single chronological hold-out cannot simulate repeated rolling-origin forecasts; it yields one fixed train/test boundary and no re-training across folds. It tempts because time-ordered hold-out does preserve temporal order, which suits a one-off final evaluation rather than rolling backtesting.

A
Walk-forward validation
Walk-forward validation repeatedly trains on all data up to a point and tests on the immediately following window, then advances that split forward through time. This preserves chronological order and mimics how a deployed forecaster is retrained and rolled forward, unlike random or single-holdout splits.
B
Random 80/20 train-test split
Why it fails: Random splitting shuffles daily observations, so training rows sit chronologically after test rows, leaking future information into the model and inflating measured accuracy. It is tempting because it is the default for independent records, and would be correct for non-sequential data such as customer churn.
C
Stratified k-fold cross-validation
Why it fails: Stratified k-fold shuffles observations across folds, leaking future values into training and destroying temporal order, so it cannot simulate rolling forecasts. It tempts because stratification balances class proportions in cross-validation, which suits classification, not time-series forecasting.
D
Hold-out split based on time (e.g., train on first 18 months, test on last 6 months)
Why it fails: A single chronological hold-out cannot simulate repeated rolling-origin forecasts; it yields one fixed train/test boundary and no re-training across folds. It tempts because time-ordered hold-out does preserve temporal order, which suits a one-off final evaluation rather than rolling backtesting.

Question 16hardmultiple choice

A machine learning engineer is building a time-series forecasting model to predict daily sales for the next 30 days. The dataset spans two years of daily sales data. To evaluate model performance, the engineer needs to simulate a realistic forecasting scenario where the model is trained on past data and tested on future data without leakage. Which data splitting strategy should they use?

Trap 1: Hold-out validation using a random 80/20 split

A random 80/20 split shuffles observations across time, so the model trains on future days and tests on past ones, leaking temporal information. Hold-out splitting suits independent, identically distributed data; time-series forecasting requires chronological partitioning with the test set strictly after the training set.

Trap 2: Stratified sampling based on sales volume

Stratified sampling preserves class proportions but still assigns individual days randomly across folds, mixing past and future observations and leaking future information into training. Stratification is correct for imbalanced classification, where preserving label ratios across splits matters more than temporal order.

Trap 3: k-fold cross-validation with random shuffling

k-fold cross-validation with random shuffling interleaves past and future days across every fold, so training always sees data from the test period. k-fold suits stationary, exchangeable datasets; forecasting requires forward-chaining splits where each validation window follows its training window in time.

A
Hold-out validation using a random 80/20 split
Why it fails: A random 80/20 split shuffles observations across time, so the model trains on future days and tests on past ones, leaking temporal information. Hold-out splitting suits independent, identically distributed data; time-series forecasting requires chronological partitioning with the test set strictly after the training set.
B
Walk-forward validation with an expanding window
Walk-forward validation with an expanding window trains on all past observations and tests on the subsequent future period, then rolls forward, mirroring real forecasting and preventing the temporal leakage that random or shuffled splits would introduce.
C
Stratified sampling based on sales volume
Why it fails: Stratified sampling preserves class proportions but still assigns individual days randomly across folds, mixing past and future observations and leaking future information into training. Stratification is correct for imbalanced classification, where preserving label ratios across splits matters more than temporal order.
D
k-fold cross-validation with random shuffling
Why it fails: k-fold cross-validation with random shuffling interleaves past and future days across every fold, so training always sees data from the test period. k-fold suits stationary, exchangeable datasets; forecasting requires forward-chaining splits where each validation window follows its training window in time.

Question 17hardmultiple choice

An ML team is building a time-series forecasting model for daily sales. They need to split the data into training and validation sets without data leakage, and the validation set should be the most recent 30 days. Which splitting strategy should they use?

Trap 1: Stratified split based on sales volume

Stratification preserves the class or value distribution across splits but ignores chronological order, so training rows can postdate validation rows and leak future sales into the model. It suits classification with imbalanced labels. Time-series forecasting needs a temporal cutoff, with the latest 30 days reserved as validation.

Trap 2: K-fold cross-validation

K-fold cross-validation shuffles observations across folds, so training folds contain days later than validation folds, leaking future information into the past. It suits independent, identically distributed samples. Time-series forecasting requires chronological ordering, with the most recent 30 days held out as validation.

Trap 3: Random 80/20 split

A random 80/20 split scatters days arbitrarily, placing later dates in training and earlier dates in validation, which leaks future information backwards. Random splitting suits independent observations. Time-series forecasting requires the validation set to be the chronologically most recent 30 days, with all earlier days used for training.

A
Stratified split based on sales volume
Why it fails: Stratification preserves the class or value distribution across splits but ignores chronological order, so training rows can postdate validation rows and leak future sales into the model. It suits classification with imbalanced labels. Time-series forecasting needs a temporal cutoff, with the latest 30 days reserved as validation.
B
K-fold cross-validation
Why it fails: K-fold cross-validation shuffles observations across folds, so training folds contain days later than validation folds, leaking future information into the past. It suits independent, identically distributed samples. Time-series forecasting requires chronological ordering, with the most recent 30 days held out as validation.
C
Random 80/20 split
Why it fails: A random 80/20 split scatters days arbitrarily, placing later dates in training and earlier dates in validation, which leaks future information backwards. Random splitting suits independent observations. Time-series forecasting requires the validation set to be the chronologically most recent 30 days, with all earlier days used for training.
D
Time-based split with last 30 days as validation
Time-series data is ordered, so random splitting leaks future information into training. A time-based split trains on earlier observations and holds out the final 30 days, preserving chronological order and matching the requirement that validation be the most recent period.

Question 18hardmulti select

A machine learning engineer is evaluating a binary classification model for detecting fraudulent transactions. The dataset is highly imbalanced, and the cost of false negatives (missing a fraud) is very high. Which two evaluation metrics should the engineer consider? (Choose two.)

Trap 1: Accuracy

Accuracy counts both classes equally, so a model predicting "not fraud" for every transaction scores highly on this imbalanced dataset while catching no fraud. Accuracy suits balanced datasets where false positives and false negatives carry similar cost.

Trap 2: Precision

Precision measures how many flagged transactions are genuinely fraudulent, targeting false positives; it ignores the false negatives the scenario prioritises. Precision is the correct focus when investigating flagged cases is costly and missing fraud is tolerable.

Trap 3: Mean absolute error

Mean absolute error measures regression residuals, not class labels, so it cannot express false negatives in a binary classifier. It is tempting because it quantifies average prediction error, and would be the right choice when evaluating a regression model predicting continuous values such as transaction amount.

A
F1-score
F1-score is the harmonic mean of precision and recall, so it penalises models that sacrifice either measure. On a highly imbalanced fraud dataset with costly false negatives, it captures the precision-recall trade-off that accuracy would hide behind the dominant negative class.
B
Accuracy
Why it fails: Accuracy counts both classes equally, so a model predicting "not fraud" for every transaction scores highly on this imbalanced dataset while catching no fraud. Accuracy suits balanced datasets where false positives and false negatives carry similar cost.
C
Recall
Recall measures the proportion of actual frauds correctly identified, directly reflecting the cost constraint: high false-negative cost means missing frauds is expensive. Maximising recall minimises those misses, though it must be balanced against precision to avoid excessive false alarms.
D
Precision
Why it fails: Precision measures how many flagged transactions are genuinely fraudulent, targeting false positives; it ignores the false negatives the scenario prioritises. Precision is the correct focus when investigating flagged cases is costly and missing fraud is tolerable.
E
Mean absolute error
Why it fails: Mean absolute error measures regression residuals, not class labels, so it cannot express false negatives in a binary classifier. It is tempting because it quantifies average prediction error, and would be the right choice when evaluating a regression model predicting continuous values such as transaction amount.

Question 19easymultiple choice

A data scientist is using SageMaker to train a linear regression model on a dataset with a large number of features. They notice that the model's training time is long and want to speed it up by using a more efficient algorithm. They decide to use the SageMaker built-in Linear Learner algorithm. Which of the following is a key advantage of using the Linear Learner algorithm in SageMaker for this scenario?

Trap 1: It uses a built-in automatic model tuning feature that always finds…

Automatic model tuning is a separate SageMaker feature that can be used with Linear Learner, but it is not built into the algorithm itself. The algorithm does not automatically find optimal hyperparameters; the user must configure and run a tuning job. Therefore, this is not a key advantage of the algorithm.

Trap 2: It automatically performs feature engineering and selection,…

SageMaker Linear Learner does not automatically perform feature engineering or selection. It expects the input data to be preprocessed and in a suitable format, such as recordIO-wrapped protobuf or CSV. While it can handle high-dimensional data, feature engineering remains the responsibility of the data scientist.

Trap 3: It is specifically designed for deep learning models and can…

SageMaker Linear Learner is a linear model algorithm, not a deep learning algorithm. It does not use GPUs; it is optimized for CPU-based training. Using it for deep learning would be inappropriate. Thus, this is not a correct advantage for the given scenario.

A
It uses a built-in automatic model tuning feature that always finds the optimal hyperparameters without user intervention.
Why it fails: Automatic model tuning is a separate SageMaker feature that can be used with Linear Learner, but it is not built into the algorithm itself. The algorithm does not automatically find optimal hyperparameters; the user must configure and run a tuning job. Therefore, this is not a key advantage of the algorithm.
B
It automatically performs feature engineering and selection, reducing the need for manual preprocessing.
Why it fails: SageMaker Linear Learner does not automatically perform feature engineering or selection. It expects the input data to be preprocessed and in a suitable format, such as recordIO-wrapped protobuf or CSV. While it can handle high-dimensional data, feature engineering remains the responsibility of the data scientist.
C
It is specifically designed for deep learning models and can leverage GPUs for faster training.
Why it fails: SageMaker Linear Learner is a linear model algorithm, not a deep learning algorithm. It does not use GPUs; it is optimized for CPU-based training. Using it for deep learning would be inappropriate. Thus, this is not a correct advantage for the given scenario.
D
It supports both regression and classification and can handle large-scale datasets efficiently using distributed training.
SageMaker Linear Learner is designed for large-scale linear models and supports both regression and classification. It can be trained in distributed mode across multiple instances, which speeds up training on large datasets. This makes it a suitable choice for the data scientist's scenario of a large number of features and long training time.