Amazon AWS Certified Machine Learning Engineer - Associate MLA-C01 Practice Test 24
Question 230
As a regulated ML workload prepares for an automated regional rollout, the following condition is observed: An ML pipeline in one account is allowed to write model predictions to an unapproved external bucket because its role has overly broad s3:PutObject access. The team must demonstrate a repeatable monitoring or security control. Which TWO complementary choices provide the decisive diagnosis AND corrective response? Select TWO.
- Separate prompt input-distribution monitoring from delayed model-quality evaluation and join only observed labels to predictions.
- Inspect identity and destination bucket policies, resource ARNs, organization restrictions, and CloudTrail data-event evidence.
- Restrict writes to approved bucket prefixes and apply appropriate resource and organizational guardrails.
- Inspect online versus offline feature computation code, event-time cutoffs, freshness, and sampled entity values.
- Use approved SageMaker interface endpoints and relevant private DNS and policy settings for required API access.
Explanation
Correct Answers
B:Inspect identity and destination bucket policies, resource ARNs, organization restrictions, and CloudTrail data-event evidence. This directly tests cross-account s3 bucket exfiltration protection in the reported AWS ML workflow. Least privilege must constrain the destination resource; an unrestricted object-write policy can enable data exfiltration. It distinguishes the problem before choosing a change. The related targeted response is: Restrict writes to approved bucket prefixes and apply appropriate resource and organizational guardrails. This is one part of a select-two decision; the matching evidence and corrective action are both required. Reported signal: An ML pipeline in one account is allowed to write model predictions to an unapproved external bucket because its role has overly broad s3:PutObject access. Operational setting: As a regulated ML workload prepares for an automated regional rollout.
C:Restrict writes to approved bucket prefixes and apply appropriate resource and organizational guardrails. This is the appropriate controlled remedy for cross-account s3 bucket exfiltration protection. Least privilege must constrain the destination resource; an unrestricted object-write policy can enable data exfiltration. Verify the cause with: Inspect identity and destination bucket policies, resource ARNs, organization restrictions, and CloudTrail data-event evidence. Then confirm: A test write to an approved prefix succeeds, while writes to unapproved external destinations are denied. This is one part of a select-two decision; the matching evidence and corrective action are both required. Reported signal: An ML pipeline in one account is allowed to write model predictions to an unapproved external bucket because its role has overly broad s3:PutObject access. Operational setting: As a regulated ML workload prepares for an automated regional rollout.
Incorrect Answers
A:Separate prompt input-distribution monitoring from delayed model-quality evaluation and join only observed labels to predictions. This selection concerns target-label delay in production quality monitoring rather than the required diagnostic-and-remedy pair for cross-account s3 bucket exfiltration protection. Use evidence: Inspect identity and destination bucket policies, resource ARNs, organization restrictions, and CloudTrail data-event evidence. and the matching correction: Restrict writes to approved bucket prefixes and apply appropriate resource and organizational guardrails. Signal: An ML pipeline in one account is allowed to write model predictions to an unapproved external bucket because its role has overly broad s3:PutObject access. Operational setting: As a regulated ML workload prepares for an automated regional rollout.
D:Inspect online versus offline feature computation code, event-time cutoffs, freshness, and sampled entity values. This selection concerns training-serving feature skew incident rather than the required diagnostic-and-remedy pair for cross-account s3 bucket exfiltration protection. Use evidence: Inspect identity and destination bucket policies, resource ARNs, organization restrictions, and CloudTrail data-event evidence. and the matching correction: Restrict writes to approved bucket prefixes and apply appropriate resource and organizational guardrails. Signal: An ML pipeline in one account is allowed to write model predictions to an unapproved external bucket because its role has overly broad s3:PutObject access. Operational setting: As a regulated ML workload prepares for an automated regional rollout.
E:Use approved SageMaker interface endpoints and relevant private DNS and policy settings for required API access. This selection concerns private vpc endpoint policy for sagemaker apis rather than the required diagnostic-and-remedy pair for cross-account s3 bucket exfiltration protection. Use evidence: Inspect identity and destination bucket policies, resource ARNs, organization restrictions, and CloudTrail data-event evidence. and the matching correction: Restrict writes to approved bucket prefixes and apply appropriate resource and organizational guardrails. Signal: An ML pipeline in one account is allowed to write model predictions to an unapproved external bucket because its role has overly broad s3:PutObject access. Operational setting: As a regulated ML workload prepares for an automated regional rollout.
Question 231
During an approved rollout of an AWS ML inference workload, the following condition is observed: A new recommendation model has uncertain online behavior but the team plans to replace 100 percent of production traffic immediately. The team must meet its documented availability and rollback constraints. What postchange observation provides the strongest acceptance evidence?
- A limited slice serves the new version while metrics are monitored before any broad rollout.
- A deliberately poor candidate halts before production while a passing approved candidate can proceed.
- Low-frequency requests succeed within agreed latency while unused provisioned compute spend is reduced.
- Capacity responds to peak request load and p95 latency improves without continual scale oscillation.
Explanation
Correct Answer
A:A limited slice serves the new version while metrics are monitored before any broad rollout. This is the acceptance evidence for the described canary variant rollout for model changes scenario. Progressive exposure limits blast radius; immediate cutover obscures whether regressions occurred during ramp-up. The corrective implementation it validates is: Use a measured canary or linear traffic-shift deployment with alarms and immediate rollback conditions. Reported signal: A new recommendation model has uncertain online behavior but the team plans to replace 100 percent of production traffic immediately. Operational setting: During an approved rollout of an AWS ML inference workload.
Incorrect Answers
B:A deliberately poor candidate halts before production while a passing approved candidate can proceed. This could validate codepipeline approval gate on model metrics, but it does not establish that canary variant rollout for model changes is resolved for this workload. Confirm instead: A limited slice serves the new version while metrics are monitored before any broad rollout. Observed problem: A new recommendation model has uncertain online behavior but the team plans to replace 100 percent of production traffic immediately. Operational setting: During an approved rollout of an AWS ML inference workload.
C:Low-frequency requests succeed within agreed latency while unused provisioned compute spend is reduced. This could validate serverless inference for intermittent requests, but it does not establish that canary variant rollout for model changes is resolved for this workload. Confirm instead: A limited slice serves the new version while metrics are monitored before any broad rollout. Observed problem: A new recommendation model has uncertain online behavior but the team plans to replace 100 percent of production traffic immediately. Operational setting: During an approved rollout of an AWS ML inference workload.
D:Capacity responds to peak request load and p95 latency improves without continual scale oscillation. This could validate sagemaker endpoint auto scaling metric selection, but it does not establish that canary variant rollout for model changes is resolved for this workload. Confirm instead: A limited slice serves the new version while metrics are monitored before any broad rollout. Observed problem: A new recommendation model has uncertain online behavior but the team plans to replace 100 percent of production traffic immediately. Operational setting: During an approved rollout of an AWS ML inference workload.
Question 232
During a production MLOps reliability and security review, the following condition is observed: A loan default label becomes available months after inference, but a dashboard falsely reports current prediction accuracy using unlabeled requests. The owner needs an auditable resolution without broadening privileges. Which investigation provides the most decisive FIRST evidence for the underlying problem?
- Inspect routing hashes, experiment assignments, variant weights, and request identity consistency.
- Inspect training interruption tolerance, persistent checkpoints, allowed instance families, and deadline requirements.
- Inspect inference timestamps, eventual ground-truth arrival, join keys, and the provenance of displayed quality metrics.
- Inspect caller identity, pass-role resource ARN, service constraint, and denied event attributes.
Explanation
Correct Answer
C:Inspect inference timestamps, eventual ground-truth arrival, join keys, and the provenance of displayed quality metrics. This directly tests target-label delay in production quality monitoring in the reported AWS ML workflow. True supervised production quality generally needs observed outcomes; prediction outputs alone are not ground truth. It distinguishes the problem before choosing a change. The related targeted response is: Separate prompt input-distribution monitoring from delayed model-quality evaluation and join only observed labels to predictions. Reported signal: A loan default label becomes available months after inference, but a dashboard falsely reports current prediction accuracy using unlabeled requests. Operational setting: During a production MLOps reliability and security review.
Incorrect Answers
A:Inspect routing hashes, experiment assignments, variant weights, and request identity consistency. This is a possible diagnostic for champion challenger a/b assignment consistency, but it does not directly test the target-label delay in production quality monitoring failure reported here. Prioritize: Inspect inference timestamps, eventual ground-truth arrival, join keys, and the provenance of displayed quality metrics. The relevant case is: A loan default label becomes available months after inference, but a dashboard falsely reports current prediction accuracy using unlabeled requests. Operational setting: During a production MLOps reliability and security review.
B:Inspect training interruption tolerance, persistent checkpoints, allowed instance families, and deadline requirements. This is a possible diagnostic for spot training cost versus interruption recovery, but it does not directly test the target-label delay in production quality monitoring failure reported here. Prioritize: Inspect inference timestamps, eventual ground-truth arrival, join keys, and the provenance of displayed quality metrics. The relevant case is: A loan default label becomes available months after inference, but a dashboard falsely reports current prediction accuracy using unlabeled requests. Operational setting: During a production MLOps reliability and security review.
D:Inspect caller identity, pass-role resource ARN, service constraint, and denied event attributes. This is a possible diagnostic for iam passrole constraint for model deployment, but it does not directly test the target-label delay in production quality monitoring failure reported here. Prioritize: Inspect inference timestamps, eventual ground-truth arrival, join keys, and the provenance of displayed quality metrics. The relevant case is: A loan default label becomes available months after inference, but a dashboard falsely reports current prediction accuracy using unlabeled requests. Operational setting: During a production MLOps reliability and security review.
Question 233
At the model-governance gate before promotion of a new ML artifact, the following condition is observed: An expensive long-running training job on managed Spot Instances restarts from epoch zero after an interruption because it writes checkpoints only to ephemeral local files. The team needs a defensible technical decision rather than an untracked workaround. What targeted change should be implemented after verifying the stated cause?
- Configure a supported SageMaker checkpoint location and resume training state on managed Spot interruption recovery.
- Increase justified L2 regularization or reduce model capacity and revalidate with an untouched holdout.
- Compare a more interpretable model or add tested SageMaker Clarify explainability to the decision process.
- Train a gradient-boosted tree baseline such as SageMaker XGBoost and compare it against more complex candidates.
Explanation
Correct Answer
A:Configure a supported SageMaker checkpoint location and resume training state on managed Spot interruption recovery. This is the appropriate controlled remedy for managed spot training checkpoint recovery. Spot capacity can be interrupted; durable checkpoints prevent full retraining when restoration is correctly implemented. Verify the cause with: Inspect interruption events, checkpoint directory mapping, restoration logic, and persistent S3 checkpoint artifacts. Then confirm: A forced interruption resumes near the last saved epoch and restores optimizer and model state. Reported signal: An expensive long-running training job on managed Spot Instances restarts from epoch zero after an interruption because it writes checkpoints only to ephemeral local files. Operational setting: At the model-governance gate before promotion of a new ML artifact.
Incorrect Answers
B:Increase justified L2 regularization or reduce model capacity and revalidate with an untouched holdout. This addresses a different issue involving overfitting reduced with l2 regularization. It does not correct the stated managed spot training checkpoint recovery mechanism. The targeted response is: Configure a supported SageMaker checkpoint location and resume training state on managed Spot interruption recovery. Case evidence: An expensive long-running training job on managed Spot Instances restarts from epoch zero after an interruption because it writes checkpoints only to ephemeral local files. Operational setting: At the model-governance gate before promotion of a new ML artifact.
C:Compare a more interpretable model or add tested SageMaker Clarify explainability to the decision process. This addresses a different issue involving interpretability for high-stakes prediction. It does not correct the stated managed spot training checkpoint recovery mechanism. The targeted response is: Configure a supported SageMaker checkpoint location and resume training state on managed Spot interruption recovery. Case evidence: An expensive long-running training job on managed Spot Instances restarts from epoch zero after an interruption because it writes checkpoints only to ephemeral local files. Operational setting: At the model-governance gate before promotion of a new ML artifact.
D:Train a gradient-boosted tree baseline such as SageMaker XGBoost and compare it against more complex candidates. This addresses a different issue involving xgboost tabular classification baseline. It does not correct the stated managed spot training checkpoint recovery mechanism. The targeted response is: Configure a supported SageMaker checkpoint location and resume training state on managed Spot interruption recovery. Case evidence: An expensive long-running training job on managed Spot Instances restarts from epoch zero after an interruption because it writes checkpoints only to ephemeral local files. Operational setting: At the model-governance gate before promotion of a new ML artifact.
Question 234
During an operational load and release rehearsal for SageMaker-hosted inference, the following condition is observed: A custom image works when run locally but SageMaker cannot invoke it because the container lacks an expected health route and invocation handler. Change control requires measurable endpoint or pipeline acceptance evidence. What should the ML engineer inspect FIRST to distinguish this failure from unrelated issues?
- Inspect ECR image digest, tag history, pipeline manifests, and built-image package inventory.
- Inspect EventBridge rule patterns, source events, object prefixes, and pipeline execution histories.
- Inspect container startup logs, listening port, health endpoint, MIME types, and inference response contract.
- Inspect model sizes, framework compatibility, per-model request rates, load latency, and isolation requirements.
Explanation
Correct Answer
C:Inspect container startup logs, listening port, health endpoint, MIME types, and inference response contract. This directly tests bring-your-own-inference-container contract in the reported AWS ML workflow. A Docker image is not automatically a SageMaker-compatible inference server without the runtime HTTP contract. It distinguishes the problem before choosing a change. The related targeted response is: Implement the SageMaker inference container /ping and /invocations expectations or use a supported serving toolkit. Reported signal: A custom image works when run locally but SageMaker cannot invoke it because the container lacks an expected health route and invocation handler. Operational setting: During an operational load and release rehearsal for SageMaker-hosted inference.
Incorrect Answers
A:Inspect ECR image digest, tag history, pipeline manifests, and built-image package inventory. This is a possible diagnostic for ecr immutable image digest for inference, but it does not directly test the bring-your-own-inference-container contract failure reported here. Prioritize: Inspect container startup logs, listening port, health endpoint, MIME types, and inference response contract. The relevant case is: A custom image works when run locally but SageMaker cannot invoke it because the container lacks an expected health route and invocation handler. Operational setting: During an operational load and release rehearsal for SageMaker-hosted inference.
B:Inspect EventBridge rule patterns, source events, object prefixes, and pipeline execution histories. This is a possible diagnostic for eventbridge conditional retraining trigger, but it does not directly test the bring-your-own-inference-container contract failure reported here. Prioritize: Inspect container startup logs, listening port, health endpoint, MIME types, and inference response contract. The relevant case is: A custom image works when run locally but SageMaker cannot invoke it because the container lacks an expected health route and invocation handler. Operational setting: During an operational load and release rehearsal for SageMaker-hosted inference.
D:Inspect model sizes, framework compatibility, per-model request rates, load latency, and isolation requirements. This is a possible diagnostic for multi-model endpoint hosting tradeoff, but it does not directly test the bring-your-own-inference-container contract failure reported here. Prioritize: Inspect container startup logs, listening port, health endpoint, MIME types, and inference response contract. The relevant case is: A custom image works when run locally but SageMaker cannot invoke it because the container lacks an expected health route and invocation handler. Operational setting: During an operational load and release rehearsal for SageMaker-hosted inference.
Question 235
At a production AWS ML data lake supporting customer-facing predictions, the following condition is observed: A training preparation scan reads every month of event history even though the feature job requests one recent date, causing high bytes scanned and slow ingestion. Engineers must avoid changing unrelated source partitions. What should the ML engineer inspect FIRST to distinguish this failure from unrelated issues?
- Inspect workload read/write semantics, shared access requirements, filesystem operations, and object-store request patterns.
- Compare online Feature Store record values and offline event-time keyed feature history for the same entity and model snapshot.
- Compare the query predicates with S3 object prefixes, partition metadata, and query plans to confirm partitions are not being pruned.
- Inspect feature availability timestamps and whether each label time follows the last feature observation.
Explanation
Correct Answer
C:Compare the query predicates with S3 object prefixes, partition metadata, and query plans to confirm partitions are not being pruned. This directly tests partition pruning in s3 parquet training input in the reported AWS ML workflow. Partition-aware columnar scans reduce irrelevant I/O; naming a date column without partition metadata does not create pruning. It distinguishes the problem before choosing a change. The related targeted response is: Write partitioned columnar Parquet data by event date, register accurate partitions in the catalog, and filter on partition keys. Reported signal: A training preparation scan reads every month of event history even though the feature job requests one recent date, causing high bytes scanned and slow ingestion. Operational setting: At a production AWS ML data lake supporting customer-facing predictions.
Incorrect Answers
A:Inspect workload read/write semantics, shared access requirements, filesystem operations, and object-store request patterns. This is a possible diagnostic for s3 versus efs training storage choice, but it does not directly test the partition pruning in s3 parquet training input failure reported here. Prioritize: Compare the query predicates with S3 object prefixes, partition metadata, and query plans to confirm partitions are not being pruned. The relevant case is: A training preparation scan reads every month of event history even though the feature job requests one recent date, causing high bytes scanned and slow ingestion. Operational setting: At a production AWS ML data lake supporting customer-facing predictions.
B:Compare online Feature Store record values and offline event-time keyed feature history for the same entity and model snapshot. This is a possible diagnostic for sagemaker feature store online offline consistency, but it does not directly test the partition pruning in s3 parquet training input failure reported here. Prioritize: Compare the query predicates with S3 object prefixes, partition metadata, and query plans to confirm partitions are not being pruned. The relevant case is: A training preparation scan reads every month of event history even though the feature job requests one recent date, causing high bytes scanned and slow ingestion. Operational setting: At a production AWS ML data lake supporting customer-facing predictions.
D:Inspect feature availability timestamps and whether each label time follows the last feature observation. This is a possible diagnostic for chronological split for forecast evaluation, but it does not directly test the partition pruning in s3 parquet training input failure reported here. Prioritize: Compare the query predicates with S3 object prefixes, partition metadata, and query plans to confirm partitions are not being pruned. The relevant case is: A training preparation scan reads every month of event history even though the feature job requests one recent date, causing high bytes scanned and slow ingestion. Operational setting: At a production AWS ML data lake supporting customer-facing predictions.
Question 236
During a controlled replay of the data-preparation workflow in a separate ML staging account, the following condition is observed: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. The dataset contract must remain reproducible for a backfill. Which engineering response resolves the actual issue without masking the symptoms?
- Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3.
- Package the training tokenizer and normalization configuration with the model artifact and require serving compatibility checks.
- Use a CSV parser with explicit quoting and schema validation; quarantine malformed records before training.
- Apply a justified log1p transformation with documented treatment of invalid negatives and package it for serving.
Explanation
Correct Answer
A:Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3. This is the appropriate controlled remedy for s3 versus efs training storage choice. S3 object semantics differ from mounted shared filesystems; choose storage for workload access behavior. Verify the cause with: Inspect workload read/write semantics, shared access requirements, filesystem operations, and object-store request patterns. Then confirm: Concurrent workers observe consistent supported shared-file operations and training artifact delivery remains durable. Reported signal: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Operational setting: During a controlled replay of the data-preparation workflow in a separate ML staging account.
Incorrect Answers
B:Package the training tokenizer and normalization configuration with the model artifact and require serving compatibility checks. This addresses a different issue involving text tokenization mismatch in serving. It does not correct the stated s3 versus efs training storage choice mechanism. The targeted response is: Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3. Case evidence: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Operational setting: During a controlled replay of the data-preparation workflow in a separate ML staging account.
C:Use a CSV parser with explicit quoting and schema validation; quarantine malformed records before training. This addresses a different issue involving csv schema ambiguity during ingestion. It does not correct the stated s3 versus efs training storage choice mechanism. The targeted response is: Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3. Case evidence: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Operational setting: During a controlled replay of the data-preparation workflow in a separate ML staging account.
D:Apply a justified log1p transformation with documented treatment of invalid negatives and package it for serving. This addresses a different issue involving skewed numerical feature log transformation. It does not correct the stated s3 versus efs training storage choice mechanism. The targeted response is: Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3. Case evidence: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Operational setting: During a controlled replay of the data-preparation workflow in a separate ML staging account.
Question 237
During a controlled replay of the data-preparation workflow in a separate ML staging account, the following condition is observed: A Spark transformation joins billions of records on a region key, and one region contains most observations, stalling one shuffle task. The dataset contract must remain reproducible for a backfill. Which verification result BEST demonstrates that the issue is resolved?
- A controlled out-of-order replay yields the expected window totals and bounded late-event treatment.
- Every held-out forecast uses only data that existed at prediction time and its backtest follows real ordering.
- Long-tail task duration and shuffle spill decline without changing the joined record counts.
- Annotation workers can label required content without viewing direct identifiers and authorized audits can trace approved mappings.
Explanation
Correct Answer
C:Long-tail task duration and shuffle spill decline without changing the joined record counts. This is the acceptance evidence for the described glue spark join skew on dominant identifier scenario. A low-cardinality or skewed key can concentrate a distributed join into one expensive partition. The corrective implementation it validates is: Repartition or salt the skewed join appropriately, or use a justified broadcast join when the small side fits memory. Reported signal: A Spark transformation joins billions of records on a region key, and one region contains most observations, stalling one shuffle task. Operational setting: During a controlled replay of the data-preparation workflow in a separate ML staging account.
Incorrect Answers
A:A controlled out-of-order replay yields the expected window totals and bounded late-event treatment. This could validate streaming feature rolling window correctness, but it does not establish that glue spark join skew on dominant identifier is resolved for this workload. Confirm instead: Long-tail task duration and shuffle spill decline without changing the joined record counts. Observed problem: A Spark transformation joins billions of records on a region key, and one region contains most observations, stalling one shuffle task. Operational setting: During a controlled replay of the data-preparation workflow in a separate ML staging account.
B:Every held-out forecast uses only data that existed at prediction time and its backtest follows real ordering. This could validate chronological split for forecast evaluation, but it does not establish that glue spark join skew on dominant identifier is resolved for this workload. Confirm instead: Long-tail task duration and shuffle spill decline without changing the joined record counts. Observed problem: A Spark transformation joins billions of records on a region key, and one region contains most observations, stalling one shuffle task. Operational setting: During a controlled replay of the data-preparation workflow in a separate ML staging account.
D:Annotation workers can label required content without viewing direct identifiers and authorized audits can trace approved mappings. This could validate pii masking before model labeling, but it does not establish that glue spark join skew on dominant identifier is resolved for this workload. Confirm instead: Long-tail task duration and shuffle spill decline without changing the joined record counts. Observed problem: A Spark transformation joins billions of records on a region key, and one region contains most observations, stalling one shuffle task. Operational setting: During a controlled replay of the data-preparation workflow in a separate ML staging account.
Question 238
As a regional data-pipeline rollout is validated against approved AWS storage and streams, the following condition is observed: An S3 event-triggered feature ingestion function processes the same uploaded object twice, creating duplicate labeled samples. The data team must preserve event-time meaning and lineage. What should the ML engineer inspect FIRST to distinguish this failure from unrelated issues?
- Inspect workload read/write semantics, shared access requirements, filesystem operations, and object-store request patterns.
- Inspect feature availability timestamps and whether each label time follows the last feature observation.
- Inspect per-class confusion, worker agreement, label instructions, and disagreements on an adjudicated reference set.
- Inspect event identifiers, object versions or ETags, processing ledger, and downstream record keys for duplicate deliveries.
Explanation
Correct Answer
D:Inspect event identifiers, object versions or ETags, processing ledger, and downstream record keys for duplicate deliveries. This directly tests s3 object event at-least-once processing in the reported AWS ML workflow. Event notifications can be delivered more than once; consuming an event is not proof of exactly-once effects. It distinguishes the problem before choosing a change. The related targeted response is: Make the ingestion handler idempotent using a stable object/version key and conditional ledger writes. Reported signal: An S3 event-triggered feature ingestion function processes the same uploaded object twice, creating duplicate labeled samples. Operational setting: As a regional data-pipeline rollout is validated against approved AWS storage and streams.
Incorrect Answers
A:Inspect workload read/write semantics, shared access requirements, filesystem operations, and object-store request patterns. This is a possible diagnostic for s3 versus efs training storage choice, but it does not directly test the s3 object event at-least-once processing failure reported here. Prioritize: Inspect event identifiers, object versions or ETags, processing ledger, and downstream record keys for duplicate deliveries. The relevant case is: An S3 event-triggered feature ingestion function processes the same uploaded object twice, creating duplicate labeled samples. Operational setting: As a regional data-pipeline rollout is validated against approved AWS storage and streams.
B:Inspect feature availability timestamps and whether each label time follows the last feature observation. This is a possible diagnostic for chronological split for forecast evaluation, but it does not directly test the s3 object event at-least-once processing failure reported here. Prioritize: Inspect event identifiers, object versions or ETags, processing ledger, and downstream record keys for duplicate deliveries. The relevant case is: An S3 event-triggered feature ingestion function processes the same uploaded object twice, creating duplicate labeled samples. Operational setting: As a regional data-pipeline rollout is validated against approved AWS storage and streams.
C:Inspect per-class confusion, worker agreement, label instructions, and disagreements on an adjudicated reference set. This is a possible diagnostic for ground truth labeling agreement review, but it does not directly test the s3 object event at-least-once processing failure reported here. Prioritize: Inspect event identifiers, object versions or ETags, processing ledger, and downstream record keys for duplicate deliveries. The relevant case is: An S3 event-triggered feature ingestion function processes the same uploaded object twice, creating duplicate labeled samples. Operational setting: As a regional data-pipeline rollout is validated against approved AWS storage and streams.
Question 239
During an operational load and release rehearsal for SageMaker-hosted inference, the following condition is observed: An inference service needs a separate preprocessing transform before a predictor, but the team inserts inconsistent transformation code into many client applications. Change control requires measurable endpoint or pipeline acceptance evidence. What targeted change should be implemented after verifying the stated cause?
- Use a compatible SageMaker inference pipeline with ordered containers or a single packaged equivalent for shared preprocessing.
- Reference an approved immutable image digest or controlled version tag and retain a reproducible build record.
- Compile the supported model for the specific edge target using SageMaker Neo or choose a compatible conversion route.
- Add schema, integration and sample endpoint inference tests to the ML build and deployment pipeline.
Explanation
Correct Answer
A:Use a compatible SageMaker inference pipeline with ordered containers or a single packaged equivalent for shared preprocessing. This is the appropriate controlled remedy for multi-container inference pipeline responsibilities. A managed inference pipeline chains preprocessing and prediction steps consistently, reducing client-side skew. Verify the cause with: Inspect preprocessing version drift, input/output contracts, and the selected hosting container topology. Then confirm: The endpoint applies the same preprocessor to every client request and produces the expected model input schema. Reported signal: An inference service needs a separate preprocessing transform before a predictor, but the team inserts inconsistent transformation code into many client applications. Operational setting: During an operational load and release rehearsal for SageMaker-hosted inference.
Incorrect Answers
B:Reference an approved immutable image digest or controlled version tag and retain a reproducible build record. This addresses a different issue involving ecr immutable image digest for inference. It does not correct the stated multi-container inference pipeline responsibilities mechanism. The targeted response is: Use a compatible SageMaker inference pipeline with ordered containers or a single packaged equivalent for shared preprocessing. Case evidence: An inference service needs a separate preprocessing transform before a predictor, but the team inserts inconsistent transformation code into many client applications. Operational setting: During an operational load and release rehearsal for SageMaker-hosted inference.
C:Compile the supported model for the specific edge target using SageMaker Neo or choose a compatible conversion route. This addresses a different issue involving sagemaker neo edge compiler compatibility. It does not correct the stated multi-container inference pipeline responsibilities mechanism. The targeted response is: Use a compatible SageMaker inference pipeline with ordered containers or a single packaged equivalent for shared preprocessing. Case evidence: An inference service needs a separate preprocessing transform before a predictor, but the team inserts inconsistent transformation code into many client applications. Operational setting: During an operational load and release rehearsal for SageMaker-hosted inference.
D:Add schema, integration and sample endpoint inference tests to the ML build and deployment pipeline. This addresses a different issue involving continuous integration unit and endpoint contract tests. It does not correct the stated multi-container inference pipeline responsibilities mechanism. The targeted response is: Use a compatible SageMaker inference pipeline with ordered containers or a single packaged equivalent for shared preprocessing. Case evidence: An inference service needs a separate preprocessing transform before a predictor, but the team inserts inconsistent transformation code into many client applications. Operational setting: During an operational load and release rehearsal for SageMaker-hosted inference.
Question 240
At a production AWS ML data lake supporting customer-facing predictions, the following condition is observed: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Engineers must avoid changing unrelated source partitions. What targeted change should be implemented after verifying the stated cause?
- Split by stable patient identity before training and reserve a disjoint held-out group for evaluation.
- Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3.
- Measure label distribution differences with an appropriate pretraining bias metric and improve data representation before training.
- Preserve the intended bookmark state across deployments and run an explicit controlled backfill only when required.
Explanation
Correct Answer
B:Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3. This is the appropriate controlled remedy for s3 versus efs training storage choice. S3 object semantics differ from mounted shared filesystems; choose storage for workload access behavior. Verify the cause with: Inspect workload read/write semantics, shared access requirements, filesystem operations, and object-store request patterns. Then confirm: Concurrent workers observe consistent supported shared-file operations and training artifact delivery remains durable. Reported signal: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Operational setting: At a production AWS ML data lake supporting customer-facing predictions.
Incorrect Answers
A:Split by stable patient identity before training and reserve a disjoint held-out group for evaluation. This addresses a different issue involving group-leakage train and validation split. It does not correct the stated s3 versus efs training storage choice mechanism. The targeted response is: Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3. Case evidence: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Operational setting: At a production AWS ML data lake supporting customer-facing predictions.
C:Measure label distribution differences with an appropriate pretraining bias metric and improve data representation before training. This addresses a different issue involving clarify label imbalance measurement. It does not correct the stated s3 versus efs training storage choice mechanism. The targeted response is: Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3. Case evidence: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Operational setting: At a production AWS ML data lake supporting customer-facing predictions.
D:Preserve the intended bookmark state across deployments and run an explicit controlled backfill only when required. This addresses a different issue involving glue job bookmark state error. It does not correct the stated s3 versus efs training storage choice mechanism. The targeted response is: Place shared POSIX-style working files on suitable EFS or FSx storage and keep immutable large artifacts in S3. Case evidence: Several distributed workers repeatedly read small shared checkpoints with POSIX file semantics, but the pipeline treats object-storage paths as a mutable shared filesystem. Operational setting: At a production AWS ML data lake supporting customer-facing predictions.
