Skill 3.2.2: Automate compute resource provisioning with integrated communication between stacks and orchestration services
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - CloudFormation Cross-Stack References for SageMaker Endpoints A networking team owns the AWS VPC resources, and an ML engineering team owns the Amazon SageMaker AI endpoint resources. Both teams use AWS CloudFormation to manage their infrastructure. The ML team's endpoint stack must deploy instances into the private subnets and use the security groups created by the networking team's stack, without hardcoding IDs. Which approach satisfies these requirements with the least operational overhead and maintains a single source of truth for identifiers? (Select ONE) - A) Manually copy the subnet and security group IDs from the AWS Management Console and enter them as Parameters in the ML team's CloudFormation template. - B) Configure the networking stack to output the resource IDs and use the Fn::ImportValue function in the ML team's stack to reference them.- C) Create a custom AWS Lambda function that uses Boto3 to fetch the network IDs and pass them to the SageMaker stack deployment. - D) Deploy both stacks as nested stacks within a single parent template to share resources automatically. |
Correct Answer: B Correct Answer Analysis: - B is Correct: Exporting the subnet and security group IDs from the networking stack's Outputs section and importing them in the ML stack using Fn::ImportValue creates a direct cross-stack reference. This ensures the ML stack dynamically retrieves the current values without hardcoding, maintaining separation of concerns and minimizing operational overhead.Distractor Analysis: - A is Incorrect: Manually copying IDs introduces configuration drift and operational overhead, violating the constraint of a single source of truth. - C is Incorrect: Using a custom Lambda function adds unnecessary complexity and maintenance overhead when CloudFormation natively supports cross-stack references. - D is Incorrect: Nested stacks combine the lifecycle of both stacks into a single parent stack, which violates the requirement for separate team ownership and independent lifecycle management. > Exam Tip: Use CloudFormation Export and Fn::ImportValue to decouple infrastructure layers while securely passing configurations (like Subnet IDs) between separately owned stacks. |
| ### Question 2 - Orchestrating Ephemeral ML Environments with Step Functions An MLOps engineer is automating the deployment of a complex ML environment. The workflow requires provisioning a VPC endpoint and an Amazon SageMaker AI real-time endpoint, and then running a series of validation tests. If the endpoint deployment fails, the VPC endpoint must be rolled back automatically. The solution must minimize operational overhead. Which orchestration strategy best meets these requirements? (Select ONE) - A) Use AWS Step Functions to orchestrate AWS CloudFormation stack deployments, utilizing CreateStack and DeleteStack actions with Catch and Retry states for failure handling.- B) Use AWS CodePipeline with separate stages for VPC and SageMaker deployments, relying on pipeline-level manual approvals for failure recovery. - C) Use an AWS Lambda function triggered by EventBridge to make Boto3 API calls for provisioning, with custom try-except blocks for rollback. - D) Deploy a single AWS CloudFormation nested stack containing both the VPC and SageMaker resources, using CloudFormation Rollback triggers. |
Correct Answer: A Correct Answer Analysis: - A is Correct: AWS Step Functions provides native orchestration for CloudFormation stack deployments. By using Step Functions states, you can define sequential execution, wait for completion, and use Catch blocks to execute rollback logic (e.g., deleting the VPC stack) if the SageMaker stack fails, minimizing manual intervention and operational overhead.Distractor Analysis: - B is Incorrect: Relying on manual approvals for failure recovery introduces human intervention, violating the automation and low-operational-overhead constraints. - C is Incorrect: Writing custom Lambda functions with try-except blocks for infrastructure orchestration is an anti-pattern compared to using native Step Functions integrations, resulting in higher maintenance overhead. - D is Incorrect: While CloudFormation handles rollback within a single stack automatically, combining them into a nested stack violates the separation of concerns and doesn't provide the custom, multi-step validation workflow requested. > Exam Tip: AWS Step Functions is the preferred service for orchestrating complex, stateful workflows involving multiple AWS service integrations (like CloudFormation) with custom error handling and rollback logic. |
| ### Question 3 - Passing Objects Between AWS CDK Stacks An engineering team is using the AWS Cloud Development Kit (AWS CDK) to provision resources for an ML workload. The networking stack creates a VPC, and the ML stack creates a SageMaker AI endpoint. The ML stack must reference the VPC created by the networking stack to configure private subnets for the endpoint. Which method provides integrated communication between the CDK stacks with strong typing and the least operational overhead? (Select ONE) - A) Pass the vpc.Vpc object from the networking stack directly to the ML stack's construct, allowing CDK to handle the cross-stack reference automatically.- B) Export the VPC ID as a string from the networking stack and use Fn.importValue in the ML stack to pass the string to the SageMaker construct.- C) Store the VPC ID in AWS Systems Manager Parameter Store and have the ML stack read it during synthesis. - D) Deploy both stacks in the same AWS CDK App and use hardcoded VPC IDs in the ML stack's environment variables. |
Correct Answer: A Correct Answer Analysis: - A is Correct: In AWS CDK, you can pass the actual AWS resource object (e.g., ec2.Vpc) directly to a construct in another stack. CDK automatically creates the underlying CloudFormation cross-stack references (exports/imports) for you, providing strong typing and minimizing boilerplate code.Distractor Analysis: - B is Incorrect: While Fn.importValue works in CDK, it returns a string token, losing the strong typing benefits of passing the native CDK object. It is generally used when importing resources not managed by the current CDK app.- C is Incorrect: Using Systems Manager Parameter Store introduces an external dependency and runtime resolution that is unnecessary when CDK can handle the reference at synthesis time. - D is Incorrect: Hardcoding identifiers defeats the purpose of Infrastructure as Code and creates configuration drift risks. > Exam Tip: In AWS CDK, passing actual resource objects (like Vpc or SecurityGroup) between stacks is the best practice, as CDK automatically translates this into secure CloudFormation cross-stack references. |
| ### Question 4 - Sharing ECR Image URIs Across Stacks A data science team needs to deploy a custom inference container for a SageMaker AI endpoint. The container image is stored in Amazon ECR, which is managed in a separate "Shared Services" CloudFormation stack owned by the platform team. The SageMaker endpoint stack must dynamically retrieve the latest ECR image URI during deployment without hardcoding values. How should the endpoint stack be configured to ensure automated provisioning and integrated communication? (Select ONE) - A) Configure the Shared Services stack to export the ECR image URI, and have the SageMaker stack import this value using Fn::ImportValue.- B) Manually update the SageMaker CloudFormation template with the ECR image URI every time a new container version is pushed. - C) Use an AWS Lambda function backed by a custom resource in the SageMaker stack to query the ECR API for the latest image tag. - D) Store the ECR repository name in an Amazon S3 bucket and retrieve it using a CloudFormation macro during deployment. |
Correct Answer: A Correct Answer Analysis: - A is Correct: Using CloudFormation Export in the Shared Services stack and Fn::ImportValue in the SageMaker stack allows the endpoint stack to dynamically resolve the ECR image URI at deployment time. This integrates the stacks natively without requiring manual updates or custom code.Distractor Analysis: - B is Incorrect: Manually updating templates introduces human error and operational overhead, failing the automation constraint. - C is Incorrect: Using a custom Lambda resource to query the ECR API is overly complex for a simple value pass-through that CloudFormation handles natively. - D is Incorrect: Storing the repository name in S3 and using macros adds unnecessary complexity and potential points of failure compared to native stack exports. > Exam Tip: CloudFormation cross-stack references ( Export and Fn::ImportValue) are the most efficient way to share dynamically generated resource ARNs and URIs (like ECR images) between independently managed stacks. |
| ### Question 5 - Automating Application Auto Scaling Registration An MLOps engineer is designing an automated deployment pipeline for a SageMaker AI endpoint. The pipeline uses AWS CloudFormation to provision the endpoint. After the endpoint is successfully created and in the InService state, the endpoint variant must be automatically registered as a scalable target with Application Auto Scaling.Which configuration achieves automated resource provisioning with integrated communication between the stacks? (Select ONE) - A) Define an AWS::ApplicationAutoScaling::ScalableTarget resource in the CloudFormation template and use the DependsOn attribute to ensure it is created after the SageMaker endpoint.- B) Use an AWS Lambda custom resource triggered on stack creation to invoke the RegisterScalableTarget API via Boto3.- C) Attach an Auto Scaling group to the SageMaker endpoint natively within the AWS::SageMaker::Endpoint resource properties.- D) Configure an Amazon EventBridge rule to listen for the endpoint state change to InService and trigger an AWS Lambda function to register the scalable target. |
Correct Answer: A Correct Answer Analysis: - A is Correct: CloudFormation natively supports creating AWS::ApplicationAutoScaling::ScalableTarget resources. By using the DependsOn attribute (or simply referencing the endpoint variant in the scalable target properties), CloudFormation orchestrates the creation order automatically, registering the endpoint variant with Application Auto Scaling during the stack deployment.Distractor Analysis: - B is Incorrect: Using a custom Lambda resource is unnecessary because CloudFormation has native support for Application Auto Scaling resources, making this an anti-pattern that increases operational overhead. - C is Incorrect: The AWS::SageMaker::Endpoint resource does not natively accept an Auto Scaling group configuration; scaling is managed separately via Application Auto Scaling.- D is Incorrect: While EventBridge and Lambda can achieve this, it decouples the scaling configuration from the infrastructure code, making it less reliable and harder to track than native CloudFormation resource orchestration. > Exam Tip: Always prefer native CloudFormation resource types (like AWS::ApplicationAutoScaling::ScalableTarget) over custom Lambda functions to manage dependencies and orchestrate provisioning natively. |
| ### Question 6 - Deploying SageMaker into an Existing VPC Stack A machine learning team is migrating their model hosting infrastructure to AWS CloudFormation. They have an existing CloudFormation stack that provisions a complex VPC architecture including private subnets and S3 VPC endpoints. They need to create a new stack for their Amazon SageMaker AI endpoint that deploys into this existing VPC. Which approach provides the least operational overhead and maintains separation of concerns? (Select ONE) - A) Use the Fn::GetAtt function in the SageMaker stack to directly query the attributes of the VPC stack's resources.- B) Export the subnet and security group IDs from the VPC stack's Outputs section and import them in the SageMaker stack using Fn::ImportValue.- C) Delete the existing VPC stack and recreate the VPC resources inside the SageMaker stack's template to form a nested stack. - D) Use the DependsOn attribute in the SageMaker stack, pointing to the VPC stack name, to automatically inherit the network configurations. |
Correct Answer: B Correct Answer Analysis: - B is Correct: Exporting the necessary resource IDs from the VPC stack and importing them in the SageMaker stack creates a clean dependency link without merging the stacks. This maintains separation of concerns and allows both stacks to be managed independently. Distractor Analysis: - A is Incorrect: Fn::GetAtt cannot retrieve attributes from resources located in a completely different CloudFormation stack; it only works within the same stack.- C is Incorrect: Deleting and recreating the existing VPC stack causes downtime and violates the requirement to maintain separation of concerns between networking and ML teams. - D is Incorrect: The DependsOn attribute only enforces creation order within the same stack; it does not share or inherit configurations across different stacks.> Exam Tip: Fn::ImportValue is the standard CloudFormation mechanism for securely passing resource identifiers between independently managed stacks without merging them. |
| ### Question 7 - Orchestrating Blue/Green Deployments for SageMaker An AI company is building a stateful orchestration workflow to manage the lifecycle of an Amazon SageMaker AI endpoint. The workflow must programmatically provision the endpoint, run a battery of validation tests, and if successful, shift traffic to the new endpoint using infrastructure as code principles. The solution must minimize operational overhead. Which TWO strategies satisfy these requirements? (Select TWO) - A) Use AWS Step Functions to orchestrate the execution of AWS CloudFormation stack updates for the endpoint, managing the transition between deployment and validation steps. - B) Use AWS CodePipeline to orchestrate the deployment stages, triggering CloudFormation stack updates for provisioning and invoking AWS Lambda for validation tests. - C) Manually run aws cloudformation update-stack via a bastion host to provision the endpoint and trigger the validation suite.- D) Use the high-level SageMaker Python SDK within a monolithic AWS Lambda function to manage the entire endpoint lifecycle and testing logic. - E) Use AWS Elastic Beanstalk to deploy the SageMaker endpoint configuration and manage traffic shifting. |
Correct Answers: A and B Correct Answers Analysis: - A is Correct: AWS Step Functions provides the orchestration layer required to manage state, trigger CloudFormation stack updates (which handle the blue/green traffic shifting natively), and conditionally execute validation tests based on deployment success. - B is Correct: AWS CodePipeline natively orchestrates multi-stage deployments. It can trigger CloudFormation stack updates for infrastructure provisioning and seamlessly integrate Lambda for validation testing in a sequential CI/CD workflow. Distractor Analysis: - C is Incorrect: Manual execution via a bastion host violates the automation and low-operational-overhead constraints. - D is Incorrect: Writing a monolithic Lambda function to handle complex state, orchestration, and lifecycle management is an anti-pattern that is difficult to maintain and prone to timeouts. - E is Incorrect: AWS Elastic Beanstalk is an application platform service and does not manage SageMaker AI endpoints. > Exam Tip: For orchestrating ML infrastructure as code, use AWS Step Functions for stateful, complex workflows with custom logic, and AWS CodePipeline for standard CI/CD stage-based deployments. |
| ### Question 8 - Programmatic Deployment with Boto3 A developer needs to programmatically deploy an Amazon SageMaker AI endpoint using the AWS SDK for Python (Boto3). The developer has specific requirements to tune individual API parameters like DataCaptureConfig and AsyncInferenceConfig that are not easily exposed in high-level abstractions, requiring granular control over the API request payload.Which programmatic approach best meets this requirement? (Select ONE) - A) Use the high-level SageMaker Python SDK estimator and model builder classes. - B) Use the low-level Boto3 create_endpoint, create_endpoint_config, and create_model API calls directly.- C) Use AWS CloudFormation to deploy the endpoint via a nested stack. - D) Use the AWS CLI with a formatted JSON file for the endpoint configuration. |
Correct Answer: B Correct Answer Analysis: - B is Correct: The lower-level Boto3 client ( sagemaker) exposes individual API actions like create_model, create_endpoint_config, and create_endpoint. This provides maximum granularity to define every field in the request payload, such as AsyncInferenceConfig and DataCaptureConfig, without being restricted by high-level SDK abstractions.Distractor Analysis: - A is Incorrect: The high-level SageMaker Python SDK abstracts away many API details to simplify usage. While it can handle complex configs, the prompt specifies a need for granular control over individual API payload fields not easily exposed in abstractions, making the low-level client the better fit. - C is Incorrect: Using CloudFormation defines resources declaratively via a template, not programmatically via code logic (which is requested here). - D is Incorrect: While the AWS CLI can use JSON files, it is a command-line tool, not a programmatic approach using a language SDK. > Exam Tip: When you need granular control over individual API request parameters that high-level abstractions hide, use the low-level Boto3 client to call SageMaker APIs directly. |
| ### Question 9 - Orchestrating Stack Updates with Step Functions An ML engineering team uses AWS Step Functions to orchestrate an automated retraining pipeline. When a model drift is detected, Step Functions must programmatically trigger the deployment of an updated Amazon SageMaker AI endpoint using infrastructure as code, while ensuring the network configuration stack is updated first if necessary. Which configuration provides integrated communication between the orchestration service and the stacks? (Select ONE) - A) Use the Step Functions CloudFormation:CreateStack or UpdateStack task state to deploy the network stack, wait for completion, and then use another CloudFormation task to deploy the SageMaker stack.- B) Trigger an AWS Lambda function from Step Functions that runs the AWS CLI commands to update the CloudFormation stacks. - C) Use Amazon EventBridge to route a drift detection alert to AWS CodePipeline, which runs the CloudFormation deployments sequentially. - D) Use the SageMaker CreateEndpoint API directly within Step Functions and handle the VPC configuration manually in the console. |
Correct Answer: A Correct Answer Analysis: - A is Correct: Step Functions has native service integrations for CloudFormation. You can use the CreateStack or UpdateStack task to execute stack deployments natively. By configuring the state machine to wait for the network stack to reach CREATE_COMPLETE or UPDATE_COMPLETE before triggering the SageMaker stack, you ensure orchestrated, sequential deployment with integrated communication.Distractor Analysis: - B is Incorrect: While using a Lambda function to run CLI commands works, it introduces unnecessary custom code and operational overhead when Step Functions has native, optimized integrations for CloudFormation. - C is Incorrect: While EventBridge and CodePipeline can automate deployments, this scenario specifically asks for the orchestration to be triggered and managed by Step Functions due to the drift detection workflow. - D is Incorrect: Using the SageMaker API directly bypasses the Infrastructure as Code requirement and manual console configuration violates automation constraints. > Exam Tip: AWS Step Functions supports native integrations with AWS CloudFormation, allowing you to trigger stack updates and wait for their completion directly within your state machine without writing custom Lambda code. |
| ### Question 10 - Agent Infrastructure IAM Integration Across Stacks An organization is deploying an agentic workflow infrastructure using Amazon Bedrock AgentCore. They need to provision the runtime, memory, and gateway resources using AWS CloudFormation. The agent's execution role must have permissions to invoke downstream tools hosted in a different CloudFormation stack managed by the API team. Which approach fulfills the requirement for integrated communication between stacks while maintaining least privilege? (Select ONE) - A) Export the downstream tool API ARNs from the API team's stack and import them into the AgentCore stack's IAM policy using Fn::ImportValue.- B) Attach a managed policy with broad execute-api:* permissions to the agent's execution role to ensure connectivity.- C) Use a CloudFormation nested stack to deploy both the AgentCore resources and the downstream tools in the same template. - D) Use an AWS Lambda custom resource to fetch the API endpoints and inject them into the IAM role policy at runtime. |
Correct Answer: A Correct Answer Analysis: - A is Correct: Exporting the specific tool API ARNs from the API team's stack and importing them using Fn::ImportValue into the AgentCore stack ensures that the IAM execution role only has permissions to invoke the exact resources required. This maintains least privilege while establishing integrated communication between the stacks.Distractor Analysis: - B is Incorrect: Attaching broad execute-api:* permissions violates the principle of least privilege, granting access to APIs beyond the intended downstream tools.- C is Incorrect: Combining them into a nested stack violates the requirement that the API team manages their own separate stack. - D is Incorrect: Using a Lambda custom resource to inject ARNs at runtime is overly complex and harder to audit compared to native CloudFormation cross-stack references. > Exam Tip: For maintaining least privilege across independently managed stacks, use CloudFormation exports/imports to pass specific resource ARNs directly into IAM policy statements. |