Skip to content

Skill 3.3.10: Configure FM deployment automation with fine-tuned model versioning

Question 1 - Bedrock Prompt Management for Multi-Environment Release

A financial services company has implemented a customer-support assistant using Amazon Bedrock. The ML team manages prompt templates across development, staging, and production environments. After A/B testing in staging, the team needs to deploy an approved prompt variant to production. Compliance auditors require that any prompt deployed to production must have an immutable identifier that can be traced in audit logs, and the deployment must not require modifying application code that calls the Bedrock API.

Which approach should the team use to meet these requirements with the LOWEST operational overhead? (Select ONE)

  • A) Store approved prompts in a versioned AWS Secrets Manager secret and update the application's retrieval logic to fetch the secret value at runtime.
  • B) Use Amazon Bedrock Prompt Management to create a versioned prompt resource in production, configure a Bedrock Agent alias to use that prompt version, and have the application route through the Agent.
  • C) Copy the approved prompt text from staging into an Amazon DynamoDB table with a version attribute, and have the application query DynamoDB before each API call.
  • D) Embed the approved prompt directly in the application code repository and use AWS CodeDeploy to perform a rolling deployment to the application fleet.
  • E) Use Amazon Bedrock Prompt Management with the versioned prompt resource, and update the application to reference the PromptArn with the specific version number.
Click to reveal Answer & Explanation

Correct Answer: E

Correct Options Analysis

  • E is Correct: Amazon Bedrock Prompt Management provides versioned prompt resources in the "Create prompt" / "Prompts" console or via the CreatePrompt API. Each version has an immutable PromptArn that includes a version identifier (e.g., arn:aws:bedrock:region:account-id:prompt/name:version). The application references this PromptArn directly in InvokeModel or Converse calls (using "prompt management" with promptIdentifier in the promptOverrideConfiguration), ensuring the exact prompt variant used is traceable in CloudTrail logs without changing application code at runtime.

Distractor Analysis

  • A is Incorrect: Secrets Manager is designed for secrets like API keys and passwords, not prompt templates. While versioning exists, it introduces unnecessary retrieval overhead and conflicts with the requirement for native AWS AI workflow.
  • B is Incorrect: While Bedrock Agents support prompt overrides and aliases, routing through an Agent introduces additional complexity (agent orchestration, action groups, knowledge bases) when the application only needs prompt versioning. Bedrock Prompt Management alone satisfies the requirement without agent infrastructure.
  • C is Incorrect: DynamoDB adds operational overhead (table management, read/write capacity, caching logic) and lacks native audit lineage for prompt versioning.
  • D is Incorrect: Embedding prompts in application code violates the "immutable identifier for audit" and "no application code modification" requirements, and CodeDeploy is for application deployment, not prompt version management.

Key Takeaway: Amazon Bedrock Prompt Management turns prompt text into a versioned AWS resource—deployment becomes a lookup of a version-specific PromptArn, not a code change.

Question 2 - Fine-Tuned Foundation Model Version Control with SageMaker Model Registry

An e-commerce company has fine-tuned a foundation model using Amazon SageMaker for product categorization. The team needs a CI/CD pipeline that automates the following workflow: fine-tune new model versions when new training data arrives, evaluate each candidate model, allow ML engineers to approve only models that pass quality gates, and deploy approved models to a SageMaker real-time endpoint. Auditors require that every deployed model version must have traceable lineage to the exact training job, hyperparameters, and dataset.

Which combination of services will satisfy these requirements with the LEAST operational complexity? (Select TWO)

  • A) Amazon SageMaker Pipelines orchestrates fine-tuning using TrainingStep, evaluates the model using ProcessingStep with a custom evaluation script, and registers the model using ModelStep with CreateModelInput that references the training job's ModelArtifacts.
  • B) Store model metadata in an Amazon OpenSearch Service index, and use Lambda to query feature importance scores before manual approval in a custom internal dashboard.
  • C) Use Amazon SageMaker Model Registry to catalog model versions in a model group, with approval status managed via UpdateModelPackage and model lineage captured by SageMaker ML Lineage Tracking.
  • D) Use AWS Step Functions with a manual approval state, and store model binaries directly in Amazon EFS for easy access during deployment.
  • E) Use Amazon SageMaker Model Building Pipelines with a RegisterModel step that references the training job's ModelArtifacts, then use ModelApproval state to send an Amazon SNS notification for human approval before deployment.
Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: SageMaker Pipelines natively orchestrates the full MLOps workflow. The TrainingStep runs the fine-tuning job, ProcessingStep evaluates the model against quality thresholds, and ModelStep with CreateModelInput (specifically the RegisterModel action) registers the fine-tuned model artifact into SageMaker Model Registry with automated lineage from the training job's modelArtifacts S3 location.
  • C is Correct: SageMaker Model Registry provides version control for fine-tuned FMs via model groups and model package versions. The approval status (PendingApproval, Approved, Rejected) is managed through UpdateModelPackage API. SageMaker ML Lineage Tracking automatically captures lineage between training jobs, model packages, and data sources, satisfying audit requirements.

Distractor Analysis

  • B is Incorrect: OpenSearch Service is for search and log analytics, not model registry or lineage tracking. Using Lambda for manual approval introduces unnecessary custom infrastructure.
  • D is Incorrect: Step Functions handles the orchestration, but storing model binaries in Amazon EFS introduces manual artifact management and violates model versioning and lineage requirements. SageMaker Model Registry is the correct service.
  • E is Incorrect: While technically similar, this option is redundant with option A and C. The ModelApproval state in Step Functions is not a native SageMaker Pipelines feature—SageMaker Pipelines uses ModelStep with register_new_version and model_approval_status parameters. The correct approach uses SageMaker Pipeline's built-in registration and approval, not Step Functions.

Key Takeaway: SageMaker Pipelines + SageMaker Model Registry together provide end-to-end automation for fine-tuning FM deployment with version control and lineage tracking.

Question 3 - Rollback for Fine-Tuned Model Deployment

A healthcare startup has deployed a fine-tuned Llama 3 model on a SageMaker real-time endpoint using blue/green deployment with traffic shifting. The new model version (v2) has been live for 24 hours with 100% traffic. The ML team discovers that v2 is generating 4.5x the expected cost due to longer response times, but the accuracy metrics remain unchanged. The team wants to revert to the previous fine-tuned model version (v1) while maintaining endpoint availability.

Which action should the team take to revert to v1 with the LEAST downtime? (Select ONE)

  • A) Delete the current endpoint and create a new endpoint configuration with the v1 model, then update the application to point to the new endpoint URL.
  • B) Update the endpoint configuration to reference the v1 model package ARN from SageMaker Model Registry, then use UpdateEndpoint to apply the configuration, triggering an automatic blue/green deployment that shifts traffic to v1.
  • C) Use the SageMaker console to manually terminate the v2 instances and launch v1 instances on the same endpoint.
  • D) Unregister v2 from the model registry and re-register v1, then call InvokeEndpoint with the TargetModel parameter as v1.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: SageMaker endpoints support blue/green deployments when updating with a new endpoint configuration that references a different model version. By creating a new EndpointConfig that points to the v1 model package (from Model Registry), and calling UpdateEndpoint, SageMaker automatically performs a zero-downtime traffic shift to the v1 model (blue/green if the endpoint is configured for it, or a rolling update). The endpoint remains available throughout the transition.

Distractor Analysis

  • A is Incorrect: Deleting the endpoint and creating a new one causes downtime and requires application code changes, violating "LEAST downtime" requirement.
  • C is Incorrect: Manual termination of instances is not an automated best practice and cannot guarantee zero downtime.
  • D is Incorrect: Unregistering v2 from Model Registry doesn't change the deployed model on the endpoint. TargetModel parameter is specific to multi-model endpoints (MME), not standard single-model endpoints.

Key Takeaway: Updating an endpoint configuration to reference a previous model version from Model Registry triggers a managed blue/green rollback with zero downtime.

Question 4 - Automated CI/CD for Fine-Tuned Bedrock Custom Model

A retail company has fine-tuned a foundation model using Amazon Bedrock Custom Model Import (using CreateModelImportJob to bring a customized Llama model from SageMaker fine-tuning into Bedrock). The team wants to automate the deployment of new fine-tuned model versions through a AWS CodePipeline CI/CD workflow. The pipeline must do the following: Detect when a new model is registered in SageMaker Model Registry, validate the model against a test suite, and deploy the validated model to production using Bedrock's custom model API. The team wants to minimize custom infrastructure.

Which combination of pipeline components will satisfy these requirements? (Select TWO)

  • A) Use Amazon EventBridge to capture SageMaker Model Registry ModelPackageApproved events and trigger the CodePipeline execution via StartPipelineExecution.
  • B) Use AWS CodeBuild steps to run model validation tests and use AWS CodeDeploy to deploy the model directly to Bedrock.
  • C) Use AWS CodePipeline with a source stage that watches a S3 bucket for uploaded model artifacts, and use AWS CodeBuild to perform model validation and call Bedrock's CreateModelImportJob API for deployment.
  • D) Use AWS Lambda inside AWS CodeBuild to create a custom test harness for model validation and use Bedrock GetModelInvocationLogs for deployment verification.
  • E) Use Amazon S3 Event Notifications to put a message in an SQS queue that triggers AWS CodePipeline for the model import job.
Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: SageMaker Model Registry emits events (e.g., ModelPackageApproved) to Amazon EventBridge. This event-driven architecture automatically triggers the CodePipeline when a model is approved, satisfying "Detect when a new model is registered" with zero custom polling infrastructure.
  • C is Correct: CodePipeline can use S3 as a source stage (the S3Source action looks for new artifacts in a specific bucket). A CodeBuild stage can then perform model validation using the validation test suite, and if the validation passes, another CodeBuild step can call Bedrock's CreateModelImportJob API with the model artifacts from S3, completing the deployment to Bedrock.

Distractor Analysis

  • B is Incorrect: AWS CodeDeploy does not support deploying models to Amazon Bedrock—it deploys to EC2, Lambda, ECS, or on-premises instances. Deploying to Bedrock requires calling the Bedrock API (CreateModelImportJob), which is custom logic.
  • D is Incorrect: Bedrock GetModelInvocationLogs retrieves invocation logs, not deployment status for custom models. Additionally, Lambda inside CodeBuild is an anti-pattern—CodeBuild itself runs containerized build steps.
  • E is Incorrect: S3 Event Notifications and SQS cannot directly trigger CodePipeline. While S3 can be a source stage in CodePipeline, the notification and queue approach adds unnecessary complexity.

Key Takeaway: EventBridge + SageMaker Model Registry events are the native, low-complexity way to trigger CodePipeline when a new fine-tuned model is approved.

Question 5 - Fine-Tuned Model A/B Testing with Deployment Guardrails

A software company runs a fine-tuned Mistral model on SageMaker real-time endpoint. The team has a new fine-tuned version (v3) that they want to test against the current version (v2) in production. They want to route 20% of traffic to v3, monitor latency and error rates, and automatically roll back if the error rate exceeds 5% during a 30-minute window. Both models must remain accessible through the same endpoint URL.

Which configuration is required to achieve this with MINIMAL operational overhead? (Select ONE)

  • A) Create two separate SageMaker endpoints (one for v2 and one for v3), deploy an Application Load Balancer in front of both endpoints, and configure weighted routing with CloudWatch alarms for rollback.
  • B) Use SageMaker Deployment Guardrails with a canary traffic shift targeting 20% traffic to v3, configure a CloudWatch Alarm on Invocation5XXErrors, set the BakingPeriod to 30 minutes, and specify AutoRollbackConfiguration with the alarm in the DeploymentConfig.
  • C) Use Amazon API Gateway with a canary release, routing 20% of requests to a Lambda function that calls the v3 endpoint, with conditional logic to revert if errors increase.
  • D) Manually monitor the error rate for 30 minutes, and if errors exceed 5%, manually update the endpoint configuration to reduce traffic to v3.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: SageMaker Deployment Guardrails natively support canary traffic shifting for real-time endpoints. The DeploymentConfig with TrafficRoutingConfig (using Canary strategy with WaitIntervalInSeconds or CanarySize, and BakingPeriod) routes a specified percentage of traffic to the new (green) fleet running v3. The AutoRollbackConfiguration references a CloudWatch Alarm (e.g., Invocation5XXErrors with threshold 5%) that, when triggered during the baking period, automatically rolls back 100% of traffic to v2. The endpoint URL remains unchanged.

Distractor Analysis

  • A is Incorrect: Using an Application Load Balancer (ALB) with multiple endpoints introduces unnecessary complexity—ALBs are for HTTP traffic routing, not SageMaker endpoint traffic. SageMaker endpoints don't support ALB integration natively without custom Lambda proxies.
  • C is Incorrect: API Gateway + Lambda + custom rollback logic is a significant operational overhead compared to native SageMaker Deployment Guardrails. This violates "minimal operational overhead."
  • D is Incorrect: Manual monitoring and rollback is not automated and does not meet the requirement for automatic rollback.

Key Takeaway: SageMaker Deployment Guardrails with canary traffic shifting + CloudWatch alarms provides native A/B testing with automated rollback for fine-tuned models.

Question 6 - Model Validation Gate in CI/CD Pipeline

An automotive company uses AWS CodePipeline to deploy fine-tuned vision models to production. The pipeline currently has three stages: Source (CodeCommit), Build (CodeBuild compiles code and packages the model), and Deploy (CodeDeploy updates the SageMaker endpoint). The ML team wants to add a validation stage that runs model quality checks (accuracy, F1-score, bias metrics) before deployment. The validation must be fully automated, and the pipeline must stop if the model fails to meet thresholds.

Which configuration should the team implement? (Select ONE)

  • A) Add a manual approval action between Build and Deploy stages in CodePipeline, requiring an ML engineer to review metrics in CloudWatch before approving deployment.
  • B) Add a CodeBuild action in the pipeline after the Build stage that runs a Python script to load the model from S3, execute the validation test suite, and fail the build if metrics fall below thresholds. Use a condition in CodePipeline to skip deployment if the validation build fails.
  • C) Add a SageMaker Processing job after the Build stage that runs validation using the built-in SageMaker Clarify metrics, then use the ModelStep with CheckConditions in the subsequent stage to gate deployment.
  • D) Use Amazon EventBridge to monitor CloudWatch metrics after deployment, and if the model quality drops, trigger a rollback using SageMaker Deployment Guardrails.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: CodeBuild is the correct tool in CodePipeline for running automated validation tests in the CI/CD pipeline. The CodeBuild buildspec runs a Python script that loads the model artifacts from S3, executes the validation tests (evaluation metrics, bias checks, etc.), and exits with a non-zero exit code if the model fails thresholds. CodePipeline automatically stops the pipeline execution and marks the stage as failed, preventing deployment. This is fully automated with zero human intervention.

Distractor Analysis

  • A is Incorrect: Manual approval actions require human intervention and are not "fully automated." They also don't actually run model validation—an ML engineer reviews metrics manually.
  • C is Incorrect: While SageMaker Processing jobs can run validation, integrating them as part of a CodePipeline stage (rather than within SageMaker Pipelines) requires additional custom orchestration and is not a direct feature of CodePipeline.
  • D is Incorrect: Post-deployment monitoring and rollback via EventBridge is a reactive approach, not a pre-deployment validation gate. The requirement specifies "before deployment."

Key Takeaway: CodeBuild is the standard validation gate in CodePipeline for ML models—it runs automated test suites and fails the pipeline when quality thresholds are not met.

Question 7 - Fine-Tuned Model Provenance and Audit Trail with MLflow

A government agency uses Amazon SageMaker AI with MLflow to fine-tune large language models for document classification. The agency's compliance team requires a complete audit trail showing: which fine-tuning job produced a specific deployed model, what hyperparameters were used, what evaluation metrics were collected, and which version of the dataset was used. The ML team wants to use MLflow's native features to satisfy these requirements without building custom tools.

Which MLflow features should the team use to meet these compliance requirements with MINIMAL custom development? (Select TWO)

  • A) Use MLflow Tracking to automatically log parameters (hyperparameters), metrics (evaluation scores), and artifacts (model binaries) during fine-tuning runs, with unique run IDs.
  • B) Use MLflow Model Registry to promote fine-tuned models through stages (Staging → Production → Archived), and use the mlflow.models.get_model_info() API to retrieve the model's lineage metadata.
  • C) Use MLflow's built-in data versioning feature with AWS Glue Data Catalog to automatically capture dataset version snapshots.
  • D) Implement a custom metadata store in Amazon DynamoDB to manually record hyperparameters, metrics, and dataset paths after each fine-tuning job completes.
  • E) Use AWS CloudTrail alone to track all MLflow API calls and reconstruct the audit trail from raw API logs.
Click to reveal Answer & Explanation

Correct Answers: A and B

Correct Options Analysis

  • A is Correct: MLflow Tracking is the core experiment tracking component that automatically logs all run metadata—including hyperparameters (via mlflow.log_param), metrics (via mlflow.log_metric), model artifacts (via mlflow.log_model), and dataset information (via mlflow.log_input). Each run gets a unique run ID, enabling direct traceability from training configuration to model output.
  • B is Correct: MLflow Model Registry manages fine-tuned model versions through lifecycle stages. Each registered model version maintains a link back to the originating MLflow run (the run_id is automatically recorded when registering), providing end-to-end lineage. The model's lineage metadata (run ID, hyperparameters, metrics) can be retrieved via API calls with the specific model version identifier.

Distractor Analysis

  • C is Incorrect: MLflow does not natively integrate with AWS Glue Data Catalog for automatic dataset versioning. While MLflow has dataset tracking capabilities, they require dataset files to be logged as inputs during the run itself.
  • D is Incorrect: Implementing a custom DynamoDB metadata store is a manual process that duplicates what MLflow Tracking already provides natively. This violates the "minimal custom development" requirement.
  • E is Incorrect: CloudTrail logs API calls but does not capture the rich metadata (hyperparameters, metrics, model artifacts) that MLflow Tracking provides. Reconstructing an audit trail from raw API logs would be extremely difficult and does not satisfy compliance requirements.

Key Takeaway: MLflow Tracking (runs) + MLflow Model Registry (versions) provide native, end-to-end lineage tracking for fine-tuned FMs without custom infrastructure.

Question 8 - Automating Bedrock Custom Model Import Deployment

A technology company fine-tunes models using SageMaker and then imports them into Amazon Bedrock using CreateModelImportJob. The company needs to automate the following workflow: After a fine-tuning job completes in SageMaker and the model is approved in SageMaker Model Registry, automatically trigger the Bedrock model import job, verify the import succeeds, and send a Slack notification to the ML team. The team wants to use managed services only with minimal Lambda code.

Which combination of AWS services will satisfy these requirements? (Select ONE)

  • A) Use SageMaker Model Registry events → Amazon EventBridge → AWS Step Functions (with Bedrock CreateModelImportJob integration and SNS notification state) → Slack via AWS Chatbot.
  • B) Use SageMaker Model Registry events → Amazon EventBridge → AWS Lambda that calls Bedrock CreateModelImportJob, polls the job status, and sends a Slack webhook notification. If the job fails, the Lambda writes an error message to an S3 bucket.
  • C) Use a CloudWatch Event rule that schedules an AWS Lambda function every 5 minutes to check for new model approvals in SageMaker Model Registry, then trigger the Bedrock model import job.
  • D) Use an AWS CodePipeline with a source stage monitoring SageMaker Model Registry via a custom Lambda function, a build stage using CodeBuild for the Bedrock import, and a deploy stage using CodeDeploy for notification.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Options Analysis

  • A is Correct: AWS Step Functions natively integrates with Amazon Bedrock for the CreateModelImportJob API call, supports Wait states to poll job completion, and can publish to SNS via the Publish task. EventBridge triggers the Step Functions state machine when SageMaker Model Registry emits the ModelPackageApproved event. AWS Chatbot connects SNS to Slack for notifications, all with zero Lambda code and fully managed services.

Distractor Analysis

  • B is Incorrect: While functionally valid, this approach requires custom Lambda code (which the question explicitly asks to minimize). Step Functions provides native integration that eliminates Lambda orchestration code.
  • C is Incorrect: Polling every 5 minutes adds unnecessary complexity and latency. Event-driven triggers from Model Registry events are more efficient and remove the need for a polling Lambda.
  • D is Incorrect: CodePipeline, CodeBuild, and CodeDeploy are for building and deploying software, not for orchestrating Bedrock model imports. This adds significant operational complexity compared to Step Functions.

Key Takeaway: Step Functions is the preferred service for orchestrating Bedrock model import workflows that require polling job status and handling notifications.

Question 9 - Fine-Tuned Model Container Image Versioning

A machine learning team deploys fine-tuned models to SageMaker endpoints using custom Docker containers. The team historically used the latest tag for container images and updated the image in-place in Amazon ECR when fine-tuning new model versions. However, auditors flagged this practice because it's impossible to determine which container image version served traffic during a past incident. The team needs to implement proper version control for both the container image and the fine-tuned model with minimal pipeline changes.

Which versioning strategy should the team implement? (Select ONE)

  • A) Tag each container image with a unique immutable tag derived from the model version (e.g., model-<version>-<git-sha>), and register each fine-tuned model version in SageMaker Model Registry referencing that specific image tag and model artifact location.
  • B) Continue using latest for container images but add a manifest file in the ECR repository that records the model version and training run ID.
  • C) Create a new ECR repository for each model version, and use the ECR repository name to identify the version.
  • D) Use Amazon ECR's immutable image tags feature with the latest tag, and rely on ECR to automatically retain version history.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Options Analysis

  • A is Correct: Immutable, unique image tags derived from the model version and Git commit hash provide traceability from the deployed endpoint back to the source code and training job. Registering each fine-tuned model version in SageMaker Model Registry with the specific container image tag and S3 model artifact path ensures complete lineage tracking. This is the industry-standard practice for MLOps container versioning with minimal pipeline changes.

Distractor Analysis

  • B is Incorrect: Continuing to use latest with a separate manifest file creates a gap—the manifest can become out of sync with the actual deployed image, and the manifest file itself lacks version control.
  • C is Incorrect: Creating a new ECR repository per model version is excessively complex and violates ECR best practices (repositories are for image families, not versions). This also makes access management and lifecycle policies difficult to maintain.
  • D is Incorrect: ECR's immutable tag feature prevents overwriting tags but doesn't solve the problem of using latest—the latest tag still doesn't identify which model version or training run is deployed. ECR doesn't automatically retain version history beyond image digests.

Key Takeaway: Unique immutable image tags + SageMaker Model Registry registration is the standard practice for traceable ML deployments.

Question 10 - Automated Model Retraining with Fine-Tuned FM Version Approval

A logistics company fine-tunes a foundation model for route optimization on SageMaker. The ML team wants to automate model retraining when new shipment data arrives in S3, using a SageMaker Pipeline. The pipeline performs: data processing, fine-tuning, evaluation, and model registration. The team requires that no fine-tuned model is deployed to production without explicit approval from a senior ML engineer, and the approval process must be integrated into the pipeline.

Which configuration will satisfy the requirement for automated retraining with human approval before deployment? (Select TWO)

  • A) Configure an S3 Event Notification on the shipment data bucket that emits an event to Amazon EventBridge, which triggers StartPipelineExecution on a schedule.
  • B) In the SageMaker Pipeline definition, configure the RegisterModel step, set model_approval_status to PendingManualApproval, and then use the Model Registry's ModelPackageApproved event to trigger the deployment pipeline.
  • C) Configure the SageMaker Pipeline to automatically call UpdateEndpoint after model registration, using the ModelingModelPackage ARN as the new model version.
  • D) Use Amazon S3 Event Notifications directly to invoke the SageMaker Pipeline execution via a direct integration, bypassing EventBridge for lower latency.
  • E) In the SageMaker Pipeline, use a Callback step that pauses the pipeline execution and waits for a human to send an approval token before proceeding to the deployment step.
Click to reveal Answer & Explanation

Correct Answers: B and E

Correct Options Analysis

  • B is Correct: The ModelStep (a.k.a. RegisterModel step in SageMaker Pipelines) supports the model_approval_status parameter set to PendingManualApproval. This registers the model version in Model Registry with "Pending" status, preventing automatic deployment. A separate deployment pipeline is triggered only when the ModelPackageApproved event (emitted by Model Registry after an engineer approves the model) arrives via EventBridge.
  • E is Correct: The Callback step in SageMaker Pipelines allows the pipeline to pause at a specific point and wait for an external signal (approval token) before continuing. The pipeline can use StartPipelineExecution with a callback token, and a human approves by invoking the SendPipelineExecutionStepSuccess API (or through a custom UI) to resume execution and proceed to the deployment step.

Distractor Analysis

  • A is Incorrect: EventBridge with a schedule triggers the pipeline on a fixed cadence, not when new shipment data arrives. The correct trigger would be an EventBridge rule that matches S3 Event Notifications (ObjectCreated events) from the shipment data bucket.
  • C is Incorrect: Automatically calling UpdateEndpoint after registration bypasses the human approval requirement. The model must remain in "Pending" status until a human approves it.
  • D is Incorrect: S3 Event Notifications cannot directly invoke SageMaker Pipeline—the correct pattern is S3 → EventBridge (or SNS/Lambda) → StartPipelineExecution. Additionally, EventBridge provides better filtering and routing capabilities.

Key Takeaway: SageMaker Pipelines supports human-in-the-loop approval through ModelApprovalStatus=PendingManualApproval (Model Registry) or a Callback step (pipeline pause), enabling automated retraining with controlled deployment.