AWS Certified Machine Learning Engineer Associate MLA-C01 (MLA-C01) — Questions 526–600

Why this answer

How to eliminate wrong answers

Option B is wrong because Multi-Model endpoints are designed to host multiple independent models on a single instance, but here the ensemble is a single model composed of three sub-models that must be loaded together for each inference; using a Multi-Model endpoint would require loading each sub-model separately, increasing latency and complexity. Option C is wrong because SageMaker batch transform is an asynchronous, offline processing method that does not support real-time inference with sub-100 ms latency; it is designed for large-scale batch jobs, not low-latency endpoints. Option D is wrong because provisioned concurrency is a feature for AWS Lambda, not Amazon SageMaker endpoints; SageMaker uses Auto Scaling or manual instance scaling, and an ml.c5.xlarge instance would be over-provisioned for the baseline load, increasing cost unnecessarily.

Why this answer

How to eliminate wrong answers

Option A is wrong because writing a custom SageMaker Processing job for validation is unnecessary overhead; Data Wrangler already provides native data quality checks that are simpler and more integrated. Option C is wrong because AWS Glue DataBrew is a separate service for data preparation, not a step within a SageMaker Data Wrangler pipeline, and using it would break the pipeline's continuity. Option D is wrong because adding a SageMaker Pipeline step to check data quality after Data Wrangler is redundant; Data Wrangler itself can perform validation inline, and a post-hoc step would not catch issues before training in the same streamlined flow.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a stratified split based on the target variable preserves class proportions but does not account for time order, leading to potential data leakage when time-dependent patterns exist. Option C is wrong because a random split ignores the temporal structure entirely, allowing future data points to appear in the training set and causing leakage. Option D is wrong because K-fold cross-validation shuffles data randomly across folds, which breaks the time sequence and introduces leakage; it is unsuitable for time-series or time-sensitive data.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because switching to logistic regression with balanced class weights may help, but it is not the best action; the question asks for a single action to improve detection, and adjusting the threshold and metric (D) is more direct and effective than changing the model type. Option B is wrong because using accuracy as the evaluation metric will continue to favor the majority class and fail to reflect poor positive detection, reinforcing the original problem. Option C is wrong because applying SMOTE to the training data can introduce synthetic samples, but it does not address the need to evaluate and tune the model's decision threshold; SMOTE alone may not fix the detection issue if the threshold remains at 0.5.

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing the scale-in cooldown period would make the problem worse, not better—it would cause the endpoint to wait even longer before scaling down, increasing costs. Option C is wrong because step scaling policies control the magnitude of scaling adjustments (e.g., adding or removing multiple instances at once), but they do not affect the timing or delay of scale-in actions; the cooldown period is the key parameter for timing. Option D is wrong because changing the metric to memory utilization does not address the core issue of slow scale-down timing; the problem is with the cooldown period, not the metric choice.

Why this answer

How to eliminate wrong answers

Option B is wrong because Amazon API Gateway is designed for request routing and transformation at the HTTP level, not for heavy image preprocessing (e.g., resizing and normalization) — it lacks the computational capability and libraries needed for such tasks, and it would introduce latency without any benefit. Option C is wrong because packaging preprocessing logic into the same container as the model violates the separation of concerns principle and makes the container larger and harder to maintain; it also prevents independent scaling or updating of preprocessing steps. Option D is wrong because using a Lambda function as a proxy adds unnecessary cold-start latency and a 6 MB (or 10 MB via extension) payload limit, which is problematic for large images, and it does not integrate as seamlessly with SageMaker's built-in batching or inference pipeline features.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because random sampling from the entire dataset would include outdated data from months or years ago, failing to capture the recent distribution shift and introducing bias from stale patterns. Option C is wrong because using all historical data would force the model to learn temporal patterns that may no longer be valid, leading to degraded performance on current data and higher training costs due to the full 500 GB dataset. Option D is wrong because exponential downsampling of older data is an overly complex approach that may still retain some outdated data, and it does not guarantee that the training set reflects the most recent behavior as cleanly as a simple time-window cut; it also adds unnecessary preprocessing overhead.

Why this answer

How to eliminate wrong answers

Option A is wrong because using the model package ARN (which refers to the group) would cause a different error, such as 'ModelPackageNotFound' or 'InvalidARN', not a specific 'not approved' error; the pipeline would still need to specify a version. Option B is wrong because the question states the model version is clearly approved in the registry, so the pipeline using a different pending version would imply a misconfiguration in the pipeline's version selection logic, but the error message directly contradicts the approval status of the intended version. Option C is wrong because IAM permissions for the endpoint configuration to read the registry would cause an 'AccessDenied' or authorization error, not a 'not approved' error; the error is about approval status, not permissions.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because one-hot encoding all features, including numeric ones, would dramatically increase dimensionality and is inappropriate for features that are not categorical; dropping rows with missing values reduces the dataset size and can introduce bias. Option B is wrong because standardizing features is beneficial, but applying a Box-Cox transformation to the target variable requires all target values to be positive (which may not hold) and is less commonly used than log transformation for right-skewed targets; also, Box-Cox is not directly available in SageMaker's built-in linear learner without custom preprocessing. Option D is wrong because removing rows with missing values discards potentially valuable data and can lead to biased models; normalizing the target to [0,1] does not address skewness and may compress the variance, harming regression performance.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because SageMaker Batch Transform is designed for asynchronous, offline inference on large datasets, not for real-time sub-100ms latency; it processes data in batches and returns results only after the job completes. Option C is wrong because SageMaker Async Inference queues inference requests and processes them asynchronously, which introduces unpredictable latency and is not suitable for sub-100ms real-time requirements. Option D is wrong because SageMaker Serverless Inference auto-scales from zero and has a cold start latency that can exceed 100ms, especially for GPU-based models, making it unsuitable for strict real-time latency demands.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because SageMaker Model Monitor is designed to monitor inference endpoints for data drift and model quality after deployment, not for detecting overfitting during training. Option B is wrong because SageMaker Automatic Model Tuning (hyperparameter tuning) optimizes hyperparameters to improve model performance but does not monitor or diagnose overfitting in real time during a single training run. Option C is wrong because SageMaker Experiments tracks and organizes training runs, metrics, and parameters for comparison, but it does not actively detect or alert on overfitting patterns during training.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because tagging a model version as 'production-ready' is a metadata label that does not enforce any deployment restrictions; SageMaker does not natively use tags to gate deployments. Option C is wrong because manually moving the model artifact to a production S3 bucket bypasses the Model Registry's approval workflow entirely, offering no governance or audit trail. Option D is wrong because while IAM policies can restrict deployment to specific model ARNs, they do not leverage the Model Registry's approval status; this approach would require manual ARN management and does not integrate with the approval workflow.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because applying data augmentation by adding noise to the majority class does not address the imbalance—it only increases the size of the already dominant class, potentially worsening the imbalance and introducing irrelevant variance. Option C is wrong because using a weighted loss function is a training-time technique, not a data preparation technique; the question explicitly asks for a data preparation technique to apply to the training dataset before training. Option D is wrong because random under-sampling to match the minority class size would discard 90% of the majority class data, leading to significant information loss and a high risk of underfitting, especially with a severe 95:5 imbalance.

Why this answer

How to eliminate wrong answers

Option B is wrong because random undersampling of the majority class discards a large portion of the dataset (up to 95% of the negative examples), which leads to significant information loss and can degrade model performance due to reduced training data. Option C is wrong because random oversampling of the minority class simply duplicates existing positive examples, which does not introduce new variability and often causes overfitting, especially when the minority class is very small (5%). Option D is wrong because applying class weights during model training is a cost-sensitive learning technique, not a data preparation technique; it adjusts the loss function to penalize misclassifications of the minority class more heavily, but the question specifically asks for a data preparation technique to address imbalance without losing data.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because one-hot encoding on a column with over 200 unique values would create over 200 sparse columns, dramatically increasing memory and training time, and min-max scaling is sensitive to outliers, which would compress the majority of values into a narrow range. Option C is wrong because equal-width binning on a long-tail distribution will result in most data falling into the first few bins, losing information, and count encoding alone may not capture the ordinal relationship implied by frequency. Option D is wrong because one-hot encoding again suffers from high dimensionality, standard scaling is not robust to outliers (it uses mean and standard deviation), and removing outliers arbitrarily can discard valuable fraud signals.

Why this answer

How to eliminate wrong answers

Option A is wrong because min-max scaling is not optimal for linear models (it does not center data, which can slow convergence), and target encoding ad_category based on click rates introduces data leakage (future information) and risks overfitting. Option B is wrong because applying PCA to categorical features after converting to numeric indices is inappropriate (PCA assumes linear relationships and continuous data), and standardizing principal components is redundant since PCA already produces uncorrelated components. Option C is wrong because label encoding ad_category (50 unique values) imposes false ordinal relationships, and recursive feature elimination is computationally expensive and unnecessary for this dataset size; min-max scaling also lacks centering for linear models.

Why this answer

How to eliminate wrong answers

Option A is wrong because disabling ModelServerWorkers would force the container to use a single worker, limiting concurrency to 1 request at a time, which cannot handle 10 concurrent requests. Option C is wrong because initial variant weight controls traffic distribution across multiple variants, not concurrency or instance count; setting it to 10 does not increase the number of instances or workers. Option D is wrong because setting the initial instance count to 10 would deploy 10 instances, which is unnecessary and costly for handling 10 concurrent requests, and does not address the goal of minimizing cost.

Why this answer

How to eliminate wrong answers

Option A is wrong because SageMaker batch transform is an asynchronous, offline inference option that processes large datasets in batches and does not provide real-time, low-latency responses. Option C is wrong because SageMaker asynchronous inference is designed for requests with large payloads or long processing times, and it introduces queueing and callback mechanisms that add latency beyond the 10 ms requirement. Option D is wrong because SageMaker serverless inference auto-scales from zero and has a cold-start latency that can exceed 10 ms, making it unsuitable for sub-10 ms real-time predictions.

Why this answer

How to eliminate wrong answers

Option A is wrong because batch processing is not relevant to a real-time endpoint; SageMaker real-time endpoints process individual requests synchronously, and the inference script's use of batching would not cause gradual latency increases over weeks. Option C is wrong because the model size has remained unchanged, so if it were too large for the instance type, latency would be consistently high from the start, not gradually increasing. Option D is wrong because data capture, when enabled, adds a small, fixed overhead per request (writing to S3), which would cause a constant latency increase, not a gradual one that worsens over weeks.

Why this answer

How to eliminate wrong answers

Option B is wrong because Amazon SageMaker Clarify is designed for detecting bias and explaining model predictions, not for monitoring model performance degradation over time; it focuses on feature attribution drift, which is a form of explainability monitoring, not a direct measure of prediction error increase. Option C is wrong because Amazon CloudWatch monitoring of endpoint latency tracks infrastructure performance (e.g., response times, invocation counts), not the accuracy or error rate of model predictions; latency issues do not explain increased prediction errors when data distributions are unchanged. Option D is wrong because Amazon SageMaker Model Monitor configured for data drift tracks changes in the input feature distribution, but the question explicitly states that data distributions remain unchanged, so data drift monitoring would not detect the issue; the problem is model performance degradation despite stable input data.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because label encoding assigns arbitrary integer values to categories, which introduces a false ordinal relationship that can mislead tree-based models into treating high-cardinality features as ordered, degrading performance. Option B is wrong because one-hot encoding creates a binary column for each unique category, which with thousands of categories leads to an extremely high-dimensional and sparse feature space, causing memory issues and overfitting. Option C is wrong because frequency encoding replaces categories with their occurrence counts, which loses the relationship between the category and the target variable, often resulting in weaker predictive power compared to target encoding.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because missing values in a column would result in a null value, not a NumberFormatException; Spark can handle nulls in numeric columns without throwing a parsing error. Option B is wrong because if the schema inference had incorrectly detected the column as String, the write to Parquet would succeed without any type conversion error; the error occurs only when Spark tries to parse a string as a number. Option D is wrong because compressed CSV files are automatically decompressed by Spark/Glue based on the file extension (e.g., .gz, .bz2), and a decompression issue would produce an IOException or a different error, not a NumberFormatException.

Why this answer

How to eliminate wrong answers

Option A is wrong because a `requirements.txt` file in S3 is not automatically processed by SageMaker Processing; the container does not read it unless explicitly handled in a custom entry point or lifecycle script, and even then, pip install requires network access or a pre-built wheel. Option C is wrong because Amazon EFS is a file system for shared storage, not for distributing Python libraries; mounting EFS to a processing container would require custom network configuration and does not integrate with Python's import system without additional setup. Option D is wrong because `pip install` inside the processing script at runtime will fail if the container lacks internet access (common in VPC-only modes) or if the required build tools are missing, and it violates the principle of immutable infrastructure.

Why this answer

How to eliminate wrong answers

Option A is wrong because SageMaker Training steps with checkpointing are designed to save intermediate model state during training (e.g., for resuming from failures), not to cache or reuse preprocessed data across pipeline executions. Option C is wrong because SageMaker Feature Store is a managed repository for storing, sharing, and managing features for ML models, but it does not automatically cache the output of a preprocessing step; it requires explicit feature ingestion and retrieval, which adds complexity and does not directly address skipping the preprocessing step based on unchanged source data. Option D is wrong because SageMaker Data Wrangler is a visual interface for data preparation and feature engineering, but it does not provide built-in caching for pipeline steps; it can be used within a Processing step, but the caching behavior is a property of the Processing step itself, not of Data Wrangler.

Why this answer

How to eliminate wrong answers

Option B is wrong because using a larger instance with more vCPUs does not directly accelerate GPU-bound training; the bottleneck is GPU compute, not CPU cores. Option C is wrong because model parallelism is designed for models that are too large to fit on a single GPU, partitioning layers across devices, which adds communication overhead and is unnecessary when the model fits on one GPU. Option D is wrong because Elastic Inference attaches a separate accelerator for inference only, not for training, and cannot be used to speed up training loops.

Why this answer

How to eliminate wrong answers

Option A is wrong because SageMaker batch transform is designed for offline, asynchronous processing of large datasets, not for real-time inference; it would introduce unacceptable delays and cannot meet the sub-500 ms latency requirement. Option B is wrong because increasing the maximum instance count to 10 and lowering CPU target to 50% would significantly increase costs (more instances running) and still not guarantee sub-500 ms latency if each instance is CPU-bound; the current scaling limit of 2 instances suggests the bottleneck is per-instance compute capacity, not scaling policy. Option D is wrong because data compression reduces payload size and network latency, but the primary latency spike is due to compute time (model inference), not network transfer; the 500 MB model and 200 features are already moderate, and compression would offer minimal improvement for the compute-bound bottleneck.

Why this answer

How to eliminate wrong answers

Option A is wrong because AWS DataSync is a data transfer service for large-scale migrations or syncs, not for real-time access during a SageMaker training job; it would add latency and complexity without solving the VPC-based access restriction. Option B is wrong because simply creating an IAM role in the source account and assuming it from the training account does not satisfy the bucket policy's VPC condition; the bucket policy explicitly requires requests to originate from the specified VPC, and the IAM role alone does not control the network origin. Option C is wrong because using an S3 VPC endpoint in the training job's VPC is necessary but insufficient on its own; the bucket policy must also explicitly allow the VPC (via the `aws:SourceVpc` condition), and cross-account access still requires an IAM role in the source account to grant permissions to the training account's principal.

Why this answer

How to eliminate wrong answers

Option A is wrong because adding more layers increases model capacity, which would exacerbate overfitting and likely cause validation loss to rise even sooner, not improve generalization. Option C is wrong because increasing the learning rate would make training more unstable, potentially causing the loss to diverge or oscillate, and would not address the overfitting indicated by the rising validation loss. Option D is wrong because decreasing the batch size introduces more noise into gradient estimates, which can sometimes help escape local minima but does not directly prevent overfitting; it may even slow convergence and does not target the core issue of validation loss increasing.

Why this answer

How to eliminate wrong answers

Option B is wrong because reprocessing the entire Kinesis stream from the beginning is unnecessary and inefficient; the data is not lost, it is simply never delivered due to the buffer window not closing. Option C is wrong because switching to a Lambda-based direct write from Kinesis to S3 would bypass Firehose entirely, adding complexity and potential for data loss or duplication, and does not fix the root cause of the incomplete buffer window. Option D is wrong because increasing the buffer interval to 600 seconds would make the problem worse, as it would extend the time needed for a buffer window to complete, increasing the likelihood of incomplete windows at day boundaries.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because serverless endpoints have a cold-start latency that can exceed 2 seconds, especially for large foundation models, and they do not guarantee consistent sub-2-second inference under variable traffic. Option C is wrong because auto-scaling handles variable traffic but does not reduce per-invocation cost or latency; it only adjusts capacity, and the chosen instance type still determines base latency and cost. Option D is wrong because using the largest GPU instance is unnecessarily expensive and may provide excess compute capacity that is not needed to meet a 2-second latency requirement, violating the cost-minimization goal.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because CloudWatch Events rules can monitor pipeline state changes but cannot stop a running pipeline; they can only trigger notifications or invoke other actions after the fact. Option B is wrong because registering a model in the Model Registry is an optional downstream step, not a mechanism to stop the pipeline; if registration fails, the pipeline would still continue to subsequent steps unless explicitly handled. Option C is wrong because a Lambda step can send SNS notifications but does not have the ability to halt the pipeline execution; it would only alert after the step completes, not prevent further steps from running.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because scheduling the pipeline does not prevent redundant runs; it only triggers execution at fixed intervals, which could still re-run all steps even when data hasn't changed. Option C is wrong because passing a previous execution ID via a Parameter step does not enable caching; it merely provides a reference but does not automatically skip unchanged steps. Option D is wrong because using a Lambda step to check data changes before running adds custom logic but is not a built-in mechanism for step-level caching; SageMaker Pipelines already provides `CacheConfig` for this purpose, making a Lambda workaround unnecessary and less efficient.

Why this answer

How to eliminate wrong answers

Option B is wrong because wide-format CSV (each column as a separate time series) is not supported by DeepAR; it expects each time series to be a separate JSON object, not columns. Option C is wrong because Parquet files are not a native input format for DeepAR; the built-in algorithm specifically requires JSON Lines or RecordIO-protobuf format. Option D is wrong because a single CSV with timestamp, item_id, and value columns does not provide the 'start' and 'target' structure DeepAR needs; it would require significant preprocessing to group by item_id and convert to the required JSON Lines format.

Why this answer

How to eliminate wrong answers

Option A is wrong because keeping 'CustomerID' as a feature introduces a high-cardinality categorical variable with no correlation to the target, which can cause overfitting and degrade model generalization. Option B is wrong because the target variable for churn prediction should be a binary or categorical label indicating churn status, not a unique identifier that has no relationship to the outcome. Option D is wrong because one-hot encoding a unique identifier like 'CustomerID' would create thousands of sparse binary columns, dramatically increasing dimensionality without adding any predictive value, and is computationally wasteful.

Why this answer

How to eliminate wrong answers

Option A is wrong because setting the 'age' column type to 'number' in SageMaker Data Wrangler only affects the visual interface and exported recipe, but does not enforce type casting in the actual processing script, so the underlying data type mismatch persists. Option B is wrong because dropping rows with missing values does not address the core issue of mixed data types (e.g., strings like 'N/A' or 'unknown') in the 'age' column; the error is about type conversion, not missing values. Option C is wrong because removing the 'age' column entirely discards potentially valuable feature data and does not solve the type mismatch problem; it is an overly aggressive workaround that reduces model performance.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because deploying on Amazon ECS with a custom Docker image requires you to build, maintain, and scale the container infrastructure yourself, increasing operational overhead. Option B is wrong because AWS Lambda has a maximum deployment package size limit (250 MB unzipped) and a 15-minute timeout, making it unsuitable for large TensorFlow SavedModels or inference requests that require significant compute. Option C is wrong because Amazon SageMaker Studio is an integrated development environment (IDE) for building, training, and debugging models, not a deployment target; the actual deployment would still require creating an endpoint, which is covered by Option D.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because pipeline caching in SageMaker reuses a step's output only if the step's input parameters and source code are unchanged; it does not evaluate external data checksums, so it would not detect unchanged new data. Option B is wrong because a Lambda step can check the data, but it cannot directly skip the training step; you would still need a ConditionStep to branch based on the Lambda's result, making the Lambda step redundant and adding unnecessary complexity. Option D is wrong because CacheConfig with a TTL of 24 hours caches the step's output for that duration regardless of data changes, which would incorrectly skip training even if the data had changed within the TTL window, and it does not compare checksums.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because enabling data encryption at rest using KMS only protects stored data, not traffic between the endpoint and model containers, and using a private VPC alone does not enforce VPC-only mode for endpoint access. Option C is wrong because network isolation mode prevents the model container from accessing the internet but does not encrypt inter-container traffic nor restrict endpoint access to a specific VPC. Option D is wrong because deploying the endpoint in a private subnet and using a VPC endpoint for the SageMaker API controls API calls but does not encrypt inter-container traffic or enforce VPC-only mode for inference requests.