Modeling Approach Selection — JumpStart, Bedrock, and Custom

Modeling approach selection is the first engineering decision on every ML project, and on the MLA-C01 exam it is the dividing line between candidates who think like data scientists and candidates who think like ML Engineers. A data scientist asks "which algorithm gives the best accuracy"; an ML Engineer asks "which AWS service gets a working model in front of users with the right latency, cost, and operational ownership". The MLA-C01 exam is built around the engineer's question. Domain 2 Task 2.1 ("Choose a modeling approach") tests whether you can pick between SageMaker Autopilot, SageMaker JumpStart, Amazon Bedrock, custom SageMaker training jobs, and pre-built AWS AI services like Rekognition, Comprehend, and Forecast — and whether you can defend the choice on engineering grounds, not on algorithm theory.

This guide is the modeling approach selection playbook for the ML Engineer perspective. It builds the decision tree, explains each branch with concrete trade-offs, walks through the BYOC versus script mode versus built-in algorithm spectrum, contrasts Amazon Bedrock against SageMaker-hosted models, and catalogs the modeling approach selection traps the exam plants in scenario stems. Throughout, the focus stays on what an ML Engineer owns — pipeline orchestration, deployment, monitoring, security, cost — rather than on the math an algorithm researcher would obsess over.

What Modeling Approach Selection Means in MLA-C01

Modeling approach selection is the engineering choice between letting AWS manage everything (pre-built AI service or Bedrock managed inference), letting AWS manage most of it with light customization (Autopilot or JumpStart fine-tuning), or owning the training loop directly (built-in algorithm, script mode, or bring-your-own-container). Each rung up the customization ladder costs more engineering hours, more operational surface area, and usually more dollars per inference, but buys more control over accuracy, latency, and data residency. The exam tests whether you can match a scenario's constraints to the lowest rung that still meets requirements.

Why MLA-C01 Tests Modeling Approach Selection Differently from MLS-C01

The Specialty exam (MLS-C01) tests algorithm theory — gradient boosting versus deep neural networks, kernel selection in SVM, embedding dimensions in Word2Vec. The Associate exam (MLA-C01) tests service selection mechanics — which AWS service do you reach for, what does it cost to run, how do you deploy it, what is the operational hand-off, what compliance posture does it inherit. Expect MLA-C01 stems with phrases like "the team has limited ML expertise", "the use case requires sub-second latency", "data cannot leave the AWS account", "the customer wants generative responses to natural-language prompts", or "the workload runs once per quarter". Each phrase points at a different rung on the modeling approach ladder, and your job is to recognize the signal.

The Five-Rung Modeling Approach Ladder

A clean mental model for the exam: rank approaches by who owns what. Rung 1 — pre-built AWS AI services (Rekognition, Comprehend, Translate, Forecast, Transcribe, Polly, Textract, Personalize): AWS owns the model, training data, infrastructure, and accuracy SLA; you call an API. Rung 2 — Amazon Bedrock managed inference: AWS owns the foundation model and infrastructure; you provide prompts and optionally fine-tune. Rung 3 — SageMaker JumpStart and Autopilot: AWS provides curated algorithms or pre-trained models; you provide data and configuration; SageMaker manages training, deployment, and infrastructure. Rung 4 — SageMaker built-in algorithms with script mode: AWS provides framework containers (XGBoost, TensorFlow, PyTorch, MXNet); you provide a training script and hyperparameters. Rung 5 — Bring-Your-Own-Container (BYOC): you provide a Docker image with your full training stack; SageMaker provides only orchestration and managed compute. The right answer on MLA-C01 is almost always the lowest rung that still satisfies the constraints.

Plain-Language Explanation: Modeling Approach Selection

Modeling approach selection is the kind of topic where six AWS services blur together in candidates' heads. Three concrete analogies make the structure stick.

Analogy 1 — The Restaurant Decision: Eat Out, Meal Kit, Cook From Scratch

Imagine you need to feed yourself dinner. You have five options ranked by effort and customization. Going to a fast-food chain (Rung 1, AWS AI services like Rekognition) is fastest — you pay, you get the same burger as everyone else, you cannot ask for a different recipe, but it works in two minutes. Ordering from a fine-dining delivery service with a managed menu (Rung 2, Amazon Bedrock) gives you premium ingredients prepared by an expert kitchen — you pick from their menu, you can ask for "extra spicy" (prompt engineering or light fine-tuning), but you cannot choose the chef's stove brand. Subscribing to a meal-kit service (Rung 3, SageMaker JumpStart and Autopilot) sends you pre-portioned ingredients with a recipe card — you cook, but the heavy decisions (which cut of beef, which spice ratio) are made for you. Buying ingredients at the supermarket and following a cookbook with your own pots (Rung 4, SageMaker built-in algorithms with script mode) means you control the spice level, the doneness, the plating — but you do the cooking. Growing your own vegetables, raising your own chickens, milling your own flour (Rung 5, BYOC) means total control and total time investment.

The MLA-C01 exam plants stems like "the team is small and needs working sentiment analysis tomorrow" — fast food (Comprehend). "We need a chatbot answering company-policy questions in natural English" — fine dining (Bedrock). "We have tabular customer churn data and limited ML expertise" — meal kit (Autopilot). "We need a custom XGBoost model with our own hyperparameter sweep" — supermarket plus cookbook (built-in XGBoost in script mode). "We have a proprietary research algorithm from our PhD lab" — grow your own (BYOC).

Analogy 2 — The Transportation Decision: Uber, Rental Car, Owned Vehicle, Custom Build

You need to get from A to B with a payload. Calling an Uber (Rung 1, AWS AI services) is fastest — driver, vehicle, fuel, navigation all included; you pay per ride; you cannot pick the route. Renting a chauffeur-driven luxury sedan with optional custom routing (Rung 2, Bedrock) gives you a top-tier vehicle and driver but you specify the destination and stops. Renting a car for a week with curated upgrade options (Rung 3, JumpStart) lets you drive yourself with a known good model that has been validated for your use case. Buying a generic sedan and customizing it with off-the-shelf parts (Rung 4, built-in algorithms with script mode) gives you ownership and tuning latitude. Buying raw chassis and engine and assembling a custom race car (Rung 5, BYOC) gives you total control at maximum effort.

For an MLA-C01 stem of the form "the customer needs image moderation for user uploads in 30 days, has no ML team", the Uber answer is Rekognition. For "the customer needs a generative legal-clause writer trained on internal contracts", the chauffeured sedan with custom routing is Bedrock with retrieval-augmented generation or fine-tuning. For "the customer needs to forecast next-quarter revenue from 50 columns of internal sales data", the rental upgrade path is Autopilot. The exam wants the cheapest, most-managed answer that still satisfies the constraints — never the most powerful one.

Analogy 3 — The Construction Decision: Pre-Fab Modular, Stock House, Custom Architect Build

You need a building. A pre-fab modular structure delivered on a truck (Rung 1, AWS AI services) goes up in days for a single fixed footprint. A stock house catalog with options for paint, fixtures, and floor plan (Rung 2, Bedrock) is mass-produced quality with limited customization. A meal-kit-style home kit with assembly choices (Rung 3, JumpStart and Autopilot) provides validated designs with parameter tuning. A general contractor building from a published plan with your-choice materials (Rung 4, built-in algorithms or script mode) is conventional construction. A custom architect-designed structure built from custom blueprints (Rung 5, BYOC) is unique, expensive, and takes a year.

For MLA-C01 stems, "stand up a working solution this sprint" tends to mean Rung 1 or Rung 2; "we have specific accuracy targets and tabular data" tends to mean Rung 3 (Autopilot); "we have framework expertise and want our hyperparameters" tends to mean Rung 4 (built-in or script mode); and "we have a proprietary algorithm or unusual framework" tends to mean Rung 5 (BYOC). The construction analogy also explains operational hand-off — pre-fab needs no maintenance crew, custom architect builds need an entire facilities team, and the modeling approach selection question is fundamentally a question about the operational team you are agreeing to hire.

The Modeling Approach Decision Tree

Memorize this decision tree. The MLA-C01 exam expects you to walk it for every modeling-approach scenario.

Step 1 — Is There a Pre-Built AWS AI Service for This?

If the use case is image labeling, content moderation, face detection, OCR, sentiment analysis, entity extraction, language translation, speech-to-text, text-to-speech, time-series forecasting, recommendation, or document understanding, an AWS AI service almost certainly exists and is the right answer. Rekognition for vision, Comprehend for NLP, Translate for translation, Transcribe for speech-to-text, Polly for text-to-speech, Textract for forms and tables, Forecast for time-series, Personalize for recommendations, Kendra for enterprise search. These services have no training, no model management, no infrastructure — call the API. The exam will sometimes hide this branch behind a stem that mentions "the customer has a small ML team and a tight deadline"; the right answer is always to recognize when the use case is solved by a managed service and stop climbing the ladder.

Step 2 — Is the Use Case Generative AI With a Foundation Model?

If the workload is text generation, summarization, question-answering on natural language, code generation, image generation from prompts, or any conversational use case, the right starting point is Amazon Bedrock. Bedrock provides managed inference for foundation models from Anthropic, Meta, Mistral, Cohere, Stability AI, AI21, and Amazon Titan, all behind one API. You pay per token. You can fine-tune some models with your data (the customization layer) without standing up training infrastructure. The alternative — hosting an open-source LLM on SageMaker — is Rung 3 to Rung 5 effort and only justified when Bedrock cannot meet a specific requirement (region availability, particular open-source model not in Bedrock, deep model surgery beyond fine-tuning).

Step 3 — Is the Data Tabular, Text, or Image, and Does the Team Want AutoML?

If the data is tabular, text, or image, and the team prefers AutoML over hand-tuning, SageMaker Autopilot is the next stop. Autopilot reads the dataset, infers the problem type (classification, regression, multi-class), tries multiple algorithms and hyperparameters, returns a leaderboard of candidate models, and produces an explainability report. Autopilot has three modes: Auto (lets the service pick), Hyperparameter Optimization (HPO) mode, and Ensembling mode. The right time to choose Autopilot is when the team accepts AutoML's algorithm choices and wants a fast, well-engineered baseline.

Step 4 — Is There a Pre-Trained Model in JumpStart That Matches?

JumpStart is SageMaker's curated catalog of pre-trained models — foundation models, vision models, NLP models, tabular models — from Hugging Face, Meta, Stability AI, and AWS partners, plus end-to-end solution templates. Each model can be deployed for inference with one click, fine-tuned on your data, or used as a transfer-learning base. JumpStart is the right answer when you need a specific pre-trained architecture (for example a vision transformer for medical imaging or a BERT variant for biomedical text) that lives in the catalog and either deploys as-is or with light fine-tuning on your data.

Step 5 — Does a SageMaker Built-In Algorithm Match the Problem?

SageMaker provides 17 built-in algorithms tuned for AWS infrastructure — XGBoost for tabular, Linear Learner for classification or regression, k-NN for indexing, BlazingText for word embeddings and text classification, DeepAR for time-series, Object2Vec for pair embeddings, Image Classification, Object Detection, Semantic Segmentation, Random Cut Forest for anomaly, IP Insights for IP-entity association, Factorization Machines, Neural Topic Model, LDA, K-means, PCA, Sequence-to-Sequence. If the problem matches one of these, the built-in algorithm is the right Rung 4 answer — managed framework container, you provide hyperparameters and an S3 input, SageMaker handles the training loop.

Step 6 — Do You Need Script Mode With a Framework Container?

When the algorithm logic is custom but the framework (TensorFlow, PyTorch, MXNet, scikit-learn, XGBoost) is standard, script mode is the right Rung 4.5 answer. SageMaker provides Deep Learning Containers (DLCs) with framework runtimes pre-installed; you provide a Python training script that uses the framework's normal APIs; SageMaker mounts your script into the container, runs it on managed instances, and writes outputs to S3. Script mode lets you run any TensorFlow or PyTorch model without packaging a Docker image yourself.

Step 7 — Do You Need BYOC?

The last resort. Bring-Your-Own-Container is required when you need a non-standard framework, an unusual operating system base, or proprietary dependencies that cannot live in a SageMaker DLC. BYOC means you build a Docker image conforming to SageMaker's container contract (specific entrypoint paths, hyperparameter file conventions, output paths), push it to ECR, and SageMaker runs it as a training job. BYOC inherits all the operational responsibility — image security patching, dependency upgrades, container vulnerability scanning. The exam will rarely route you to BYOC; when it does, the stem will mention something specific that excludes the lower rungs ("the team uses a proprietary library not on SageMaker DLC", "the customer requires an air-gapped image with custom CIS hardening").

SageMaker Autopilot Deep Dive

Autopilot is the most-tested AutoML service on MLA-C01.

What Autopilot Automates

Autopilot automates: problem-type detection (binary classification, multiclass classification, regression), data preprocessing (one-hot encoding, missing value imputation, scaling), algorithm selection (XGBoost, Linear Learner, MLP), hyperparameter tuning, and model evaluation. The output is a leaderboard of candidate models ranked by the chosen metric, plus a notebook of the candidate generation pipeline (so you can audit and reproduce the choices).

Autopilot Modes

• Ensembling mode — fastest, builds AutoGluon-Tabular ensembles, suitable for datasets up to 100 GB; recommended when speed matters and the data is tabular.
• Hyperparameter Optimization (HPO) mode — runs Bayesian-optimized hyperparameter search across base learners, slower but produces stronger single-model results; recommended for accuracy-critical tabular workloads.
• Auto mode — Autopilot decides between Ensembling and HPO based on dataset size and characteristics.

Autopilot for Text and Image

Autopilot also supports text classification (using fine-tuned BERT-family models) and image classification (using fine-tuned vision models). For text and image, Autopilot uses transfer learning under the hood — the right answer when the team has labeled text or image data but lacks deep-learning framework expertise.

Autopilot Explainability

Every Autopilot run produces a SageMaker Clarify SHAP-based explainability report. For regulated workloads requiring "this model's decisions can be explained" documentation, Autopilot is a complete answer because the explainability artifact ships with every job.

When Not to Use Autopilot

Autopilot is the wrong answer when the use case requires a specific algorithm not in the AutoGluon ensemble (for example a custom recurrent net for non-tabular sequential data), when latency for individual training jobs is critical (Autopilot can run for hours), when the dataset exceeds 100 GB (HPO mode caps at 100 GB), or when the team has strong opinions about hyperparameter ranges that conflict with Autopilot's automated choices.

SageMaker JumpStart Deep Dive

JumpStart Catalog Categories

• Foundation Models — Llama, Mistral, Falcon, Stable Diffusion, BERT-family. Deployable as inference endpoints; many fine-tunable.
• Task-Specific Models — sentiment classification, named entity recognition, image classification, object detection, semantic segmentation; pre-trained on standard datasets, ready for transfer learning on your data.
• Solution Templates — end-to-end CloudFormation-deployed solutions for fraud detection, demand forecasting, predictive maintenance, churn prediction; useful as reference architectures.

JumpStart One-Click Deploy

JumpStart deploys any catalog model as a SageMaker real-time endpoint with one click, including the inference container, model artifacts, and pre-tuned hyperparameters. The deployed endpoint is operationally identical to any other SageMaker endpoint — auto-scaling, monitoring, model registry integration all apply.

JumpStart Fine-Tuning

For models that support it, JumpStart fine-tuning launches a SageMaker training job with the pre-trained weights as the base, your S3 dataset as the input, and curated hyperparameters with sensible defaults. Fine-tuning a Llama or Stable Diffusion variant on JumpStart is significantly cheaper and faster than training from scratch.

JumpStart vs Bedrock — The Comparison That Trips Candidates

JumpStart and Bedrock both expose foundation models, but the ownership model differs. With Bedrock, AWS hosts the foundation model on AWS-managed infrastructure; you do not manage instances; you pay per token. With JumpStart, you deploy the foundation model to a SageMaker endpoint that you own; you pay for the underlying instance hours; you control instance type, network isolation, and scaling. The exam plants stems where the right answer is Bedrock (no infrastructure, fast time-to-market, regional inference) versus JumpStart (need VPC isolation, need a model variant not in Bedrock, need fine-grained control over instance type).

Amazon Bedrock for Inference

What Bedrock Provides

A single API surface (bedrock-runtime:InvokeModel and InvokeModelWithResponseStream) for foundation models from multiple providers. You select a model ID, send a prompt, get a response. AWS manages the model hosting, scaling, region routing, and capacity. There is no SageMaker endpoint, no instance, no auto-scaling configuration.

Bedrock Customization Options

• Prompt engineering — zero-cost, change behavior by changing the prompt structure.
• Retrieval-Augmented Generation (RAG) — connect Bedrock to your data via Knowledge Bases, which integrate with OpenSearch Serverless or Aurora for vector storage; queries retrieve relevant context that the model uses to ground its responses.
• Fine-tuning — provide labeled examples; Bedrock produces a customized model variant. Available for select models. The fine-tuned model is hosted on Provisioned Throughput infrastructure.
• Continued Pre-Training — for select foundation models, continue training on your domain corpus to adapt the model's base knowledge.
• Agents for Bedrock — orchestrate multi-step reasoning with tool calls.

When Bedrock Is the Wrong Choice

Bedrock is wrong when you need a model not available in Bedrock's catalog, when your region does not have Bedrock with your chosen model, when you need sub-100ms first-token latency that Bedrock cannot guarantee at on-demand rates, when fine-tuning costs exceed JumpStart fine-tuning + dedicated endpoint hosting at your volume, or when compliance requires the model to live inside a customer-controlled VPC.

SageMaker Built-In Algorithms — Quick Reference for Engineers

The MLA-C01 exam expects matching of common scenarios to the right built-in algorithm.

Tabular and Classical ML

• XGBoost — the default for structured tabular data, classification or regression. Handles missing values, mixed-type features, large datasets. Almost always the right answer for "tabular structured data".
• Linear Learner — fast linear classification or regression at very large scale. Right answer when the dataset has millions of rows and a linear baseline is the goal.
• k-Nearest Neighbors (k-NN) — indexing-based retrieval, similarity search, recommender baselines.
• Factorization Machines — sparse high-dimensional data, click-through rate prediction.

Time-Series

• DeepAR — autoregressive recurrent network for multivariate time-series with covariates. Right answer when the team wants control over a SageMaker training job for forecasting; Amazon Forecast is the right answer when the team prefers a managed service with no model management.

Text

• BlazingText — Word2Vec embeddings or text classification. Fast and cost-efficient for production text classification at scale.
• Object2Vec — pair embeddings (user-item, sentence-pair, document-document). Used for recommenders and semantic similarity.
• Sequence-to-Sequence — encoder-decoder for translation, summarization, text generation; usually superseded by foundation models on Bedrock or JumpStart for new builds.

Vision

• Image Classification — based on ResNet, ImageNet pre-trained.
• Object Detection — bounding-box detection.
• Semantic Segmentation — pixel-level classification.

Anomaly

• Random Cut Forest — unsupervised anomaly detection for streaming and batch data; integrates with Kinesis.
• IP Insights — anomaly detection for IP-entity association patterns; useful for security analytics.

BYOC vs Script Mode vs Built-In Algorithm

This three-way comparison is heavily tested.

Built-In Algorithm

You provide hyperparameters and S3 input data. SageMaker provides the algorithm, the container, and the training loop. Lowest engineering effort, narrowest customization scope. Use when a built-in matches the problem.

Script Mode

You provide a Python training script. SageMaker provides a framework-specific Deep Learning Container (DLC) with TensorFlow, PyTorch, MXNet, scikit-learn, or XGBoost pre-installed. SageMaker injects your script into the DLC and runs it as a training job. Medium engineering effort, broad customization scope. Use when you need framework code without managing the container.

Bring-Your-Own-Container (BYOC)

You provide a Docker image conforming to SageMaker's container contract (the train and serve entrypoints, the /opt/ml/input and /opt/ml/output paths, the hyperparameter and resource config files). SageMaker provides only managed compute and orchestration. Highest engineering effort, broadest customization scope. Use when no framework DLC supports your dependency stack.

The Container Contract You Inherit With BYOC

A SageMaker BYOC training image must respond to the train invocation, read hyperparameters from /opt/ml/input/config/hyperparameters.json, read training data from /opt/ml/input/data/<channel>, write the trained model to /opt/ml/model, and write training metric logs to standard output in a format that SageMaker can scrape. A serving image must accept HTTP POST to /invocations and respond to /ping for health checks. The contract is documented but easy to get wrong; misconfigured BYOC images produce silent failures with cryptic logs.

AWS AI Services — When the Pre-Built API Is the Right Answer

Amazon Rekognition

Image and video analysis: object/scene detection, content moderation, face detection and recognition, celebrity recognition, text in image. Right answer for "we need to moderate user-uploaded images" or "we need to detect logos in marketing assets" — managed model, no training, pay per image. Custom Labels lets you fine-tune on your data without leaving the Rekognition surface.

Amazon Comprehend

Natural language: sentiment, key phrase extraction, entity recognition, language detection, syntax analysis, topic modeling, PII detection. Right answer for "classify customer reviews as positive or negative" or "redact PII from support tickets". Custom Comprehend supports fine-tuning entity recognition or classification on your data.

Amazon Forecast

Time-series forecasting with a managed AutoML pipeline. Reads time-series CSVs, produces forecasts with prediction intervals. Right answer when the team prefers a managed forecasting service with no model management; the alternative is DeepAR on SageMaker.

Amazon Personalize

Real-time personalized recommendations. Reads interaction history, produces a deployed recommendation API. Right answer for "recommend products for an e-commerce site". Replaces the Rung 4 Factorization Machines or k-NN approach when the use case is general-purpose recommendation.

Amazon Textract, Transcribe, Translate, Polly, Kendra

Pre-built APIs for document understanding, speech-to-text, machine translation, text-to-speech, and enterprise search. Each is a single-API answer to a specific problem. The exam will plant scenarios where the use case directly maps to one of these services and the correct answer is to call the API rather than build a custom model.

Transfer Learning Patterns

Transfer learning is the workhorse of modern ML and shows up across multiple modeling approaches.

Transfer Learning With JumpStart

The cleanest path. Pick a pre-trained model from the JumpStart catalog (BERT for NLP, ResNet for vision, Llama for generative), provide your fine-tuning dataset, configure hyperparameters with sensible defaults, launch the fine-tuning job. JumpStart handles the model loading, freezing or unfreezing layers, training the new head, and packaging the resulting artifact. This is the right answer for "we have a small labeled dataset and want to leverage a pre-trained model".

Transfer Learning With Built-In Algorithms

SageMaker's Image Classification, Object Detection, and Semantic Segmentation built-in algorithms support transfer learning natively — toggle the use_pretrained_model hyperparameter and the algorithm starts from ImageNet weights.

Transfer Learning With Script Mode

For framework users, script mode is the path. Pull the pre-trained checkpoint from Hugging Face or PyTorch Hub in your training script, freeze appropriate layers, fine-tune on your data, save the artifact to /opt/ml/model. The training script is conventional framework code; SageMaker's only role is managed compute.

Generative AI Integration in ML Pipelines

Bedrock in a SageMaker Pipeline

A SageMaker Pipeline step can call Bedrock to generate synthetic training data, label unstructured data, or augment a downstream model's inputs. The pattern: Lambda step or Processing step invokes bedrock:InvokeModel, persists the output to S3, downstream steps consume the S3 output. The IAM execution role needs bedrock:InvokeModel on the target model ARN.

LLM-Hosted on SageMaker for Pipeline Use

When Bedrock is not viable (model not available, region not supported, VPC requirement), JumpStart-deployed LLM endpoints can serve the same role. Pipeline steps invoke the endpoint, persist outputs to S3, downstream steps consume.

Hybrid — Generative Plus Discriminative

A common pattern: a JumpStart or Bedrock generative model for unstructured-data understanding, a SageMaker XGBoost classifier on top of structured features for the final decision. Modeling approach selection here means picking the right tool per stage rather than forcing one approach across the pipeline.

Common Modeling Approach Selection Traps on MLA-C01

Trap 1 — Defaulting to Custom Training Because It Sounds More Sophisticated

The most common candidate error. The exam consistently rewards the simplest approach that meets the requirements. If Comprehend solves the problem, Comprehend is the answer.

Trap 2 — Confusing Bedrock With JumpStart

Bedrock is managed inference with no infrastructure. JumpStart deploys to a SageMaker endpoint you own. Stems mentioning "no infrastructure" or "pay per token" route to Bedrock; stems mentioning "VPC isolation" or "specific instance type" route to JumpStart.

Trap 3 — Choosing BYOC When Script Mode Suffices

If the framework is TensorFlow, PyTorch, MXNet, scikit-learn, or XGBoost, script mode covers it. BYOC is required only for non-standard frameworks or proprietary dependencies that cannot live in a DLC.

Trap 4 — Ignoring Data Residency and VPC Constraints

A stem that mentions "data must not leave our VPC" or "we operate in GovCloud" excludes services that are not VPC-bound or not GovCloud-resident. Bedrock availability and AI service availability vary by region; check the constraint before picking.

Trap 5 — Treating Autopilot as a Magic Bullet

Autopilot is constrained to its supported problem types (tabular classification/regression, text classification, image classification) and dataset sizes (up to 100 GB for HPO). For other use cases, Autopilot is the wrong answer.

Trap 6 — Forgetting That Forecast Replaces DeepAR for Many Use Cases

For straightforward time-series forecasting with no need for SageMaker integration, Amazon Forecast is the lower-rung answer. DeepAR is right when the team wants pipeline integration or a SageMaker-native artifact.

Trap 7 — Picking SageMaker Custom for Sentiment Analysis

The exam plants stems where the obvious instinct is "fine-tune a transformer for sentiment". The correct answer is almost always Comprehend (or Custom Comprehend if the data is domain-specific).

Trap 8 — Overlooking Custom Labels and Custom Comprehend

When the AI service does not match out of the box, the customization layer (Rekognition Custom Labels, Custom Comprehend) is the next rung — not jumping to SageMaker custom training.

Trap 9 — Treating Foundation Model Selection as Algorithm Theory

The exam does not test which foundation model has the best perplexity. It tests whether you know Bedrock hosts multiple providers, JumpStart hosts a different but overlapping set, and customization mechanics differ across both.

Trap 10 — Conflating "Custom" With "Better"

Climbing the ladder costs engineering hours, ongoing maintenance, and inference cost. The exam consistently rewards the engineer who recognizes that the lowest viable rung is the right answer.

Key Numbers and Must-Memorize Modeling Approach Facts

The Five-Rung Ladder

• Rung 1: AWS AI services (Rekognition, Comprehend, Forecast, ...)
• Rung 2: Amazon Bedrock managed inference
• Rung 3: SageMaker Autopilot, JumpStart
• Rung 4: SageMaker built-in algorithms, script mode
• Rung 5: Bring-Your-Own-Container (BYOC)

Autopilot Limits

• Tabular dataset cap: 100 GB for HPO mode
• Modes: Auto, Ensembling, HPO
• Problem types: tabular classification/regression, text classification, image classification

Bedrock vs JumpStart

• Bedrock: managed inference, no infrastructure, per-token pricing
• JumpStart: SageMaker endpoint you own, per-instance-hour pricing, VPC-able

BYOC Container Contract

• train invocation entrypoint
• Hyperparameters at /opt/ml/input/config/hyperparameters.json
• Training data at /opt/ml/input/data/<channel>
• Model output at /opt/ml/model
• Inference: /invocations POST, /ping health check

Common AWS AI Services

• Rekognition: vision (Custom Labels for fine-tuning)
• Comprehend: NLP (Custom Comprehend for fine-tuning)
• Forecast: time-series
• Personalize: recommendations
• Textract: documents and forms
• Translate, Transcribe, Polly: translation, speech-to-text, text-to-speech

FAQ — Modeling Approach Selection Top Questions

Q1 — When does an MLA-C01 stem call for Amazon Bedrock and when does it call for SageMaker JumpStart?

If the stem emphasizes "no infrastructure to manage", "fastest time to market", "pay per token", or describes a generative-AI use case where AWS-managed inference is acceptable, the answer is Bedrock. If the stem emphasizes "VPC isolation", "specific instance type", "fine-grained instance scaling", "model not available in Bedrock", or "data must stay in a customer-controlled endpoint", the answer is JumpStart. Both can host foundation models; Bedrock owns the infrastructure and you pay per token, while JumpStart deploys the model to a SageMaker endpoint you own and you pay per instance-hour. The exam typically plants one of those phrases as the deciding signal.

Q2 — When should the answer be a pre-built AWS AI service rather than SageMaker custom training?

Whenever the problem directly maps to the AI service's scope and the customer accepts the service's accuracy bounds. Comprehend for sentiment, key-phrase extraction, entity recognition, PII redaction. Rekognition for image labeling, content moderation, face detection. Forecast for time-series. Personalize for recommendations. Textract for documents and forms. The MLA-C01 exam consistently rewards picking the AI service even when the candidate's instinct is to build custom — climb to SageMaker only when an explicit constraint (custom accuracy SLA, regional availability, VPC requirement, or unique customization need) excludes the AI service.

Q3 — How do I decide between SageMaker Autopilot and a built-in algorithm like XGBoost?

Autopilot is the right answer when the team wants AutoML — they accept that Autopilot will choose the algorithm and hyperparameters, and they value the leaderboard, explainability report, and notebook output that document the choices. The built-in XGBoost is the right answer when the team has opinions about hyperparameters, wants a single specific algorithm, or is integrating into an existing pipeline that expects a SageMaker training job. For tabular structured data with limited ML expertise on the team, Autopilot is consistently the right starting answer; for tabular structured data with experienced engineers wanting control, XGBoost in script or built-in mode is the right answer.

Q4 — When should I use BYOC instead of script mode?

BYOC is required only when no SageMaker Deep Learning Container (DLC) supports your framework or dependency stack. The DLCs cover TensorFlow, PyTorch, MXNet, scikit-learn, XGBoost, and Hugging Face Transformers. If your code uses any of these frameworks with conventional dependencies, script mode is the right answer — you provide the Python script, SageMaker provides the container. BYOC is required for proprietary frameworks, custom CUDA stacks not in the DLCs, hardened images with custom CIS or FIPS profiles, or air-gapped images. The MLA-C01 exam routes to BYOC only when an explicit constraint excludes script mode; defaulting to BYOC adds significant operational burden (image patching, vulnerability scanning, dependency upgrades) that the exam expects you to recognize.

Q5 — How do I decide between Amazon Forecast and SageMaker DeepAR?

Forecast is the managed-service answer — no model management, no SageMaker training job, AutoML over multiple algorithms, deployed forecasting API. The right answer when the team wants a forecasting solution with minimal ML expertise and no integration into a SageMaker pipeline. DeepAR is the SageMaker built-in algorithm — you train, you deploy to a SageMaker endpoint, you integrate into a SageMaker pipeline, you control the model artifact lifecycle. The right answer when the customer requires SageMaker-native artifacts, when the use case integrates with other SageMaker components (Feature Store, Model Registry, Model Monitor), or when the customer wants control over the training-deployment-monitoring loop.

Q6 — How do JumpStart fine-tuning and Bedrock fine-tuning differ?

JumpStart fine-tuning runs a SageMaker training job — you select a pre-trained model from the JumpStart catalog, provide your S3 dataset, configure hyperparameters, launch the job, and the result is a SageMaker model artifact you deploy to a SageMaker endpoint. You own the resulting endpoint, the instance hours, and the operational lifecycle. Bedrock fine-tuning runs inside Bedrock's managed surface — you select a Bedrock model that supports fine-tuning, provide a labeled dataset, Bedrock produces a customized model variant hosted on Provisioned Throughput. You do not manage instances, but you commit to a Provisioned Throughput plan to host the fine-tuned variant. The decision: JumpStart fine-tuning gives you control and per-instance pricing; Bedrock fine-tuning gives you a managed surface with Provisioned Throughput pricing. Choose based on whether the customer prioritizes infrastructure control or operational simplicity.

Q7 — A stem says "the customer needs to extract entities and PII from millions of customer support tickets". Which modeling approach?

Amazon Comprehend, Rung 1. Specifically the DetectEntities and DetectPiiEntities APIs (or batch jobs for the volume implied). Custom Comprehend is the next rung if the entity types are domain-specific and the standard model misses them. Building a custom NER model on SageMaker is the wrong answer at the Associate level — it adds engineering effort, training infrastructure, ongoing maintenance, and operational ownership for a problem that is already solved by a managed service. The MLA-C01 exam plants this exact stem pattern repeatedly; the right answer is always the AI service unless an explicit constraint forces climbing.

Further Reading — Official AWS Documentation for Modeling Approach Selection

The authoritative AWS sources are: SageMaker Developer Guide (especially the Built-in Algorithms reference, JumpStart documentation, Autopilot documentation, and Bring-Your-Own-Container documentation), Amazon Bedrock User Guide (especially the model selection guide and customization documentation), and the individual AI service developer guides (Rekognition, Comprehend, Forecast, Personalize, Textract). The AWS Well-Architected Machine Learning Lens provides the modeling-approach decision framework that MLA-C01 borrows from. AWS re:Invent and re:MARS sessions on "choosing the right ML service" provide additional decision tree material that mirrors exam stems. The AWS Machine Learning Blog has a long history of "from AI service to SageMaker" migration case studies that illustrate the climbing-the-ladder pattern, and the AWS Solutions Library hosts reference implementations that show modeling approach decisions in production architectures.