Choosing a Modeling Approach

The build-vs-buy ladder

A question gives you a business problem and four answers that each solve it at a different level of effort, and the right pick is the lowest-effort approach that actually meets the requirements. Picture four rungs on a ladder, cheapest and most managed at the bottom: a managed AI service, a foundation model on Amazon Bedrock, a SageMaker built-in algorithm or JumpStart pre-trained model you train or fine-tune, and a fully custom model you write from scratch. You climb only when the rung below cannot do the job.

Rung 1: managed AI service

At the bottom sit the pre-trained AI services. Each wraps a model AWS already trained behind a simple API, so you send input and get a result with no training data, no tuning, and no endpoint to run. They cover common, well-bounded tasks: Amazon Rekognition^[1] for image and video analysis, Amazon Transcribe^[2] for speech-to-text, Amazon Translate^[3] for language translation, Amazon Textract^[4] for pulling text and data out of documents, Amazon Comprehend^[5] for natural-language tasks like entity and sentiment extraction, Amazon Personalize^[6] for recommendations, and Amazon Forecast^[7] for time-series forecasting. Comprehend's own documentation makes the value plain: for its pre-trained features 'there is no need for you to provide training data'. If a service on this rung already does the task and you have no special accuracy or customization need, this is the answer.

Rung 2: foundation model on Bedrock

When the task is generative or open-ended language work (summarize a document, answer questions, draft text, classify free text with few examples), reach for a foundation model rather than training one. Amazon Bedrock^[8] is a fully managed, serverless service that offers a choice of foundation models from several providers behind a single API, so 'you don't have to manage any infrastructure'. You can use a model as-is, ground it on your own data with Knowledge Bases for retrieval-augmented generation, or fine-tune it, all without standing up GPU clusters.

Rung 3: built-in algorithm or JumpStart

Drop to Amazon SageMaker AI^[9] when the prediction is specific to your own data and no managed service covers it: churn on your customers, a price for your inventory, a defect unique to your product line. Prefer a built-in algorithm before custom code, and use SageMaker JumpStart^[10] when you want to start from a pre-trained model and fine-tune it, which needs far less labeled data than training from zero. The next section maps problem types to the specific built-in algorithm.

Rung 4: fully custom model

The top rung, writing your own algorithm in a SageMaker training container, is the most flexible and the most expensive in data, time, and skill. It is justified only when no lower rung fits: a novel architecture, a research problem, or accuracy requirements the built-ins cannot reach. On the exam, an answer that jumps straight to a custom model for a task a managed service or built-in algorithm already handles is the distractor, not the key.

The four modeling approaches ranked by build effort; stop at the lowest rung that meets the requirements.

Pick the built-in algorithm from the problem type

Once you are on the SageMaker rung, the question becomes which built-in algorithm fits, and AWS hands you the map: built-in algorithms are grouped by learning paradigm (supervised, unsupervised) and by data domain (text, image), and each group lists the problem types it solves. Read the problem type out of the stem first, then name the algorithm.

Supervised learning on tabular data

For supervised problems^[11] where you have labeled examples, the split is classification (assign a category) versus regression (predict a number). Both run on the same family of tabular algorithms: XGBoost^[12], Linear Learner^[13], K-Nearest Neighbors^[14], Factorization Machines^[15], LightGBM, CatBoost, TabTransformer, and AutoGluon-Tabular. XGBoost, a gradient-boosted-trees implementation, is the default first reach for structured classification and regression because it is strong out of the box; Linear Learner fits a linear function and is the more interpretable choice. Factorization Machines is built for high-dimensional sparse data such as click or recommendation matrices.

Time series, clustering, anomaly, dimensionality

Time-series forecasting (predict future values from history) is its own supervised problem with one built-in: DeepAR^[16], a recurrent-neural-network forecaster that learns across many related series at once. The unsupervised algorithms^[11] (no labels) cover the rest: K-Means^[17] for clustering or grouping similar records, Random Cut Forest^[18] for anomaly detection on numeric data, IP Insights^[19] for anomalous IP-to-entity associations, and PCA^[20] for dimensionality reduction (shrink the feature count while keeping most of the variance).

Text and image domains

Text has its own built-ins: BlazingText^[21] for word embeddings and text classification, Sequence-to-Sequence for translation and summarization, and LDA or the Neural Topic Model for topic modeling (discover the themes in a document set without labels). Image built-ins are Image Classification, Object Detection^[22] (bounding boxes around objects), and Semantic Segmentation (label every pixel). On exam tasks these compete with the managed services: if a generic image or text task fits Rekognition or Comprehend, that managed service usually wins on effort, and the built-in algorithm is correct only when you must train on your own labeled data.

Pre-trained models: JumpStart and Bedrock

When you want to start from a model that already learned, two paths exist. SageMaker JumpStart^[10] offers pre-trained, open-source models (vision, text, tabular) plus solution templates; you can 'incrementally train and tune these models before deployment' and deploy with one click, so it suits fine-tuning a known model on your data. Bedrock, from the rung above, is the path for large generative foundation models behind a managed API. The difference: JumpStart deploys a model into your account on a SageMaker endpoint you manage; Bedrock keeps the model behind its own serverless API and you never run the infrastructure.

SageMaker built-in algorithms grouped by AWS's own learning-paradigm and data-domain map, plus the two pre-trained-model paths.

Interpretability, cost, and reading the question

Two factors decide modeling questions besides raw accuracy, and ignoring them is how candidates pick the wrong answer: interpretability and cost.

When the prediction must be explained

If a question stresses that a decision has to be justified to a person or a regulator, the most accurate model is not automatically the answer. A loan denial, a medical flag, or any regulated outcome needs an explanation, and a black-box deep network that scores a point higher loses to a model whose reasoning you can show. Two levers help. First, choose an inherently interpretable algorithm: Linear Learner exposes a coefficient per feature, so you can say which inputs drove the prediction. Second, keep a strong model like XGBoost but add SageMaker Clarify^[23], which uses a model-agnostic feature-attribution approach based on SHAP (Shapley values) to 'understand why a model made a prediction' per instance. Either way, the answer that names interpretability when the stem asks for it beats the answer that only maximizes a metric.

When cost and effort are the constraint

The same logic applies to budget and team size. A managed AI service is an API call with no training cost; a built-in algorithm runs on a single right-sized instance; a custom model can demand a GPU fleet and an ML team. When a stem mentions limited ML expertise, a tight timeline, or cost minimization, the correct approach is the lowest rung on the ladder that still meets the accuracy bar, not the most sophisticated one. 'Fastest to build with the least ML expertise' is almost always pointing at a managed service or a built-in algorithm, never at a from-scratch model.

What the question stems look like

The exam phrases these as scenario picks. A few recurring shapes and the right read:

Stem signal	Right approach	Why the obvious distractor is wrong
'transcribe call-center audio', 'detect objects in images', 'extract fields from invoices'	Managed AI service (Transcribe, Rekognition, Textract)	A custom or built-in model is wasted effort for a task a pre-trained API already does.
'predict a numeric value / churn / price from our tabular data'	Supervised tabular built-in (XGBoost, Linear Learner)	A foundation model on Bedrock is the wrong tool for structured prediction.
'forecast demand from historical sales'	DeepAR	Generic regression ignores the time-series structure DeepAR exploits.
'group customers with no labels', 'flag abnormal sensor readings'	K-Means (clustering), Random Cut Forest (anomaly)	Treating it as supervised assumes labels you do not have.
'summarize / answer questions over text', 'generate content'	Foundation model on Bedrock	A built-in NLP algorithm cannot do open-ended generation.
'must explain each decision to auditors'	Interpretable model (Linear Learner) or add Clarify	Choosing the highest-accuracy black box ignores the explainability requirement.
'least ML expertise / fastest / lowest cost'	Lowest rung that fits (managed service, then built-in)	Custom training contradicts the stated effort constraint.

Work every question the same way: read off the problem type and the binding constraint (accuracy, interpretability, cost, effort), then pick the lowest-effort approach that satisfies all of them.

Four modeling approaches, lowest to highest build effort

Decision factor	Managed AI service	Foundation model (Bedrock)	Built-in algorithm / JumpStart	Fully custom model
Examples	Rekognition, Comprehend, Transcribe, Translate, Textract, Personalize, Forecast	Bedrock FMs (Nova/Titan, Claude, Llama, Mistral, Cohere)	XGBoost, Linear Learner, DeepAR; JumpStart pre-trained models	Your own algorithm in a SageMaker training container
Training data you supply	None (pre-trained)	None for base use; some for fine-tuning	Your labeled dataset (less if fine-tuning JumpStart)	Full labeled dataset
Customization	Few/no knobs	Prompting, RAG, fine-tuning	Hyperparameters; fine-tune a pre-trained model	Total control
Infra to manage	None (API call)	None (serverless API)	Training jobs + endpoints you configure	Training jobs + endpoints you configure
Effort and cost	Lowest	Low to medium	Medium	Highest
Use when	Common task, no special accuracy need	Generative / language tasks	Prediction specific to your data	No other approach fits

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Pick the lowest-effort modeling approach that meets the requirements

When choosing how to model a problem, work up a ladder from least to most build effort and stop at the first rung that solves it: a managed AI service, then a foundation model on Bedrock, then a SageMaker built-in algorithm or JumpStart model you train or fine-tune, then a fully custom model. Climbing higher than the problem needs costs more data, time, and money for no benefit, so the cheapest approach that meets the accuracy, interpretability, and effort constraints is the right one.

Trap Reaching for a fully custom model when a managed service or built-in algorithm already handles the task.

Use a managed AI service when a pre-trained API already does the task

For common, well-bounded tasks AWS already ships a pre-trained model behind an API, so there is no training data to collect and no endpoint to run: Amazon Rekognition for image and video, Amazon Transcribe for speech-to-text, Amazon Translate for translation, Amazon Textract for document extraction, Amazon Comprehend for NLP such as entities and sentiment, Amazon Personalize for recommendations, and Amazon Forecast for time-series forecasting. Reach past them to SageMaker only when the prediction is specific to your data or needs accuracy the generic API cannot give.

Trap Standing up a SageMaker training pipeline to do what Comprehend, Rekognition, or Transcribe already does out of the box.

Amazon Comprehend needs no training data for its pre-trained features

Amazon Comprehend is a managed NLP service whose pre-trained features (entity recognition, sentiment, key phrases, language detection) work straight from the API; its docs state 'there is no need for you to provide training data'. That is the signal it belongs on the lowest rung: a standard text-analysis task with no labeled corpus to supply points at Comprehend, not at a custom-trained NLP model.

Reach for a foundation model on Bedrock for generative and open-ended language tasks

When the task is generative or open-ended (summarize, answer questions, draft or generate text), use a foundation model on Amazon Bedrock rather than training one. Bedrock is a fully managed, serverless service giving single-API access to foundation models from several providers, so you manage no infrastructure, and you can use a model as-is, ground it on your data with Knowledge Bases for retrieval-augmented generation, or fine-tune it.

Trap Using a foundation model on Bedrock for a structured tabular prediction like churn or price; that is a supervised job for XGBoost or Linear Learner.

2 questions test this

Build or fine-tune a model only when the prediction is specific to your data

Drop to SageMaker AI when no managed service fits, because the prediction depends on your own data (churn on your customers, a price for your inventory, a defect unique to your product) or needs accuracy a generic API cannot reach. Prefer a built-in algorithm before writing custom training code, and start from a pre-trained model via JumpStart or Bedrock when you can, since fine-tuning needs far less labeled data than training from scratch.

Trap Writing a custom model for a standard task such as sentiment, OCR, or translation that a managed service already covers.

1 question tests this

A retail company wants to build an image classification model to categorize product photos into specific categories. The company has a…

Map the problem type to the algorithm family before naming a service

AWS groups SageMaker built-in algorithms by learning paradigm (supervised, unsupervised) and data domain (text, image), and the exam expects you to read the problem type from the stem and land on the family. Supervised classification or regression on tabular data points to the tabular family; time-series forecasting to DeepAR; clustering to K-Means; anomaly detection to Random Cut Forest; dimensionality reduction to PCA. Naming the paradigm and problem type first keeps you from picking a service that solves a different shape of problem.

XGBoost is the default first reach for tabular classification and regression

For supervised problems on structured tabular data, XGBoost is the strongest out-of-the-box built-in and the usual first choice for both classification (assign a category) and regression (predict a number). It is a gradient-boosted-trees implementation; the same problem can also be served by Linear Learner, K-NN, Factorization Machines, LightGBM, CatBoost, TabTransformer, or AutoGluon-Tabular, but XGBoost is the safe default when the stem just says 'predict from tabular data' with no special twist.

1 question tests this

A healthcare company is building a model to predict patient readmission risk based on clinical and demographic data stored in tabular…

Linear Learner is the interpretable tabular choice

Linear Learner fits a linear function for regression or a linear threshold for classification, and because each feature carries a coefficient you can read which inputs drove a prediction. That makes it the pick when a tabular decision must be explained, even if a tree model like XGBoost scores slightly higher; interpretability, not raw accuracy, is what the question is testing in that case.

Trap Picking XGBoost for its accuracy when the stem requires an explainable, per-feature-attributable model.

1 question tests this

A company's data science team needs to build a model to predict customer churn using tabular data with 50 numeric features. The dataset…

Factorization Machines fits high-dimensional sparse data

Factorization Machines extends a linear model to capture pairwise feature interactions economically in high-dimensional sparse datasets, which is why it suits click-through prediction and recommendation matrices where most feature values are zero. When the stem describes a very wide, sparse feature space rather than a dense tabular table, Factorization Machines beats a plain linear model.

5 questions test this

DeepAR is the built-in for time-series forecasting

Forecasting future values from historical data is its own supervised problem, and SageMaker's built-in for it is DeepAR, a recurrent-neural-network forecaster that trains across many related time series at once to learn shared patterns. A stem about predicting future demand, sales, or load from history points to DeepAR, not to a generic regression algorithm that ignores the time-series structure.

Trap Treating demand forecasting as plain regression with XGBoost, which discards the temporal structure DeepAR exploits.

3 questions test this

K-Means is the built-in for clustering unlabeled data

When you need to group similar records and have no labels (segment customers by behavior, find natural groupings), use the unsupervised K-Means algorithm, which partitions data into clusters whose members are as similar as possible. A stem that groups records with no target column is unsupervised clustering, so treating it as a supervised classification assumes labels you do not have.

Trap Framing an unlabeled grouping task as supervised classification, which assumes labels the data does not contain.

4 questions test this

Random Cut Forest is the built-in for anomaly detection

To flag data points that diverge from an otherwise well-structured pattern (abnormal sensor readings, sudden metric spikes), use Random Cut Forest, the unsupervised SageMaker anomaly-detection algorithm for numeric data. For the narrower case of suspicious IP-address-to-entity associations, IP Insights is the dedicated built-in instead.

4 questions test this

PCA reduces dimensionality while keeping most of the variance

Principal Component Analysis is the unsupervised built-in for dimensionality reduction: it projects data onto a few principal components to cut the number of features while retaining as much variance as possible. Reach for it as a feature-engineering step when a wide dataset has many correlated columns, before feeding a downstream model.

BlazingText handles word embeddings and text classification

BlazingText is the SageMaker built-in for text: a highly optimized Word2vec and text-classification implementation that scales to large corpora. Use it when you must train a text model on your own labeled documents; for a generic NLP task with no custom training need, the managed Amazon Comprehend usually wins on effort, and for open-ended generation you need a Bedrock foundation model instead.

Trap Choosing a built-in text algorithm like BlazingText for open-ended text generation, which only a foundation model can do.

2 questions test this

Use SageMaker built-in image algorithms only when training on your own labels

SageMaker's image built-ins are Image Classification (label the whole image), Object Detection (bounding boxes around objects), and Semantic Segmentation (label every pixel). They compete with Amazon Rekognition, which is pre-trained: pick the built-in only when you must train on your own labeled images for a domain Rekognition does not cover, otherwise the managed service is less effort.

Trap Training a SageMaker Object Detection model for a generic detection task that Amazon Rekognition already does with no training.

JumpStart deploys and fine-tunes pre-trained models on endpoints you manage

SageMaker JumpStart provides pre-trained, open-source models (vision, text, tabular) plus solution templates you can fine-tune and deploy with one click; it suits adapting a known model to your data with far less labeling than training from scratch. The key difference from Bedrock: JumpStart deploys the model onto a SageMaker endpoint in your account that you manage, whereas Bedrock keeps the model behind its own serverless API with no infrastructure for you to run.

Trap Assuming JumpStart is serverless like Bedrock; a JumpStart deployment runs on a SageMaker endpoint you provision and manage.

2 questions test this

Weigh interpretability, not just accuracy, when a decision must be explained

When a prediction has to be justified to a person or a regulator (a loan denial, a medical flag), the most accurate model is not automatically the answer; an explainable one can be the right call even at a small accuracy cost. Two levers: choose an inherently interpretable algorithm such as Linear Learner, or keep a strong model and add SageMaker Clarify, which gives model-agnostic feature attribution. A stem stressing auditability or fairness is testing interpretability over the top metric.

Trap Selecting the highest-accuracy black-box model when the requirement is that each decision be explainable.

1 question tests this

A company's data science team needs to build a model to predict customer churn using tabular data with 50 numeric features. The dataset…

SageMaker Clarify explains predictions with SHAP feature attribution

SageMaker Clarify provides model-agnostic explainability using a feature-attribution approach based on SHAP (Shapley values), assigning each feature an importance for a given prediction so you can answer why the model decided as it did, both after training and per instance at inference. It lets you keep a high-accuracy model like XGBoost and still meet an explainability requirement, rather than swapping to a weaker but inherently interpretable model.

3 questions test this

Let cost and effort point to the lowest rung that meets the accuracy bar

A managed AI service is an API call with no training cost, a built-in algorithm runs on a single right-sized instance, and a custom model can demand a GPU fleet and an ML team. When a stem mentions limited ML expertise, a tight timeline, or cost minimization, the answer is the lowest rung on the ladder that still meets the accuracy requirement, so 'fastest to build with the least ML expertise' almost always points at a managed service or a built-in algorithm.

Trap Choosing a from-scratch custom model when the stem constrains on cost, speed, or scarce ML expertise.

Read the problem type and the binding constraint, then choose

Every modeling question resolves the same way: identify the problem type (classification, regression, forecasting, clustering, anomaly, generation, perception) and the binding constraint (accuracy, interpretability, cost, or effort), then pick the lowest-effort approach that satisfies all of them. The wrong answers are usually a correct approach for a different problem type or one that ignores a stated constraint, so naming both up front filters the distractors.

Autopilot AUTO mode picks ENSEMBLING under 100 MB and HPO over 100 MB

With Mode=AUTO (or unset), SageMaker Autopilot chooses ENSEMBLING for datasets smaller than 100 MB (AutoGluon trains ~10 base models and stacks them — fast and accurate for small data) and HYPERPARAMETER_TUNING for datasets larger than 100 MB (Bayesian optimization under 100 MB, multi-fidelity above, stopping weak trials early). The default objective metric is F1 for binary classification, Accuracy for multiclass, and MSE for regression.

Trap Assuming Autopilot always tunes hyperparameters — under 100 MB it uses ensembling, not HPO, so the trial behavior and cross-validation differ.

10 questions test this

Autopilot sample weights work only in ENSEMBLING mode via SampleWeightAttributeName

To up-weight minority-class rows on an imbalanced dataset, add a sample-weights column and pass its name in SampleWeightAttributeName (TabularJobConfig for CreateAutoMLJobV2). This is supported ONLY in ENSEMBLING training mode (and ignored by the BalancedAccuracy and InferenceLatency objective metrics); the weights then influence the objective metric during training and evaluation.

Trap Configuring SampleWeightAttributeName with HYPERPARAMETER_TUNING mode — sample weights are ignored outside ensembling mode.

5 questions test this

The build-vs-buy ladder

Rung 1: managed AI service

Rung 2: foundation model on Bedrock

Rung 3: built-in algorithm or JumpStart

Rung 4: fully custom model

Pick the built-in algorithm from the problem type

Supervised learning on tabular data

Time series, clustering, anomaly, dimensionality

Text and image domains

Pre-trained models: JumpStart and Bedrock

Interpretability, cost, and reading the question

When the prediction must be explained

When cost and effort are the constraint

What the question stems look like

Four modeling approaches, lowest to highest build effort

Decision tree

Cheat sheet

Also tested in

References