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.
外出先でもすべての問題を解きたいですか？
Cloud Passを無料でダウンロード — 模擬試験、学習進捗の追跡などを提供します。
合格体験記(3)
S
S**********Nov 24, 2025
学習期間: 2 weeks
Used these questions exclusively to study, passed on first time. The app questions is very similar to the actual exam.
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.
3
問題 3
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.
4
問題 4
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.
5
問題 5
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.
6
問題 6
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.
7
問題 7
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.
8
問題 8
(2つ選択)
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).
9
問題 9
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.
10
問題 10
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.
