AWS
106+ Free Practice Questions with AI-Verified Answers
All Questions &
Answers Free
Detailed
Explanation
Closest to the
Real ExamAI-Powered
Every AWS Certified Machine Learning Engineer - Associate (MLA-C01) answer is cross-verified by 3 leading AI models to ensure maximum accuracy. Get detailed per-option explanations and in-depth question analysis.
A fintech startup has deployed a gradient-boosted tree fraud-detection model with 42 numeric features to an Amazon SageMaker real-time endpoint on ml.m5.large (target p95 latency ≤ 80 ms and ~200 RPS), and compliance officers require per-inference feature attributions (for example, amount=$1,275, country=DE, device_age_days=14) to understand why specific transactions are flagged without changing the model code; which solution will provide explanations for predictions from the live endpoint?
SageMaker Model Monitor is for ongoing monitoring of deployed models: capturing inference data, detecting data/feature drift, monitoring data quality constraints, and (with additional setup) bias and explainability reports typically in batch/offline contexts. It does not natively provide per-request, synchronous feature attributions returned with each real-time inference response. It addresses model operations and governance, not live per-inference explanations.
SageMaker Clarify is the correct choice because it provides model explainability via feature attributions (commonly SHAP) and can be used with deployed endpoints by adding an explainer configuration. This enables per-inference explanations for tabular models like gradient-boosted trees without modifying the model code. It directly satisfies the requirement to explain why specific transactions were flagged in real time.
CloudWatch can visualize metrics and distributions (latency, error rates, custom metrics, A/B test traffic splits), but it does not compute feature attributions or explain individual predictions. At best, it helps observe operational behavior of endpoints. It cannot produce compliance-grade per-inference explanations like “amount contributed X to the fraud score.”
A shadow endpoint is useful for safe testing (e.g., comparing a candidate model to production by mirroring traffic) and analyzing prediction differences. However, it does not inherently generate feature attributions. You would still need an explainability method/tool to compute per-inference explanations. This option addresses deployment validation, not explainability requirements.
Core Concept: This question tests real-time model explainability on Amazon SageMaker endpoints. The AWS service purpose-built for per-inference feature attributions (local explanations) without modifying model code is Amazon SageMaker Clarify, which can attach an explainer to an existing real-time endpoint. Why the Answer is Correct: Compliance officers require per-transaction explanations such as “amount=$1,275, country=DE, device_age_days=14” for each inference. SageMaker Clarify supports online explainability by deploying an explainer (e.g., SHAP-based feature attribution) alongside the model endpoint. This enables returning feature attributions for each prediction request/response path while keeping the original model artifact and inference container unchanged—matching the requirement “without changing the model code.” It is designed for tabular models (including gradient-boosted trees) and numeric features, and can be used with real-time endpoints. Key AWS Features: Clarify provides feature attribution methods (commonly SHAP) and can be configured to output per-feature contribution scores for each inference. In practice, you configure the explainer with the model’s input schema, baseline/background dataset (or reference), and desired output format. This is aligned with governance and auditability needs in regulated industries (fintech) and supports operational use cases where explanations must be generated synchronously with predictions. Common Misconceptions: Model Monitor is often confused with explainability because both relate to governance. However, Model Monitor focuses on data quality, drift, bias monitoring over time, and alerting—not per-inference attribution. CloudWatch A/B distributions and shadow endpoints help with operational monitoring and safe rollout, but they do not produce feature-level explanations. Exam Tips: When you see “feature attributions,” “why this prediction,” “local explanation,” or “SHAP,” think SageMaker Clarify. When you see “drift,” “data quality,” “bias over time,” or “monitoring schedules,” think SageMaker Model Monitor. Also note the constraint “without changing model code,” which points to managed explainability tooling rather than custom instrumentation inside the model container.
In a refinery safety system, an ML engineer must select a binary classifier that detects methane leaks from sensor streams; a missed real leak (false negative) incurs an average incident cost of $120,000 while a false alarm triggers a $300 on-site check and 5 minutes of downtime, so which metric finding should be prioritized the most when choosing the model?
Low precision means many predicted leaks are false alarms (high FP relative to TP). While the scenario tolerates more false alarms than missed leaks, you still don’t “prioritize low precision” as a goal; it’s merely a possible trade-off you accept to achieve high recall. The objective is to reduce false negatives, not to intentionally increase false positives.
High precision focuses on ensuring that when the model predicts a leak, it is usually correct (minimizing false positives). That would reduce $300 checks and downtime, but those costs are tiny compared to the $120,000 average cost of missing a real leak. Optimizing for precision risks increasing false negatives, which is unacceptable in a safety-critical refinery context.
Low recall indicates the model misses many true leaks (high false negatives). This is the opposite of what the business needs because false negatives carry the dominant cost ($120,000 incidents). A model with low recall could look good on accuracy if leaks are rare, but it would be dangerous operationally and economically in this setting.
High recall (sensitivity) maximizes detection of actual methane leaks by minimizing false negatives. Because a missed leak has an average cost of $120,000, the model selection should prioritize recall, even if it increases false positives and triggers more $300 checks and brief downtime. In practice, you’d also tune the decision threshold to push recall higher and validate with a confusion matrix and PR curve.
Core Concept: This question tests classification evaluation metrics and cost-sensitive model selection. In safety-critical detection (methane leaks), the business impact of errors is asymmetric, so you prioritize the metric that minimizes the most expensive error type. This is part of ML model development: selecting metrics, thresholds, and decision criteria aligned to risk. Why the Answer is Correct: A false negative means a real leak is missed, with an average incident cost of $120,000. A false positive triggers a $300 check plus 5 minutes downtime—orders of magnitude cheaper. Recall (a.k.a. sensitivity or true positive rate) measures how many actual positives are correctly detected: Recall = TP / (TP + FN). Maximizing recall directly reduces false negatives (FN). Therefore, you should prioritize high recall when choosing the model (and typically tune the decision threshold to further reduce FN), even if that increases false alarms. Key AWS Features / Best Practices: In Amazon SageMaker, you can: - Choose evaluation metrics that reflect the objective (e.g., recall, F-beta with beta > 1 to weight recall higher than precision). - Tune classification thresholds post-training using model outputs (probabilities) to trade precision vs recall based on cost. - Use SageMaker Automatic Model Tuning with custom metrics (e.g., recall at a fixed precision, or a custom cost function) published via training logs. - Evaluate with confusion matrices and Precision-Recall curves (often more informative than ROC in imbalanced or safety contexts). These align with AWS Well-Architected principles (especially reliability and operational excellence): design to reduce high-severity failures. Common Misconceptions: High precision can sound desirable (“don’t waste time on false alarms”), but here false alarms are cheap relative to missed leaks. Another trap is thinking “low precision” is the goal; it’s not. You want high recall; precision may drop as a consequence, but it’s not the target. Exam Tips: When costs are asymmetric, map them to FN vs FP. If FN is far more expensive (safety, fraud escape, disease missed), prioritize recall (or F-beta with beta > 1). If FP is more expensive (e.g., blocking legitimate payments), prioritize precision. Always consider threshold tuning, not just the base model.
A media analytics company operates over 200 ML models across 12 AWS accounts, where each model is packaged as a Docker image stored in account-local Amazon ECR repositories with semantic version tags. Compliance requires a single, cross-account central catalog in a separate governance account that supports versioned entries, approval status (Approved/Pending/Rejected), lineage metadata, and audit logs, provides read-only discovery to a shared data science account, allows producer accounts to register new versions via CI/CD, and avoids duplicating or migrating container images between accounts; which solution should the company implement?
ECR cross-account replication copies images to other registries/regions/accounts. This violates the requirement to avoid duplicating or migrating container images. It also does not create a governance catalog with approval states, lineage metadata, or a centralized audit trail for model registration decisions. Replication solves distribution, not model lifecycle governance.
A central ECR repository with replication from producer accounts explicitly duplicates images into the governance account, which the question forbids. Even if it centralizes storage, ECR alone lacks native constructs for model version governance (beyond tags), approval workflows (Approved/Pending/Rejected), and model lineage metadata. You would need additional services to approximate a registry.
SageMaker Model Registry provides a centralized, versioned model catalog with approval status and rich metadata. It can reference container images stored in account-local ECR via image URIs, avoiding image duplication. Cross-account registration and discovery can be enabled with SageMaker resource policies and IAM assume-role patterns, while CloudTrail provides audit logs for compliance.
AWS Glue Data Catalog is designed for datasets (tables, schemas, partitions) and discovery via crawlers, not for container images and ML model governance. Crawling ECR is not a standard Glue pattern, and Glue does not natively support model approval workflows, model package versioning semantics, or MLOps lineage/audit requirements in the way SageMaker Model Registry does.
Core Concept: This question tests centralized ML model governance across multiple AWS accounts without moving artifacts. The best-fit service is Amazon SageMaker Model Registry (part of SageMaker MLOps), which provides a versioned catalog (Model Package Groups), approval workflows, lineage/metadata, and auditability via AWS CloudTrail. Why the Answer is Correct: Option C meets every requirement: a single central catalog in a governance account, versioned entries, approval status (Approved/Pending/Rejected), lineage metadata, and audit logs. SageMaker Model Registry stores model package metadata centrally while allowing the model artifact to be referenced by URI (e.g., an ECR image URI and optional model data in S3). Crucially, it does not require duplicating container images into the governance account. Producer accounts can register new model package versions through CI/CD by calling SageMaker APIs cross-account, and a shared data science account can be granted read-only discovery access to list/describe model package groups and versions. Key AWS Features: - Model Package Groups: logical grouping for a model with semantic versioning handled as successive model package versions. - Model approval workflow: ModelPackageApprovalStatus supports PendingManualApproval/Approved/Rejected patterns used in regulated environments. - Cross-account access: use SageMaker resource-based policies (and/or IAM roles with sts:AssumeRole into the governance account) to allow producer accounts to create model packages and consumer accounts to list/describe them. Pair with ECR repository policies in producer accounts to allow image pull by authorized deployment accounts when needed. - Audit logs: SageMaker API calls are captured in CloudTrail in the governance account, supporting compliance and traceability. - Lineage/metadata: store custom metadata in model package descriptions, tags, and integrate with SageMaker lineage tracking where applicable. Common Misconceptions: ECR replication (A/B) looks like “centralization,” but it explicitly duplicates images, violating the “avoid duplicating/migrating container images” constraint and does not provide approval workflows or lineage. Glue Data Catalog (D) is for data metadata, not container/model governance, and cannot natively represent model approval states and MLOps lifecycle controls. Exam Tips: When you see “model catalog,” “approval status,” “versioned entries,” and “audit/compliance,” think SageMaker Model Registry. When the question forbids artifact movement, prefer metadata catalogs with cross-account references plus resource policies/assume-role patterns, rather than replication-based approaches.
An online travel platform with 220 data scientists uses Amazon SageMaker Model Registry to track more than 1,200 model package versions that are already organized into 95 model groups, and the scientists are aligned to three business domains—pricing optimization, search relevance, and fraud detection—so an ML platform engineer must implement a solution to organize the existing assets by these domains to improve discoverability at scale without modifying any model artifacts, model package versions, approval statuses, or current model group memberships. Which solution will meet these requirements?
Tagging model packages could add domain metadata, but it is not the best fit for organizing the existing assets at scale in the way the question describes. Applying tags to more than 1,200 model package versions creates significant operational overhead and requires ongoing maintenance for every new version. Tags also organize individual resources through metadata rather than providing a clear structural grouping of model groups by domain. Because the requirement is to improve discoverability without changing current group memberships, collections are the more direct and scalable native feature.
Creating new model groups and moving existing models into them violates the explicit requirement not to modify current model group memberships. Model package versions are associated with their model groups, so moving them would change the existing organizational structure and could disrupt downstream processes. This would also introduce unnecessary migration effort and risk for a large inventory of models. Therefore, this option clearly fails the stated constraints.
SageMaker ML Lineage Tracking is used to capture relationships among datasets, jobs, models, and deployments for traceability and reproducibility. It does not automatically determine business domains such as pricing optimization, search relevance, or fraud detection, nor does it serve as a domain-based organizational layer for Model Registry assets. Even if lineage metadata exists, it would not replace an explicit mechanism for grouping model groups for discoverability. As a result, this option does not meet the requirement.
Creating a Model Registry collection for each business domain is the best solution because collections are designed to organize and improve discoverability of existing Model Registry assets at a higher level. This approach allows the engineer to place the current model groups into domain-based collections without moving model package versions or altering the existing model groups themselves. It preserves model artifacts, approval statuses, and current memberships exactly as required. It also scales cleanly for 95 model groups and 1,200+ model package versions, making it the most operationally efficient and purpose-built option.
Core concept: The question is testing the best way to organize existing SageMaker Model Registry assets at scale by business domain without modifying model artifacts, model package versions, approval statuses, or existing model group memberships. Why correct: SageMaker Model Registry collections provide a higher-level organizational construct that can group existing model groups into domain-based buckets such as pricing optimization, search relevance, and fraud detection. Key features: collections improve discoverability across many model groups, avoid moving model package versions, and preserve the current registry structure. Common misconceptions: tags can help with metadata and filtering, but they are not the most purpose-built mechanism here because the requirement is to organize existing assets by domain without changing current group membership, and the question specifically points to grouping model groups rather than tagging every package version. Exam tips: when AWS asks for scalable organization of existing registry assets without restructuring or modifying versions, prefer native organizational constructs like collections over manual tagging or migration.
A smart farming startup must build an ML model in Amazon SageMaker that, given 4K drone images (3840x2160) of orchard rows, automatically finds each ripe fruit and returns a class label plus bounding-box coordinates (x_min, y_min, x_max, y_max) for every detection with confidence >= 0.85; which SageMaker algorithm should they use?
Image classification predicts one label (or a probability distribution over labels) for an entire image. It does not localize objects or output bounding-box coordinates. It could answer questions like “does this image contain ripe fruit?” but cannot return (x_min, y_min, x_max, y_max) for each fruit instance. Therefore it does not meet the localization and multi-instance detection requirements.
XGBoost in SageMaker is a gradient-boosted decision tree algorithm primarily used for tabular data (classification/regression) with engineered features. It does not natively process raw 4K images to produce bounding boxes. While you could theoretically extract image features elsewhere and train a separate model, that would not directly satisfy the object localization requirement and is not the intended SageMaker algorithm for this use case.
Object detection is explicitly designed to both classify and localize objects within an image, producing bounding boxes and confidence scores per detected instance. This matches the requirement to find each ripe fruit in drone imagery and return class labels plus (x_min, y_min, x_max, y_max) coordinates, then filter results by confidence >= 0.85. SageMaker’s built-in Object Detection (SSD-based) is the appropriate choice.
k-NN is a simple instance-based algorithm used for classification or regression on vector/tabular data. It is not a computer vision localization model and does not output bounding boxes from raw images. Even if embeddings were used, k-NN would typically return nearest labels, not spatial coordinates for multiple objects. It does not align with the required detection output format.
Core Concept: This question tests selecting the correct Amazon SageMaker built-in algorithm (or task type) for a computer vision problem. The key is recognizing the required output: multiple detections per image with class labels, bounding-box coordinates (x_min, y_min, x_max, y_max), and confidence thresholding. Why the Answer is Correct: The requirement is to “find each ripe fruit” in 4K drone images and return bounding boxes and class labels for every detection with confidence >= 0.85. That is the definition of object detection (localize + classify multiple instances). SageMaker’s Object Detection algorithm (built on SSD) is designed to predict bounding boxes and class probabilities for objects within an image. After inference, you can filter predictions by confidence score (e.g., keep only detections >= 0.85) to meet the business rule. Key AWS Features: SageMaker Object Detection supports training with labeled bounding boxes (commonly in RecordIO format) and uses convolutional neural networks for feature extraction and localization. It is appropriate for high-resolution imagery; in practice you may resize or tile 4K images during preprocessing to fit GPU memory and improve small-object detection, then map boxes back to original coordinates. You can deploy the trained model to a real-time endpoint for low-latency inference or use batch transform for large offline drone-image runs. Confidence thresholds are typically applied in post-processing, and non-maximum suppression (NMS) helps remove duplicate overlapping boxes. Common Misconceptions: Image classification is often chosen because it’s “images + labels,” but classification outputs a single label (or set of labels) for the whole image and does not provide bounding boxes. XGBoost and k-NN are general ML algorithms for tabular/vector data and are not designed to directly output bounding boxes from raw images. Exam Tips: When you see “bounding boxes,” “(x_min, y_min, x_max, y_max),” “localize,” “multiple objects per image,” or “detections with confidence,” the correct task is object detection. If the question instead asked only “is there ripe fruit in this image?” that would be image classification. Always map the required output format to the ML task type first, then pick the SageMaker algorithm/service that matches.
Want to practice all questions on the go?
Download Cloud Pass for free — includes practice tests, progress tracking & more.
An ML engineer is building a click-through prediction model for a news recommendation system using the Amazon SageMaker XGBoost algorithm, where the binary classifier labels impressions as click or no-click and is trained on 5 million rows with 180 features (including one-hot encoded publisher_id and time bucket features), and with current hyperparameters of max_depth=10, eta=0.1, and subsample=1.0 the model achieves 0.99 AUC and 95% precision on the training set but only 0.68 AUC and 35% precision on a held-out week of traffic and on newly arriving impressions, indicating severe overfitting; to improve generalization to new impressions without changing the algorithm or feature space, what should the engineer do?
Increasing the learning rate (eta) makes each boosting step larger and typically helps fit the training data faster, not generalize better. When a model already achieves extremely high training AUC/precision, a higher eta often increases overfitting and can reduce validation performance. In XGBoost, improving generalization usually involves lowering eta (and increasing number of rounds) rather than raising it.
Removing irrelevant features can reduce overfitting, but it changes the feature space, which the prompt explicitly disallows. Also, the described overfitting is more consistent with excessive model capacity (deep trees memorizing sparse one-hot patterns) than with a few irrelevant features. In exam terms, this option is a feature-engineering/data-prep action, not the best hyperparameter-only fix requested.
Increasing max_depth increases tree complexity and the model’s ability to memorize training data. With max_depth already at 10 and training metrics near-perfect, deeper trees would almost certainly worsen the generalization gap. This is the opposite of what you want when validation AUC and precision collapse on a held-out week and on new impressions.
Decreasing max_depth reduces model capacity by limiting how many splits each tree can make. This directly combats overfitting in boosted trees, especially with high-cardinality one-hot features that enable very specific rules. Shallower trees tend to learn more general patterns that transfer better across weeks and to new impressions, improving validation AUC/precision without changing the algorithm or feature set.
Core Concept: This question tests ML model development and regularization in gradient-boosted decision trees (Amazon SageMaker XGBoost). The symptoms (excellent training metrics but poor held-out/new-traffic metrics) indicate high variance/overfitting. In tree boosting, model capacity is strongly controlled by tree depth and related complexity parameters. Why the Answer is Correct: With max_depth=10, the trees are quite deep, enabling the model to memorize idiosyncrasies in the training week—especially with sparse one-hot publisher_id and time-bucket features that can create many near-unique splits. This yields near-perfect training AUC/precision but weak generalization to a different week and to new impressions. Decreasing max_depth reduces the hypothesis space (shallower trees), forcing the model to learn broader, more stable patterns rather than fitting noise or week-specific correlations. This is a primary, direct lever to reduce overfitting without changing the algorithm or feature space. Key AWS Features / Best Practices: In SageMaker XGBoost, max_depth controls the maximum depth of each boosted tree; smaller values typically improve generalization. This aligns with the AWS Well-Architected principle of performance efficiency and reliability for ML: prefer simpler models when they generalize better. In practice, you would tune max_depth (and often also min_child_weight, gamma, reg_alpha/reg_lambda, subsample/colsample_bytree, and early stopping) using SageMaker Automatic Model Tuning and evaluate on a time-based validation split to match production drift. Common Misconceptions: It can be tempting to “learn faster” by increasing eta or to “add complexity” by increasing max_depth, but both usually worsen overfitting when the model already fits training data extremely well. Another common thought is to remove features; however, the prompt explicitly says not to change the feature space, and feature removal is a data/feature-engineering change rather than a pure hyperparameter generalization fix. Exam Tips: When you see a large gap between training and validation/test performance, think overfitting/high variance. For tree-based boosting, first-line fixes are reducing max_depth, adding subsampling/column sampling, increasing regularization, and using early stopping. If the question restricts algorithm and features, choose the hyperparameter change that reduces model complexity—here, decreasing max_depth.
A media monitoring team ingests 900 hours per week of multilingual podcast audio (MP3), 300 hours per week of conference recordings (MP4 video), and 35,000 blog posts, and must deliver German-language summaries within 24 hours for only the Italian-language items while minimizing engineering effort and avoiding any model training; which solution will meet the requirements in the least amount of time?
Incorrect. This approach requires training and deploying custom models in SageMaker for transcription and then training/deploying an LLM for summarization. It directly violates the requirement to avoid model training and significantly increases engineering effort and delivery time (data labeling, model selection, tuning, hosting, MLOps). SageMaker is appropriate when you need custom models or full control, not for fastest managed summarization.
Option B is the best available answer because it uses Amazon Transcribe batch for the audio and video sources, which is the correct managed AWS service for converting spoken content in MP3 and MP4 files into text. It also uses Amazon Bedrock with Anthropic Claude, which satisfies the requirement to generate German summaries without any model training or infrastructure management. Although translating Italian transcripts to English before generating German summaries is unnecessary, the overall architecture still aligns more closely with the requirements than the other options. Its main weakness is that it does not explicitly mention handling the blog posts, but it remains the closest fit among the provided choices.
Incorrect. Amazon Rekognition analyzes images and videos for labels, faces, text-in-image, and moderation; it is not the service for speech-to-text transcription from audio tracks. Therefore it cannot reliably “convert the media into English text” for podcasts and conference recordings. Even though Bedrock + Claude is suitable for summarization, the ingestion/transcription component is wrong, making the pipeline infeasible.
Incorrect. Amazon Comprehend performs NLP on text (entities, key phrases, sentiment, classification) but does not transcribe audio/video into text, so it cannot handle MP3/MP4 inputs. Additionally, Stable Diffusion is an image generation model, not a text summarization model, so it cannot produce German-language summaries from text. This option misaligns services to tasks and fails core requirements.
Core Concept: This question tests selecting the fastest fully managed AWS AI solution for multilingual content processing across audio, video, and text, while avoiding any model training. The required pipeline must handle podcasts, conference recordings, and blog posts, identify only Italian-language items, and produce German summaries within 24 hours using managed services. Why the Answer is Correct: None of the options is perfectly designed, but option B is the closest fit because it correctly uses Amazon Transcribe for speech-to-text on MP3 and MP4 inputs and Amazon Bedrock with Anthropic Claude for summarization without training. However, its inclusion of Amazon Translate to English is unnecessary for generating German summaries, and more importantly, the option does not explicitly address the 35,000 blog posts. Despite that gap, the other options are clearly less suitable because they misuse AWS services or require custom model training. Therefore B remains the best available answer among the choices. Key AWS Features: - Amazon Transcribe batch supports asynchronous transcription for audio and video speech content at scale. - Amazon Bedrock provides managed foundation models such as Claude for multilingual summarization without infrastructure management or training. - Amazon Translate can translate text between languages, though translating Italian to English before producing German summaries is not required if the model can summarize directly. - For text blog posts, a practical real-world design would send the original text directly to Bedrock after language filtering, but that step is not explicitly included in any option. Common Misconceptions: A is not appropriate because it requires custom model training, which the question explicitly forbids. C is incorrect because Rekognition does not perform speech transcription for podcasts and conference recordings. D is incorrect because Comprehend does not convert audio/video to text, and Stable Diffusion is not a text summarization model. Exam Tips: On AWS AI exams, first map each modality to the correct managed service: Transcribe for speech, Translate for language conversion, Comprehend for text analytics, and Bedrock for generative text tasks. If no option is perfect, choose the one that best satisfies the core requirements with the fewest technical mismatches. Be alert for distractors that misuse services or add unnecessary translation/training steps.
An ML engineer at an online marketplace is building a model to predict the resale price (USD) of used smartphones using 200,000 historical transactions, where the target is a continuous value ranging from $50 to $1,500 and stakeholders require an evaluation metric that reports the average absolute prediction error in the same units (USD); which metric should be used to evaluate the model’s performance?
Accuracy measures the proportion of correct predictions and is primarily used for classification problems with discrete labels (e.g., spam vs. not spam). For a continuous target like smartphone resale price, there is no natural concept of “correct” unless you artificially bin prices into categories, which would change the problem. Accuracy also would not report error in USD, so it does not meet stakeholder requirements.
Area Under the ROC Curve (AUC) evaluates how well a binary classifier ranks positive examples above negative ones across all thresholds. It is not designed for regression and does not output an error magnitude in the same units as the target. Even if you converted the problem into a classification task (e.g., above/below a price), AUC would measure ranking quality, not average absolute dollar error.
F1 score is the harmonic mean of precision and recall for classification tasks, especially useful with imbalanced classes. It requires discrete class labels and a decision threshold, neither of which naturally exist for predicting a continuous resale price. F1 does not provide an error in USD and would only apply if the problem were reframed into categories (e.g., low/medium/high price), which the question does not indicate.
Mean Absolute Error (MAE) is a standard regression metric that computes the average absolute difference between predicted and actual values. Because it uses absolute differences, MAE is expressed in the same units as the target variable (USD), directly satisfying the requirement to report “average absolute prediction error in USD.” It is also straightforward to interpret for stakeholders and is commonly used in model evaluation pipelines.
Core Concept: This question tests selecting an appropriate evaluation metric for a supervised learning problem. Because the target variable is a continuous resale price in USD, this is a regression task (not classification). The metric must express average absolute prediction error in the same units as the target. Why the Answer is Correct: Mean Absolute Error (MAE) directly measures the average magnitude of errors between predicted and actual values: MAE = average(|y - ŷ|). Because it uses absolute differences, the result is in the same unit as the target (USD). If stakeholders want “average absolute prediction error in USD,” MAE is the most direct match. It is also easy to interpret: an MAE of 75 means the model is off by $75 on average, which aligns with business expectations for pricing. Key AWS Features / Best Practices: In AWS ML workflows (e.g., Amazon SageMaker training jobs and model evaluation), regression metrics commonly include MAE, MSE/RMSE, and R2. MAE is often preferred when interpretability in business units matters. It is also more robust to outliers than MSE/RMSE because it does not square errors (though it still reflects outliers linearly). In SageMaker, you can compute MAE during training (custom metric definitions, built-in algorithm metrics where available) or in a post-training evaluation step (SageMaker Processing, Pipelines) and track it in Amazon CloudWatch or SageMaker Experiments. Common Misconceptions: Candidates often pick “Accuracy” or “F1” because they are popular metrics, but those apply to classification where outputs are discrete labels. AUC is also classification-specific and measures ranking quality across thresholds; it does not produce an error in USD. Another common confusion is between MAE and RMSE: RMSE is also in USD but emphasizes large errors more; the question explicitly asks for “average absolute” error, which is MAE. Exam Tips: First identify the ML problem type: continuous target implies regression. Then match stakeholder requirements to metric properties: “absolute” and “same units” strongly indicates MAE. Remember: Accuracy/F1/AUC are classification metrics; MAE/RMSE/R2 are regression metrics. When business users want an interpretable “average dollars off,” MAE is usually the best answer.
An online lending platform with 2.5 million past applications and 18 features (including age_group and income_bracket) is training a binary default-risk model in Amazon SageMaker and needs to examine both the training data and batch prediction outputs to detect and quantify patterns (e.g., demographic parity difference > 0.1 between applicants aged 18–25 vs 60+) that could skew performance across protected groups; which solution provides this level of analysis?
Amazon CloudWatch focuses on infrastructure and application observability (CPU, memory, network, logs, alarms). While useful for monitoring SageMaker training job resource utilization and troubleshooting performance bottlenecks, it does not compute fairness or bias metrics such as demographic parity difference across protected groups. CloudWatch cannot analyze training data distributions or compare prediction outcomes by sensitive attributes without significant custom implementation outside its intended purpose.
AWS Glue DataBrew is a visual data preparation service that can profile data and apply transformations via recipes. It can help clean data, handle missing values, and generate summary statistics, which may support downstream bias mitigation efforts. However, DataBrew does not natively provide formal bias/fairness metrics on training data and batch predictions (e.g., demographic parity difference) nor produce standardized bias reports for ML governance like SageMaker Clarify does.
Amazon SageMaker Clarify is designed to detect bias in ML workflows and provide explainability. It can evaluate pre-training bias in the dataset (e.g., label imbalance across age groups) and post-training bias in predictions from batch inference, computing metrics such as demographic parity and related group fairness measures. Clarify produces reports stored in S3 and integrates with SageMaker pipelines/Studio, meeting the requirement to detect and quantify skew across protected groups.
AWS Lambda can automate preprocessing steps (validation, normalization, feature engineering triggers) and enforce consistent input quality, but it does not provide built-in bias detection or fairness metric computation across protected groups. Implementing demographic parity difference calculations in Lambda would require custom code, careful statistical definitions, and governance artifacts. The question asks for a solution that provides this level of analysis directly, which aligns with SageMaker Clarify.
Core Concept: This question tests bias detection and quantification for both training data and model predictions in Amazon SageMaker. The AWS service purpose-built for this is Amazon SageMaker Clarify, which provides bias metrics (pre-training and post-training) and explainability (feature attributions) for models. Why the Answer is Correct: The platform must examine (1) the training dataset and (2) batch prediction outputs to detect and quantify patterns such as demographic parity difference exceeding a threshold between protected groups (e.g., age 18–25 vs 60+). SageMaker Clarify directly supports this workflow by computing bias metrics on the input dataset (pre-training bias) and on inference results (post-training bias) using a specified sensitive attribute (e.g., age_group) and a label/outcome (e.g., default vs no default). Clarify can run as a processing job and integrates with SageMaker batch transform outputs, producing a bias report that includes metrics like demographic parity, disparate impact, and other group fairness measures. Key AWS Features: Clarify supports: - Pre-training bias analysis: detects imbalances in labels and features across groups. - Post-training bias analysis: evaluates prediction outcomes across groups (including batch inference). - Configurable facets (sensitive features like age_group/income_bracket) and groups (e.g., 18–25 vs 60+). - Reports and visualizations (via SageMaker Studio) plus artifacts stored in Amazon S3 for auditability. - Explainability via SHAP-based feature attribution to understand drivers of predictions, which complements bias metrics. Common Misconceptions: It’s tempting to choose data-prep tools (Glue DataBrew) or automation (Lambda) because bias can be mitigated by transforming data. However, the requirement is to detect and quantify bias patterns with formal fairness metrics on both data and predictions, not merely to clean or transform data. CloudWatch is operational monitoring, not fairness analysis. Exam Tips: When you see keywords like “bias,” “protected groups,” “demographic parity,” “disparate impact,” “explainability,” and “training data + predictions,” the exam is pointing to SageMaker Clarify. Distinguish Clarify (fairness/explainability) from Model Monitor (data/model drift and quality) and from general ETL tools (DataBrew/Glue) that don’t compute fairness metrics out of the box.
A video streaming platform runs a real-time content moderation model on an Amazon SageMaker real-time endpoint that serves about 1,500 requests per minute with a p95 latency SLO of 120 ms. A new model version trained on a larger multilingual dataset is ready, and the team must evaluate its accuracy and latency using the same live production requests for 24 hours while storing its inferences for offline comparison, without affecting any production user decisions or latency. Which solution will meet these requirements?
SageMaker Debugger primarily helps during training and (to a limited extent) inference monitoring by collecting tensors/metrics and applying rules to detect issues like overfitting or vanishing gradients. It is not intended to mirror live production inference requests to a separate model version for side-by-side output comparison. It also does not inherently guarantee zero impact on production decisions or provide the shadow-evaluation workflow required here.
Blue/green with all-at-once traffic shifting moves 100% of production traffic to the new model immediately. That would directly affect production user decisions and risks violating the latency SLO if the new model is slower. It also prevents a controlled 24-hour evaluation period where the old model remains the sole decision-maker. This is a deployment strategy, not a no-impact evaluation method.
Canary shifting (e.g., 10% for 24 hours) is useful for gradual rollouts and monitoring, but it still routes a portion of real users to the new model’s responses. That violates the requirement to not affect any production user decisions. Additionally, even a small percentage can introduce user-visible latency or quality changes. Canary is for controlled release, not shadow evaluation.
Shadow testing with a shadow variant mirrors the same live production requests to the new model while keeping the production variant’s responses as the only outputs returned to the application. This enables accurate measurement of real-world latency and output quality over 24 hours, and the shadow outputs can be stored (e.g., via SageMaker Data Capture to S3) for offline comparison, all without impacting user decisions or production response latency.
Core Concept: This question tests safe evaluation of a new model in production using Amazon SageMaker real-time endpoints without impacting user-facing decisions or latency. The key concept is running an additional model variant that receives the same live requests (for accuracy/latency measurement) while keeping the production variant as the only one that returns responses to the application. Why the Answer is Correct: Shadow testing with a shadow variant (D) is designed for exactly this requirement: send a copy of production traffic to a new model version for a fixed evaluation window (24 hours) while ensuring the production response path remains unchanged. This allows the team to measure real-world accuracy and latency under true production load and data distribution, and to store the shadow model’s inferences for offline comparison, all without affecting production user decisions. Because the production variant continues to serve 100% of responses, user-visible behavior and decisioning are not altered. Key AWS Features: In SageMaker, you can deploy multiple production variants behind one endpoint and configure a shadow variant so that requests are mirrored to it while responses are ignored for the client. You can capture the shadow variant’s outputs using SageMaker Data Capture (capture input/output payloads) and store them in Amazon S3 for offline analysis. You can also use CloudWatch metrics to compare latency and invocation counts per variant, and optionally enable autoscaling for the shadow variant to handle mirrored load without throttling. Common Misconceptions: Canary or blue/green shifting (B/C) are often used for progressive rollouts, but they explicitly route some percentage of real user traffic to the new model for actual responses—this violates the requirement of not affecting production user decisions. Debugger (A) is for debugging/training/monitoring tensors and detecting issues, not for running a parallel “no-impact” live A/B evaluation of inference outputs. Exam Tips: When the question says “use the same live production requests” AND “without affecting production decisions,” look for “shadow testing,” “traffic mirroring,” or “shadow variant.” If any option shifts traffic for real responses (even 1%), it changes user outcomes and is not acceptable. Pair shadow testing with Data Capture to persist inferences for offline comparison.
Want to practice all questions on the go?
Download Cloud Pass for free — includes practice tests, progress tracking & more.
A data scientist exported a scikit-learn churn model outside Amazon SageMaker and stored a 7.8-GB model.tar.gz artifact in an SSE-S3–encrypted bucket (s3://retail-ml-artifacts-prod/models/churn/2025-07-01/), and needs to make this model discoverable to a business analyst using SageMaker Canvas in the same SageMaker domain for no-code evaluation and iterative tuning; which combination of requirements must be met to share the model with the Canvas user? (Choose two.)
Incorrect. Sharing models with SageMaker Canvas is intended within the same SageMaker domain so that Studio/Canvas users can access shared resources governed by that domain’s roles and settings. Different domains typically imply separate user profiles, roles, and resource boundaries, which would make sharing harder, not a requirement. The question explicitly says they are in the same domain.
Correct. Canvas ultimately needs to access the model artifact stored in S3. Even with SSE-S3 encryption (managed by S3), the Canvas user’s execution role must be authorized by IAM/bucket policy to read the object (s3:GetObject) and often list the prefix (s3:ListBucket). Without S3 read permissions, the model cannot be imported/used even if it is registered.
Correct. For a model built outside SageMaker/Canvas to be discoverable in Canvas, it should be registered in SageMaker Model Registry as a model package/version. The registry provides a governed catalog of models (versions, metadata, approval) that Studio/Canvas can browse. Pointing Canvas at an arbitrary S3 URI alone does not satisfy the “discoverable to a business analyst” requirement.
Incorrect. AWS Marketplace is for distributing products (including ML models) to external customers/accounts under commercial terms. It is not used for internal sharing between users in the same SageMaker domain. Marketplace publishing adds unnecessary packaging, legal, and billing constructs unrelated to Canvas discovery.
Incorrect. Deploying to a SageMaker real-time endpoint is not a prerequisite for sharing a model with Canvas. Canvas can evaluate and work with models via managed workflows and governed model artifacts; hosting is a separate lifecycle step. Endpoints are relevant for real-time inference, not for making a model discoverable for no-code evaluation/tuning.
Core Concept: This question tests how SageMaker Canvas discovers and uses models created outside Canvas, and the governance/permissions path for sharing models across personas within a SageMaker Studio domain. The key services are Amazon S3 (model artifacts), SageMaker Model Registry (model packages/versions), and IAM/SageMaker domain execution roles. Why the Answer is Correct: To make an externally built scikit-learn model “discoverable” in Canvas, the model must be surfaced through SageMaker’s model governance layer. Registering the model as a model package/version in SageMaker Model Registry (within the same domain/account/region context) is the standard mechanism that enables Studio/Canvas to list and consume approved/registered models rather than arbitrary S3 objects. Additionally, even if the model is registered, Canvas (via the Canvas user’s execution role) must be able to read the underlying model.tar.gz in S3. With SSE-S3 encryption, there is no KMS key policy to manage, but S3 authorization still applies: the role needs s3:GetObject (and typically s3:ListBucket for the prefix) on the bucket/key. Key AWS Features: - SageMaker Model Registry: model packages, versions, approval status, lineage, and controlled sharing to downstream tools. - IAM and S3 access control: bucket policy and role permissions for s3:GetObject to the artifact prefix. - SSE-S3: simplifies encryption management compared to SSE-KMS, but does not remove the need for S3 permissions. Common Misconceptions: It’s tempting to think deploying to a real-time endpoint is required for Canvas, but discoverability/sharing is about governance and access, not hosting. Similarly, AWS Marketplace is unrelated to internal model sharing. Domain separation is also incorrect: Canvas and the data scientist must be in the same SageMaker domain to share resources in that domain context. Exam Tips: When you see “discoverable in Canvas/Studio,” think “Model Registry + permissions.” When you see “model artifacts in S3,” always validate the consuming persona’s IAM role can read the exact S3 prefix/object (encryption type affects whether KMS permissions are also needed).
A radiology analytics startup currently trains and serves image segmentation models on its private servers using custom TensorFlow 2.12 Python 3.10 scripts with proprietary 12 TB DICOM data and domain-specific preprocessing, and must migrate both training and inference to AWS within 2 weeks while preserving the existing code and running on a single-GPU instance (e.g., ml.p3.2xlarge with 1×V100); which approach will achieve this with the least effort?
SageMaker built-in algorithms can reduce ML engineering effort when your use case matches the provided algorithm and input format. However, they do not “run your existing TensorFlow scripts.” Migrating proprietary DICOM preprocessing and a custom segmentation pipeline into a built-in algorithm workflow typically requires significant refactoring and data transformation, which conflicts with the requirement to preserve existing code and move quickly within 2 weeks.
SageMaker Script Mode with prebuilt TensorFlow containers is designed to run your existing TensorFlow training and inference code with minimal changes. You bring your Python scripts; SageMaker provides the managed infrastructure, GPU-enabled framework container, data channel mounting from S3, and model artifact handling. This best satisfies the constraints: fastest migration, preserves TF 2.12/Python 3.10 code, and supports single-GPU instances like ml.p3.2xlarge.
Bring-your-own-container (BYOC) works for maximum flexibility (custom OS packages, niche dependencies, unsupported framework versions). But it requires building, testing, securing, and maintaining a Docker image, plus ensuring CUDA/cuDNN compatibility for GPU. Under a 2-week deadline and with a mainstream framework like TensorFlow, BYOC is usually more effort than necessary compared to SageMaker’s prebuilt TensorFlow DLC + Script Mode.
AWS Marketplace models may accelerate prototyping, but they rarely match specialized radiology segmentation requirements and do not preserve the startup’s proprietary training code and preprocessing. Adapting third-party models to proprietary DICOM pipelines and domain-specific labeling often takes substantial effort and introduces licensing/compliance concerns. It also doesn’t directly address the requirement to migrate existing training and inference scripts with minimal change.
Core Concept: This question tests Amazon SageMaker’s ability to run existing ML code with minimal refactoring by using managed training and hosting on GPU instances via SageMaker Script Mode and AWS Deep Learning Containers (DLCs) for TensorFlow. Why the Answer is Correct: The startup must migrate within 2 weeks, preserve existing TensorFlow 2.12 / Python 3.10 scripts, and run on a single-GPU instance (e.g., ml.p3.2xlarge). SageMaker Script Mode with the prebuilt TensorFlow container is purpose-built for this: you provide your existing entry-point scripts (training and inference), and SageMaker handles provisioning, GPU drivers/CUDA compatibility in the container, data channel mounting from S3, logging, metrics, and model artifact management. This is the least-effort path because it avoids rewriting code to fit built-in algorithms and avoids the operational overhead of building/patching a custom container. Key AWS Features: - SageMaker Training jobs using the TensorFlow DLC image that matches TF 2.12 and Python 3.10 (or the closest supported tag), with GPU support on ml.p3.2xlarge. - Script Mode: pass hyperparameters, specify entry_point/source_dir, and use SageMaker environment variables (e.g., SM_CHANNEL_TRAIN, SM_MODEL_DIR) to locate data and write model artifacts. - SageMaker Hosting: deploy the resulting model to a real-time endpoint using the same framework container and an inference script (model_fn/predict_fn/input_fn/output_fn), preserving your preprocessing. - Data handling: store the 12 TB DICOM dataset in S3 and stream/shard via S3 input channels; optionally use Pipe mode where supported to reduce local disk needs. Common Misconceptions: Built-in algorithms (Option A) can sound “fast,” but they require adopting AWS-provided model implementations and data formats, which conflicts with proprietary preprocessing and existing TensorFlow scripts. BYOC (Option C) is flexible, but it adds time-consuming container engineering, security patching, and dependency management—risky under a 2-week deadline. Marketplace models (Option D) do not preserve proprietary training code and rarely match specialized medical segmentation requirements. Exam Tips: When the prompt emphasizes “preserve existing code,” “least effort,” and a standard framework (TensorFlow/PyTorch), default to SageMaker framework containers + Script Mode. Choose BYOC only when you need unsupported frameworks, custom system libraries, or very specific runtime constraints not met by DLCs. Built-in algorithms are best when you can conform to their expected inputs and don’t need custom training logic.
A fitness app company serves the current version of a recommendation model on an Amazon SageMaker real-time endpoint using 8 Reserved Instances of an accelerated instance type (g5.xlarge), and exactly one additional Reserved Instance of the same type is available exclusively for the deployment process; during the transition, the solution must reuse the original 8 instances to host both old and new model versions with zero downtime or service interruption. Which solution will meet these requirements?
Blue/green with all-at-once traffic shifting requires the new green environment to be fully provisioned and ready before 100% of traffic is cut over. For an endpoint currently running on 8 instances, this effectively requires enough additional capacity to stand up the replacement fleet before the switch. Because only 1 extra instance is available, there is not enough capacity to prepare a full green fleet for an all-at-once cutover. Therefore this option does not satisfy the stated capacity constraint.
A blue/green deployment with canary traffic shifting and a size of 10% is the best fit because 10% of an 8-instance endpoint corresponds to 1 instance, matching the exactly one additional Reserved Instance available. SageMaker can launch a green fleet with 1 instance for the new model, send a small portion of traffic to validate health and performance, and then continue the deployment while reusing the original 8 instances as capacity is transitioned. This approach maintains zero downtime because the blue fleet continues serving production traffic while the green environment is validated. It also aligns directly with the requirement that the original 8 instances be reused during the transition rather than requiring a full parallel fleet.
A shadow test mirrors a percentage of production requests to a shadow variant, but the shadow responses are not returned to users and the deployment is intended for validation rather than production cutover. It still requires separate capacity to run the shadow model in parallel, and it does not itself perform the controlled replacement of the production model version. The question asks for a deployment strategy that transitions versions with zero downtime, not just a test mechanism. Therefore shadow testing does not meet the full deployment requirement.
A rolling deployment updates endpoint instances in batches, replacing old instances with new ones over time, but it is not the best match for the requirement that both old and new model versions be hosted during the transition using the original 8 instances plus exactly 1 extra instance. The question specifically emphasizes traffic-safe coexistence of versions during transition, which is what blue/green canary is designed for. Rolling deployment is more about incremental in-place replacement and does not map as cleanly to the explicit 10% extra-capacity pattern implied by 1 additional instance out of 8. For this reason, rolling batch size 1 is less appropriate than blue/green canary.
Core concept: This question tests Amazon SageMaker endpoint deployment guardrails and how deployment strategies consume capacity during model updates. The key requirement is zero downtime while using 8 existing g5.xlarge instances for production and exactly 1 additional instance for deployment, with the original 8 reused to host both old and new versions during the transition. Blue/green deployments in SageMaker can be configured with canary traffic shifting so that only a small green fleet is created first, which fits a constrained-capacity rollout. A common misconception is that rolling deployment is always the best choice when spare capacity is limited, but rolling updates replace instances in batches rather than running old and new endpoint fleets side by side in the way described here. Exam tip: when a question explicitly mentions traffic shifting percentages and one small amount of extra capacity for safe cutover, think blue/green canary rather than rolling or shadow.
A media analytics team runs AWS Batch array preprocessing jobs on a job queue every 4 hours and sometimes launches them manually; they are building Amazon SageMaker Pipelines that will consume the S3 outputs of those jobs during the data processing phase and require the pipeline to start within 2 minutes after a job succeeds without introducing state machines or long‑running services, so which approach integrates the AWS Batch jobs with the pipelines with the least operational overhead?
Step Functions can orchestrate AWS Batch and SageMaker Pipelines with explicit control flow (submit job, wait, then start pipeline). However, the question explicitly says not to introduce state machines, which rules Step Functions out despite being a valid architecture. It also adds operational overhead in terms of workflow definition, state management, and potentially more complex error handling than an event-driven trigger.
SageMaker Processing steps take inputs from data sources such as S3 (or FSx/EFS), not from AWS Batch job ARNs. Pipelines cannot directly “consume” a Batch job as an input artifact by ARN. The correct integration point is the S3 outputs produced by Batch, which should be passed as pipeline parameters or discovered by convention, not by referencing Batch job identifiers as processing inputs.
Callback steps are designed for human approval or external systems to signal completion back to the pipeline via a callback token. Using them to run AWS Batch would require an external component (e.g., Lambda or a custom service) to start the Batch job and then call back when it finishes. That introduces extra moving parts and operational overhead, and it is not the simplest way to react to an already-running Batch job’s success event.
EventBridge is purpose-built for reacting to AWS service events with minimal operations. AWS Batch emits Job State Change events, and an EventBridge rule can match SUCCEEDED and invoke SageMaker’s StartPipelineExecution quickly (typically seconds). This meets the “start within 2 minutes” requirement, works for both scheduled and manual job runs, and avoids state machines or long-running pollers while keeping the integration loosely coupled and resilient.
Core Concept: This question tests event-driven orchestration for ML workflows with minimal operations. The key services are Amazon EventBridge (to react to AWS Batch job state changes) and Amazon SageMaker Pipelines (to run the ML workflow). The requirement explicitly avoids state machines and long-running services, pushing you toward managed, serverless event routing. Why the Answer is Correct: Amazon EventBridge can natively receive AWS Batch Job State Change events (e.g., SUCCEEDED) and route them to targets with near-real-time delivery. By creating an EventBridge rule that matches successful completion of the specific Batch jobs/queues (including array jobs) and setting the target to SageMaker (StartPipelineExecution), the pipeline can start within the 2-minute SLA after the Batch job succeeds. This approach also works whether jobs run on a schedule (every 4 hours) or are launched manually, because the trigger is the job success event, not the job submission mechanism. Key AWS Features: 1) EventBridge rules with event patterns for AWS Batch job state changes (detail.status = "SUCCEEDED", jobQueue/jobName filters). 2) EventBridge targets for SageMaker Pipelines (StartPipelineExecution) and optional input transformation to pass dynamic values (e.g., S3 output prefix, jobId) as pipeline parameters. 3) Optional dead-letter queue (SQS) and retry policy on the EventBridge target for resilience. 4) IAM: EventBridge needs permission to call sagemaker:StartPipelineExecution; SageMaker steps need S3 read permissions for the Batch outputs. Common Misconceptions: Step Functions is a common orchestration answer, but it is explicitly disallowed (“without introducing state machines”). Callback steps in Pipelines sound like they can “wait” for external work, but they still require an external actor to call back and are not the simplest integration for existing Batch jobs. Referencing Batch job ARNs as pipeline inputs is not how SageMaker Processing inputs work; they consume data locations (e.g., S3), not job metadata. Exam Tips: When you see “start within X minutes after an event” and “least operational overhead,” think EventBridge. If the question forbids state machines/servers, prefer managed event routing (EventBridge) over Step Functions or custom pollers. Also remember SageMaker Pipelines can be triggered via API, and EventBridge is the standard way to react to AWS service events like Batch job state changes.
A robotics R&D company operates six Amazon SageMaker notebook instances across two VPC subnets for nine ML engineers; each instance was created with its own execution IAM role, and whenever engineers need additional read-only access to two S3 buckets (s3://cv-raw-2025 and s3://cv-curated-2025) during quarterly audits, the security team must update all six roles separately, so the company wants to centralize permission changes so that a single update applies to every notebook instance without granting broad administrator privileges; which solution will meet this requirement?
Correct. SageMaker notebook instances use an execution IAM role to access AWS services. Attaching the same role to all six notebooks centralizes authorization so the security team updates permissions once (ideally by editing/attaching a single customer-managed policy). This satisfies least privilege by granting only required S3 read-only access to the two buckets plus minimal SageMaker permissions, avoiding administrator-level access.
Incorrect. IAM groups cannot be associated directly with SageMaker notebook instances. Groups are a mechanism to assign permissions to IAM users, not to AWS compute/service identities. Even if engineers are in a group, the notebook instance still uses its execution role for AWS API calls, so changing a group would not reliably centralize the notebook’s runtime permissions.
Incorrect and insecure. Using a single IAM user’s long-term credentials in notebook instances is against AWS best practices (risk of key exposure, rotation burden, lack of per-session credentials). Attaching AdministratorAccess violates the requirement to avoid broad admin privileges and breaks least-privilege principles. SageMaker is designed to use execution roles with temporary credentials, not embedded access keys.
Incorrect. This combines multiple flawed ideas: IAM groups still cannot be attached to notebook instances, and granting AdministratorAccess is explicitly broader than required. While roles can be assumed by principals (users/groups via policies), the notebook instance itself needs an execution role; associating a group with a role does not automatically make the notebook use that role, and it does not meet least privilege.
Core Concept: This question tests IAM role design for Amazon SageMaker notebook instances, specifically how to centralize and govern permissions using execution roles and least privilege. SageMaker notebook instances assume an IAM execution role to access AWS resources (like S3) without embedding long-term credentials. Why the Answer is Correct: Option A centralizes permissions by standardizing all notebook instances on a single execution IAM role. When quarterly audits require additional read-only access to s3://cv-raw-2025 and s3://cv-curated-2025, the security team updates one policy (inline or attached managed policy) on that single role and the change applies to all six notebook instances immediately (subject to IAM policy propagation). This meets the requirement of “a single update applies to every notebook instance” while avoiding broad administrator privileges by granting only S3 read permissions (e.g., s3:ListBucket on the buckets and s3:GetObject on the bucket prefixes/objects) plus the minimum SageMaker permissions needed for notebooks. Key AWS Features: - SageMaker notebook execution role: the role is assumed by the notebook instance to call AWS APIs. - IAM managed policies: attach a customer-managed policy (e.g., “AuditS3ReadOnly”) to the shared role so quarterly changes are made by editing one policy document. - Least privilege: scope S3 permissions to the two buckets and required actions only; avoid wildcard resources/actions. - Operational governance: one role reduces drift and inconsistent permissions across notebooks. Common Misconceptions: A common trap is thinking IAM groups can be “attached” to AWS services. Groups only grant permissions to IAM users, not to SageMaker notebook instances. Another misconception is using an IAM user’s access keys in notebooks for simplicity; this violates best practices and increases credential leakage risk. Exam Tips: For AWS services that run code (SageMaker, EC2, Lambda), prefer IAM roles over IAM users and access keys. When asked to “centralize permission changes,” look for shared roles and/or shared managed policies. Also watch for options that introduce AdministratorAccess—these almost never align with least-privilege requirements in exam scenarios.
Want to practice all questions on the go?
Download Cloud Pass for free — includes practice tests, progress tracking & more.
A public healthcare network is deploying an internal legal-assistant chatbot that handles about 2,000 queries per day via API calls to Amazon Q Business; compliance policy requires that the model’s responses must never include the confidential codename "Project Raven" (exact phrase match), even if that string appears in the indexed source documents, and the control must be enforced at response time without modifying the existing index—what should the team do to meet this requirement?
Correct. Blocking “Project Raven” as a blocked phrase in Amazon Q Business is an output-time control that prevents the exact string from appearing in responses, even if it exists in indexed documents. This meets the compliance requirement of “must never include” and satisfies the constraint of enforcing at response time without changing or rebuilding the existing index.
Incorrect. Excluding retrieval results that contain “Project Raven” is a retrieval-time mitigation, not a response-time guarantee. It can reduce exposure but cannot ensure the phrase never appears, because the model could still generate the phrase from other retrieved passages, user prompts, or partial context. The requirement demands deterministic response-time blocking.
Incorrect. Building a new Amazon Kendra index that omits documents containing “Project Raven” violates the constraint “without modifying the existing index” (re-indexing/rebuilding is effectively modifying the indexing approach). It also still doesn’t provide a strict response-time guarantee if the phrase can be introduced via prompts or other sources.
Incorrect. Document attribute boosting only changes ranking/relevance (deprioritization) and is not a security control. Even if content mentioning “Project Raven” is ranked lower, it can still be retrieved and used in generation, and the model could still output the phrase. Compliance requires an absolute block, not probabilistic relevance tuning.
Core Concept: This question tests Amazon Q Business security and governance controls that operate at response time (output guardrails), specifically preventing disclosure of sensitive terms regardless of what is stored in the underlying indexed content. This aligns with the “Security” and “Data protection” pillars of the AWS Well-Architected Framework. Why the Answer is Correct: The requirement is explicit: the chatbot’s responses must never include the exact phrase “Project Raven,” even if it exists in indexed documents, and the control must be enforced at response time without modifying the existing index. Amazon Q Business provides administrative controls to block specific words/phrases from appearing in generated responses. Configuring “Project Raven” as a blocked phrase enforces an output-time policy, ensuring the term is filtered/redacted/blocked in the final response returned by the API, independent of retrieval results. Key AWS Features: In Amazon Q Business, blocked phrases (sometimes described as blocked words/phrases) are designed for compliance and safety by preventing certain strings from being emitted in responses. This is an output control (response-time enforcement), which is exactly what the policy demands. It complements other controls like access control integration and content filtering, but uniquely satisfies the “never include this exact phrase” constraint without re-indexing. Common Misconceptions: A common trap is to focus on retrieval-time filtering (excluding documents or results). Even if retrieval excludes some items, the model could still produce the phrase via other retrieved content, user prompt injection, or model behavior. Another misconception is that “deprioritizing” content (boosting) reduces risk; it does not guarantee non-disclosure. Exam Tips: When you see “must never appear in the response” and “enforced at response time,” look for output guardrails such as blocked phrases/terms rather than retrieval tuning, ranking, or re-indexing. Also note constraints like “without modifying the existing index” eliminate rebuild/re-ingestion solutions. For healthcare/compliance scenarios, prefer deterministic controls (explicit blocking) over probabilistic relevance tuning.
A data science team at a fintech startup plans to run a distributed Amazon SageMaker training job on 6 ml.p3.8xlarge instances inside private subnets and must ensure that all data in transit used by SageMaker processes during the training run—including inter-node traffic and framework coordination messages—is encrypted end to end without changing any at-rest encryption settings; which solution will meet these requirements?
Incorrect. Batch Transform is used for offline/batch inference, not for running distributed training jobs. Enabling encrypted communications for Batch Transform would not affect the network traffic patterns of a SageMaker training cluster (e.g., gradient exchange, MPI/NCCL collectives). The requirement explicitly targets a distributed training run and inter-node coordination traffic, which Batch Transform settings do not cover.
Correct. Inter-container traffic encryption for a SageMaker training job is designed to encrypt data in transit between the instances/containers participating in distributed training. This includes node-to-node traffic and coordination messages required by distributed frameworks. It satisfies the “end-to-end in transit encryption” requirement for the training cluster without requiring any changes to at-rest encryption settings for data, volumes, or artifacts.
Incorrect. Providing a KMS key in the training job request primarily enables encryption at rest (e.g., EBS volumes used by training instances and/or output artifacts written to S3, depending on configuration). While important for storage security, it does not ensure that inter-node or framework coordination traffic during distributed training is encrypted in transit. The question explicitly focuses on in-transit encryption during the run.
Incorrect. A KMS key for a SageMaker Studio Domain governs encryption at rest for Studio-related storage (e.g., EFS volume for user home directories) and certain Studio resources. It does not control the runtime network encryption behavior of a separate SageMaker distributed training job cluster. The requirement is specific to training job in-transit traffic, not Studio domain storage encryption.
Core Concept: This question tests Amazon SageMaker distributed training network security—specifically encrypting data in transit for traffic that occurs inside the training cluster (node-to-node communication, coordination/control messages, and container-to-container traffic) without modifying at-rest encryption. Why the Answer is Correct: For distributed training on multiple instances (6 ml.p3.8xlarge) SageMaker uses a cluster of training containers that exchange gradients/parameters and coordination messages (for example, MPI/NCCL/Horovod or framework-specific collectives). Enabling SageMaker’s inter-container traffic encryption ensures that all traffic between the training instances/containers in the cluster is encrypted in transit end to end. This directly addresses the requirement to encrypt inter-node traffic and framework coordination messages during the training run, and it does so without changing any at-rest encryption settings. Key AWS Features: SageMaker training jobs support “inter-container traffic encryption” (sometimes described as encrypting communication between nodes in a distributed training job). When enabled, SageMaker configures the training cluster so that network traffic among the instances participating in the job is encrypted. This is distinct from encrypting data at rest in S3/EBS or encrypting model artifacts; it is specifically about in-transit encryption within the distributed training fabric. Running in private subnets is compatible and often paired with VPC-only access, but private subnets alone do not guarantee encryption of east-west traffic. Common Misconceptions: A frequent trap is assuming that specifying a KMS key (for the training job or Studio domain) encrypts “everything.” KMS keys in SageMaker primarily control encryption at rest (e.g., EBS volumes attached to training instances, model artifacts in S3, or Studio storage). They do not automatically encrypt the runtime network traffic between distributed training nodes. Another misconception is confusing Batch Transform settings with training jobs; Batch Transform is an inference/batch scoring feature, not distributed training. Exam Tips: When you see requirements like “inter-node traffic,” “framework coordination messages,” or “east-west traffic within the cluster,” look for features explicitly about in-transit encryption for distributed training (inter-container/inter-node traffic encryption). If the requirement says “without changing at-rest encryption,” eliminate KMS-only answers unless the question is about storage encryption. Also distinguish training vs. Batch Transform vs. Studio domain configuration—each has different security controls.
A healthcare analytics startup plans to onboard 60 data scientists across 8 AWS accounts in the next 14 days using Amazon SageMaker notebook instances to analyze de-identified patient data in a HIPAA-aligned environment. The security team requires that notebook instances must never be created with root access enabled, regardless of whether they are launched via the AWS Management Console, AWS CLI/SDK, AWS Service Catalog, or AWS CloudFormation, and the control must proactively block such creations rather than delete noncompliant resources after the fact; what solution will enforce this across all accounts and Regions?
Correct. SageMaker supports the service-specific condition key sagemaker:RootAccess, which can be evaluated in IAM policies for CreateNotebookInstance and UpdateNotebookInstance requests. By using an explicit Deny that requires RootAccess to be Disabled, AWS blocks the API call before the notebook instance is created or modified, which satisfies the requirement for proactive enforcement. Applying that Deny in an AWS Organizations SCP makes it effective across all member accounts and Regions, including for administrators in those accounts. This also covers launches from the Console, CLI/SDK, CloudFormation, and Service Catalog because those provisioning paths ultimately invoke the same SageMaker APIs.
Incorrect. AWS KMS encryption controls data-at-rest protection for EBS volumes and other encrypted resources, but it does not govern SageMaker notebook instance OS-level settings like RootAccess. Key policies can restrict who can use a CMK, not whether a notebook is created with root enabled. This does not meet the requirement to prevent root access configuration.
Incorrect. EventBridge + Lambda deletion is reactive remediation. A notebook with root access could exist for seconds (or longer if the function fails), violating “must never be created” and “proactively block.” It also introduces operational risk (missed events, throttling, retries) and does not provide a hard preventive guardrail at request authorization time.
Incorrect. CloudFormation stack event detection only applies to resources created through CloudFormation, not those created via Console/CLI/SDK or Service Catalog products that may not be CloudFormation-based. Even when applicable, deleting after stack creation/update is still reactive and allows a noncompliant resource to exist temporarily, failing the proactive prevention requirement.
Core Concept: This question tests preventive governance controls for Amazon SageMaker using IAM policy evaluation and AWS Organizations Service Control Policies (SCPs). The requirement is to proactively block creation of noncompliant notebook instances (root access enabled) across multiple accounts and Regions, regardless of the provisioning path (Console, CLI/SDK, Service Catalog, CloudFormation). Why the Answer is Correct: SageMaker notebook instances expose a RootAccess parameter (often represented as Enabled/Disabled). IAM supports service-specific condition keys (e.g., sagemaker:RootAccess) that can be used in a Deny statement for CreateNotebookInstance and UpdateNotebookInstance when RootAccess is not Disabled. An explicit Deny enforced via an SCP applies to all principals in member accounts (including admins) and is evaluated for every API call, no matter how the resource is launched. This satisfies “must never be created” and “proactively block,” and it works uniformly across Regions because SCPs apply organization-wide and IAM evaluation happens at request time. Key AWS Features: 1) AWS Organizations SCPs: set a permissions guardrail that cannot be bypassed by account-level IAM permissions. 2) IAM condition keys: enforce configuration-level constraints (not just who can call an API, but with what parameters). 3) Coverage of multiple provisioning mechanisms: Console, CloudFormation, and Service Catalog ultimately call SageMaker APIs, so the same Deny applies. 4) Defense-in-depth: you can pair SCP with identity policies, but SCP is the critical cross-account control. Common Misconceptions: Event-driven remediation (EventBridge/Lambda) and CloudFormation hooks feel like “enforcement,” but they are reactive and allow a window of noncompliance—explicitly disallowed here. KMS encryption is unrelated to root access; it protects data at rest, not notebook OS privilege configuration. Exam Tips: When you see “must never be created” and “across all accounts,” think preventive controls: SCPs, permission boundaries, and explicit Deny with condition keys. Reactive controls (Config rules, EventBridge remediation, stack event cleanup) are for detection and correction, not hard prevention. Also remember that Service Catalog and CloudFormation are not separate control planes—they call underlying service APIs, so IAM/SCP guardrails are the most universal enforcement point.
An online education platform operates a single AWS account and stores 5 TB of labeled training data in one Amazon S3 bucket (s3://edu-ml-data) under department-specific prefixes (s3://edu-ml-data/math/, /physics/, /cs/, /biology/); 50 ML engineers run all model training in Amazon SageMaker using Studio notebooks and SageMaker training jobs, and each engineer must be able to read and write only the data under their own department's prefix while being blocked from accessing other departments' data from both interactive notebooks and training jobs; which solution will provide the engineers with the appropriate access controls?
S3 bucket versioning keeps multiple variants of objects to protect against accidental overwrites/deletes and to support rollback. It does not control who can access which objects. Even with versioning enabled, any principal with s3:GetObject on an object key can still read it, and any principal with s3:PutObject can still write. Versioning is a durability/recovery feature, not an access control mechanism for department isolation.
S3 Object Lock enforces write-once-read-many (WORM) retention and legal holds to prevent objects from being deleted or overwritten for a retention period. It is used for compliance and immutability, not for scoping read/write permissions by user or department. Object Lock cannot prevent an engineer from reading another department’s data if their IAM permissions allow it, so it does not meet the isolation requirement.
CORS rules in S3 define which web origins (domains) can make browser-based requests to S3 and which methods/headers are allowed. SageMaker Studio notebooks and training jobs access S3 using AWS SDKs and IAM credentials/roles, not browser cross-origin calls that CORS governs. Therefore, CORS does not enforce per-prefix authorization and will not block engineers from accessing other departments’ prefixes.
IAM policies scoped to S3 prefixes are the correct way to enforce least-privilege access. Create policies that allow ListBucket only for the allowed prefix (using s3:prefix conditions) and allow GetObject/PutObject only on arn:aws:s3:::edu-ml-data/<dept>/*. Attach these to the SageMaker execution roles used by each department (and map Studio user profiles accordingly) so both interactive notebooks and training jobs are restricted consistently.
Core Concept: This question tests AWS identity and access management for data security in ML workflows: using IAM policies (and SageMaker execution roles) to enforce least-privilege access to Amazon S3 prefixes. In SageMaker, both Studio notebooks and training jobs access S3 using an IAM role (the user profile role for Studio and the training job execution role), so controlling those roles controls data access. Why the Answer is Correct: Option D is correct because the requirement is fine-grained read/write isolation by department prefix (math/, physics/, cs/, biology/) for 50 engineers, and it must apply consistently to interactive notebooks and training jobs. The correct approach is to create IAM policies that allow s3:ListBucket with a prefix condition and allow s3:GetObject/s3:PutObject (and possibly s3:DeleteObject) only on the specific prefix ARN (e.g., arn:aws:s3:::edu-ml-data/math/*). Attach these policies to the IAM principals actually used: either IAM users (less common for SageMaker) or, best practice, the SageMaker execution roles per department (or per user) so that both Studio and training jobs inherit the same restrictions. Key AWS Features: Use resource-level permissions on S3 object ARNs plus bucket-level ListBucket permissions constrained by s3:prefix (and optionally s3:delimiter). Implement separate SageMaker execution roles per department, and map Studio user profiles to the appropriate role. This aligns with the AWS Well-Architected Security pillar: least privilege, separation of duties, and centralized policy management. Optionally, add explicit Deny statements to prevent access to other prefixes, and consider permission boundaries or IAM Identity Center for scalable user management. Common Misconceptions: Versioning and Object Lock relate to data retention and immutability, not authorization. CORS controls browser-based cross-origin requests, not IAM authorization for SageMaker. These can sound “security-related” but do not enforce per-prefix access for AWS service roles. Exam Tips: When you see “only this folder/prefix in S3” and “must work from SageMaker training jobs,” think IAM policies on S3 prefixes attached to SageMaker execution roles. Remember you typically need both (1) s3:ListBucket on the bucket with prefix conditions and (2) object actions on arn:aws:s3:::bucket/prefix/* for read/write.
A data science team has deployed an Amazon SageMaker model for an image-tagging feature to a serverless inference endpoint (2 vCPU equivalent, 4 GiB memory) in production, invoked via the InvokeEndpoint API; during off-peak periods when the endpoint sits idle for more than 10 minutes, p95 latency in production rises from the 120 ms baseline measured in staging to 480–520 ms, and the ML engineer suspects the extra latency is due to model startup (cold start) time rather than inference logic. What should the ML engineer do to confirm or refute this hypothesis?
Incorrect. SageMaker Model Monitor focuses on ongoing model governance signals such as data quality, drift, bias, and (optionally) model quality when ground truth is available. It does not directly measure endpoint cold-start or initialization latency. Scheduling Model Monitor jobs would not help confirm whether the extra 400 ms is due to model startup versus inference logic.
Incorrect. Even if CloudWatch metrics are enabled for Model Monitor outputs, Model Monitor is still the wrong tool for diagnosing serverless inference cold starts. The question is about request latency decomposition at the endpoint runtime, which is provided by SageMaker endpoint CloudWatch metrics, not by Model Monitor job metrics.
Correct. ModelSetupTime is the CloudWatch metric that most directly measures the initialization overhead associated with preparing a SageMaker model for inference. In a serverless inference scenario, if latency rises after the endpoint has been idle, elevated ModelSetupTime on those first requests is strong evidence of a cold start. This lets the engineer distinguish startup overhead from the actual inference code path. Because the metric is emitted by SageMaker to CloudWatch, it is the appropriate operational signal to inspect for this hypothesis.
Incorrect. ModelLoadingWaitTime is not the best metric for validating whether the latency spike is caused by cold-start setup overhead. A wait-time metric suggests time spent waiting for model loading or resources, but it does not as directly represent the full initialization and setup phase as ModelSetupTime does. The question asks how to confirm whether startup time is the cause, so the metric that explicitly measures setup is the better choice. On the exam, prefer the metric whose name and purpose most precisely match the suspected issue.
Core Concept: This question is about diagnosing latency spikes on an Amazon SageMaker serverless inference endpoint by using the built-in Amazon CloudWatch metrics that break endpoint latency into phases. When latency increases only after periods of idleness, the likely cause is cold-start overhead rather than the model’s inference logic. Why the Answer is Correct: The best way to confirm or refute a cold-start hypothesis is to inspect the CloudWatch metric that specifically measures model setup and initialization time. For SageMaker endpoints, ModelSetupTime in the AWS/SageMaker namespace captures the time spent preparing the model container and loading the model before inference begins. If the first invocation after idle periods shows elevated ModelSetupTime that aligns with the p95 latency spike, that supports the cold-start explanation; if not, the latency is likely coming from inference execution or another downstream factor. Key AWS Features: SageMaker publishes endpoint metrics to Amazon CloudWatch in the AWS/SageMaker namespace, where you can analyze latency-related metrics without modifying application code. Metrics such as ModelSetupTime help separate initialization overhead from steady-state inference behavior, which is especially useful for serverless inference where scale-down during idle periods can lead to cold starts. This makes CloudWatch the primary operational tool for validating startup-related latency issues in production. Common Misconceptions: SageMaker Model Monitor is designed for monitoring data quality, model quality, bias, and drift, not for diagnosing request-path latency or cold starts. Another common mistake is to focus on generic waiting or queueing metrics instead of the metric that directly measures setup time. For this scenario, the question is specifically asking how to validate startup overhead, so the setup metric is the most relevant. Exam Tips: When an endpoint is fast under steady load but slower after being idle, think of cold starts and look for setup or initialization metrics in CloudWatch. On AWS exams, prefer the service-native operational metric that directly measures the suspected bottleneck instead of governance or monitoring features aimed at model quality. Also remember that SageMaker endpoint performance metrics are available through CloudWatch in the AWS/SageMaker namespace.
Study period: 2 weeks
Used these questions exclusively to study, passed on first time. The app questions is very similar to the actual exam.
Study period: 2 weeks
Passed Oct 2025 with 905 score.
Study period: 1 month
문제 좋네요 굿굿!!
Associate
Practitioner
Specialty
Practitioner
Associate
Associate
Professional
Specialty
Professional
Download Cloud Pass and access all AWS Certified Machine Learning Engineer - Associate (MLA-C01) practice questions for free.
Want to practice all questions on the go?
Get the free app
Download Cloud Pass for free — includes practice tests, progress tracking & more.
