Deployment and Orchestration of ML and AI Workflows

Picture one Amazon Bedrock knowledge base, the store of your documents that a generative AI application retrieves passages from: how each query searches it (its search type and metadata filters) is one decision (choose), how its documents are split into chunks and indexed is a second (provision), and how the index is synced again by an ingestion job when documents change is a third (automate). This domain splits every machine learning (ML) and artificial intelligence (AI) deployment the same way: choose where a model or agent runs, how callers invoke it and the settings each query carries; provision the capacity, networking, container images, knowledge base indexes and agent state it runs on (directly or through AWS CloudFormation stacks), plus AWS Step Functions workflows that run SageMaker AI training and processing jobs and wait for them to finish; and automate how each new version is built, tested, promoted and rolled back. The classic trap answers a question from one step with a tool from another: a scaling policy for requests too large or too slow for a synchronous endpoint, when Asynchronous Inference exists to queue them (a choose decision), or more instances (a provision change) when an endpoint update must roll back automatically, which SageMaker AI deployment guardrails do (an automate decision; not Amazon Bedrock Guardrails, which filter prompts and responses). Name the step first, and only the answers that belong to it stay in play.

The domain carries 24 percent of scored content, the same as two other domains, while Data Preparation for ML and AI carries 28 percent. Manage deployment infrastructure for ML and AI models covers the choose step: the four SageMaker AI inference options (real-time inference, Serverless Inference, Asynchronous Inference and batch transform), picked by how the caller waits for the result; sharing one endpoint among several models; hosting a model trained outside AWS; running a foundation model (FM) on Amazon Bedrock or on a SageMaker AI endpoint; hosting agents on Amazon Bedrock AgentCore Runtime and connecting them to tools; and per-query knowledge base settings. Provision and configure ML and AI workload resources covers the provision step: on-demand versus provisioned SageMaker AI endpoint capacity; auto scaling on a per-unit load signal, a metric such as InvocationsPerInstance that falls when capacity is added; creating the model, endpoint configuration and endpoint in order, directly or through CloudFormation stacks; Step Functions workflows that run SageMaker AI training and processing jobs and wait for them to finish (automated provisioning; a model-building pipeline in SageMaker Pipelines is instead the automate step, which releases each new version); container images; private networking; knowledge base chunking and vector indexes; and agent state in AgentCore Memory. Automate orchestration and delivery for ML and AI workloads covers the automate step: a model-building pipeline in Amazon SageMaker Pipelines and a release pipeline in AWS CodePipeline, joined by SageMaker Model Registry approval; versions of models, prompts, flows and agents; release gates; endpoint rollouts; retraining triggers; and knowledge base ingestion jobs. The decision tree on this page asks the three step questions in that order.

Each convenient option comes with a documented list of what it does not do, and the detail that separates two plausible answers is often on that list. Three examples: Serverless Inference does not support graphics processing units (GPUs) or virtual private cloud (VPC) configuration, among other real-time inference features; AWS Step Functions Express Workflows support only the Request Response integration pattern, which moves on as soon as the service responds, so they cannot use the Run a Job (.sync) pattern that waits for a SageMaker AI training job to finish, as Standard Workflows can (a provision decision under the AWS MLA-C02 exam guide's Task 3.2); and deployment guardrails, the SageMaker AI managed options for updating an endpoint with automatic rollback, apply only to real-time and asynchronous endpoints. Read the scenario for its hard requirement (accelerators, private networking, waiting for completion, automatic rollback), discard every option that excludes it, and then prefer the most managed option that remains.