MLA-C01 Cheat Sheet

Apache Parquet and Apache ORC store data column-by-column, so an analytical query or a feature extract that reads a subset of columns prunes the rest and only scans what it needs. That cuts both runtime and Amazon Athena cost, which is billed per terabyte scanned, and the columnar layout compresses well because each column holds one data type. Reach for a row format like CSV or JSON instead when you genuinely read whole records or need human-readable output.

Trap Choosing CSV for a wide analytical table because it is simple; the full-row scan reads every column and inflates the data scanned and the Athena bill.

Row-oriented formats keep each record's fields together, which suits append-heavy streaming ingestion where you write and read whole records. Apache Avro adds compact binary encoding and carries its schema with the data, so producers can add or change fields without breaking older readers, which is schema evolution. Convert the landed data to columnar Parquet later for the analytical reads downstream rather than forcing columnar at ingest.

Trap Forcing Parquet at the streaming ingest point where the schema is still changing; columnar files are awkward to append to and rewrite on every schema change.

SageMaker's built-in algorithms expect training data in the record-oriented application/x-recordio-protobuf format, which streams efficiently through Pipe input mode in batches. When a question shows a built-in algorithm fed by Pipe mode, RecordIO-protobuf is the format being described. For your own scripts and frameworks you are not bound to it and usually keep Parquet, CSV, or the framework's native format.

File mode is the default SageMaker input mode: it copies the entire dataset from S3 to the instance's local disk, then begins training, so the instance must have storage for the whole set and startup time grows with dataset size and file count. It is the simplest correct choice for small datasets. For distributed training, shard with ShardedByS3Key so each instance downloads only its slice rather than the full dataset.

Trap Picking File mode for a dataset larger than the training volume; the up-front full download has nowhere to land and the job fails on disk space.

Fast file mode exposes S3 objects through a POSIX file-system interface but streams their content as the training script reads it, so training starts almost immediately and the dataset no longer has to fit on the EBS volume. It supports random access yet works best on sequential reads, and it accepts S3 prefixes only, not manifest or augmented-manifest files. AWS now positions it as the default streaming choice over the older Pipe mode.

Trap Assuming fast file mode accepts augmented manifest files; it supports S3 prefixes only, so a manifest-driven dataset needs File mode or Pipe mode.

Pipe mode streams S3 data at high concurrency into a named FIFO pipe read by a single process, so like fast file mode it needs only enough local disk for the model artifacts. AWS describes the newer fast file mode as the simpler mechanism that largely replaces it, so Pipe mode stays relevant mainly for its managed sharding and shuffling and for the RecordIO-protobuf path built-in algorithms use.

Amazon FSx for Lustre mounts to the training instance in seconds regardless of dataset size and scales to hundreds of GB/s and millions of IOPS, so it shines when the same large dataset is read repeatedly across epochs and S3 download or re-streaming would dominate. The cost is operational: it requires a VPC and uses a single Availability Zone, which you map to the training subnet to avoid cross-AZ data-transfer charges. For a small or read-once dataset, plain S3 File mode is simpler and cheaper.

Trap Standing up FSx for Lustre and its VPC plumbing for a small or one-off dataset; S3 File mode downloads it in seconds with no networking to configure.

SageMaker can mount an existing Amazon EFS file system to the training instance and start the script in place, which fits data already shared across instances in EFS. The data must already reside in EFS before training and the job must connect to a VPC to reach it. When data sits in S3, stream it with fast file or Pipe mode rather than first copying it into EFS.

A large analytical extract against a transactional primary competes with live traffic and can degrade the application, so point the pull at an Amazon RDS read replica, a DynamoDB export to S3, or an S3 snapshot instead. The replica or export absorbs the heavy scan while the primary keeps serving. This is the recurring right answer whenever a stem describes pulling training data from an operational database under load.

Trap Running the full training extract directly against the RDS primary; the analytical scan steals IOPS and connections from production traffic.

S3 Transfer Acceleration routes uploads through the nearest CloudFront edge location and then over the AWS backbone to the bucket, which raises throughput for large objects or clients far from the bucket Region. It helps when distance or object size is the bottleneck, not when the client is already close to the Region. It does not change how training reads data; it is an ingestion-speed option for getting data into S3.

Trap Enabling Transfer Acceleration for clients in the same Region as the bucket; with no distance to overcome it adds cost without improving throughput.

When an extract or a self-managed data store is throughput-bound on its block storage, EBS Provisioned IOPS SSD volumes (io1/io2) deliver the sustained, consistent IOPS the workload specifies, which general-purpose gp3 may not hold under steady heavy load. io2 also supports higher durability and, with Block Express, very high IOPS ceilings. Use Provisioned IOPS when the requirement is a guaranteed IOPS floor rather than lowest cost.

Amazon Kinesis Data Streams retains records (24 hours by default, extendable up to 365 days) so multiple independent consumers can read the same stream and replay it, and it preserves order within a shard. Reach for it when you need ordering, replay, or several readers, rather than a one-way delivery pipe. Amazon Data Firehose, by contrast, delivers and discards and cannot be re-read with custom logic.

Trap Choosing Amazon Data Firehose when the requirement is replay or multiple independent consumers; Firehose only delivers to a destination and is not a re-readable buffer.

Each Kinesis Data Streams shard sustains writes of 1 MB/s or 1,000 records per second, whichever it hits first, so you scale write throughput by adding shards. A single record's payload can be up to 10 MiB (the data blob plus partition key must stay within 10,485,760 bytes), not 1 MB. Size the shard count to the aggregate ingest rate, and remember the record ceiling is 10 MiB, well above the per-second throughput figure.

Trap Stating the maximum Kinesis record size as 1 MB; the per-shard sustained write rate is 1 MB/s, but a single record can be up to 10 MiB.

Enhanced fan-out (EFO) gives each registered consumer its own dedicated 2 MB/s read throughput per shard via a push model, instead of sharing the standard 2 MB/s per shard across all consumers. The registration limit is 20 registered consumers per stream, not per shard, for standard On-Demand and Provisioned modes. Use EFO when several consumers each need full-rate, low-latency reads; standard polling is cheaper when readers are few.

Trap Claiming enhanced fan-out allows 20 consumers per shard; the limit is 20 registered consumers per stream.

Amazon Data Firehose (formerly Kinesis Data Firehose) buffers records by size or time and delivers them to Amazon S3, Amazon Redshift, or OpenSearch, with optional in-flight conversion to Parquet or ORC, and there is nothing to provision. The trade is added buffering latency and that it is a delivery pipe, not a buffer you read with custom consumers. Choose it when the goal is simply to land a stream in a store with minimal operational overhead.

Trap Reaching for Amazon MSK or self-managed Kafka when you only need buffered delivery to a store; Firehose is serverless and removes broker and shard management.

Amazon MSK runs managed Apache Kafka so teams already invested in Kafka topics, partitions, and the existing consumer ecosystem keep their tooling without operating brokers. It is the right answer when a stem explicitly names Kafka or an existing Kafka estate, not when the requirement is generic streaming that Kinesis or Firehose covers more simply.

Trap Picking Amazon MSK for net-new generic streaming with no Kafka requirement; you take on Kafka's operational model for nothing Kinesis would not handle.

Amazon Managed Service for Apache Flink runs Apache Flink for stateful, sub-second stream processing: windowed aggregations, joins, and on-the-fly feature computation, and it can write the engineered features straight into a SageMaker Feature Store online store. Reach for it when transformation or feature creation must happen in the stream in real time, rather than after the data has landed in S3.

AWS Glue runs serverless Apache Spark with a crawled Data Catalog, so a Glue ETL job joins multiple cataloged sources on a common key at scale without you managing a cluster. It is the default for combining terabyte-scale data from many sources. Amazon EMR runs the same Apache Spark joins on a cluster you control, which is the choice when you need cluster-level tuning or already operate a Spark or Hadoop estate.

Trap Writing a hand-rolled per-record loop or using one oversized instance to join terabytes across sources; the volume calls for distributed Spark on Glue or EMR.

Built-in Glue classifiers cover JSON/CSV/Parquet/Avro but return an UNKNOWN certainty on fixed-width or oddly-delimited data; attach a custom Grok classifier (regex patterns mapping text to field names) for fixed-width or unusual text files, or a custom CSV classifier (specifying delimiter, quote, header, or the Open CSV SerDe for quoted commas). The crawler runs custom classifiers before the built-ins.

Trap Assuming the built-in CSV classifier handles pipe-delimited or fixed-width files it cannot actually parse.

A Glue crawler's schema-change policy governs catalog updates: AddOrUpdateBehavior=MergeNewColumns adds newly discovered columns while preserving existing definitions; UpdateBehavior=LOG records changes without overwriting manual edits (UPDATE_IN_DATABASE is the default, which does overwrite); RecrawlBehavior=CRAWL_NEW_FOLDERS_ONLY only scans new partitions and leaves existing schema untouched; and 'Create a single schema for each S3 path' merges compatible files into one table instead of many.

Trap Leaving UpdateBehavior at UPDATE_IN_DATABASE, so the next crawl overwrites schema corrections data scientists made by hand.

On-demand capacity mode makes Kinesis Data Streams manage shards automatically, accommodating up to double the previous 30-day peak write throughput, which suits highly variable or unpredictable workloads with the least operational overhead. You can switch an existing stream between provisioned and on-demand (up to twice per 24 hours) without disrupting producers or consumers.

Trap Manually resharding a provisioned stream for spiky traffic when switching to on-demand mode removes the capacity-planning burden entirely.

S3 Intelligent-Tiering automatically moves objects between Frequent, Infrequent (after 30 days), and Archive Instant Access (after 90 days) tiers based on actual access, charging no retrieval fees, which makes storage costs predictable for datasets whose access pattern is unpredictable. Optional Archive Access and Deep Archive Access tiers add deeper savings for data untouched for months (a small per-object monitoring fee applies).

Trap Hand-authoring lifecycle transition rules for data whose access pattern is genuinely unknown, where Intelligent-Tiering adapts automatically.

S3 Glacier Instant Retrieval is the lowest-cost class for long-lived data accessed only about once a quarter that still needs millisecond retrieval (e.g. audit or compliance datasets), saving up to ~68% versus S3 Standard-IA with no restore step (it has a 90-day minimum storage duration and higher per-GB retrieval fees). Lifecycle NoncurrentVersionTransition can move older object versions into it while current versions stay in S3 Standard.

Trap Choosing S3 Glacier Flexible or Deep Archive for rarely-accessed data that must still be readable in milliseconds, forcing a multi-hour restore.

Cost-optimize S3 by transitioning objects down the waterfall as access drops: S3 Standard for active data, Standard-IA for infrequent-but-fast access, then Glacier Flexible Retrieval (3-5 hour standard restore) or Deep Archive for cold data, with an expiration action to delete at end of retention. S3 Standard has no minimum storage duration, so short-lived raw data can be expired without a minimum-duration charge (Standard-IA has a 30-day minimum).

Trap Parking data needed within milliseconds in Glacier Flexible Retrieval, whose standard restore takes 3-5 hours.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

A SageMaker AI real-time endpoint is a persistent endpoint that stays provisioned and warm so it answers synchronous requests with consistent low latency, which fits online prediction behind an application. The synchronous InvokeEndpoint call caps the request body at 6 MB and the model must respond within 60 seconds. Because the instances run continuously you pay for them even during idle, so it suits sustained traffic rather than occasional bursts.

Trap Choosing a real-time endpoint for a payload over 6 MB or inference that runs minutes; it exceeds the synchronous limits and asynchronous inference is the right option.

Serverless inference launches compute on demand and scales to zero when no requests arrive, so you pay only while requests are processed, which fits unpredictable or intermittent traffic with idle periods. You configure memory from 1024 MB to 6144 MB instead of choosing an instance type. The tradeoff is a cold start, the extra latency to spin compute back up after idle, which you measure with the OverheadLatency metric and reduce with Provisioned Concurrency.

Trap Keeping a real-time endpoint running for traffic that arrives in occasional bursts, paying for idle instances when serverless would scale to zero.

Serverless inference excludes several real-time features: GPUs, multi-model endpoints, VPC configuration, network isolation, data capture, multiple production variants, Model Monitor, and inference pipelines. A workload that needs any of these cannot run serverless. The most common case is a deep-learning model that needs a GPU, which forces a real-time or asynchronous endpoint instead.

Trap Selecting serverless inference when the scenario mentions a GPU or Model Monitor, neither of which serverless supports.

Asynchronous inference queues each request and processes it in the background, which lets it accept payloads up to 1 GB and run inference for up to one hour, well past the synchronous 6 MB and 60-second limits. The caller submits a request pointing at an S3 input and gets a location where the result will be written; SageMaker AI writes the prediction to S3 and can fire an SNS notification on completion. Like serverless, an async endpoint can scale to zero between bursts, which suits high-resolution vision or large-document NLP.

Trap Reaching for batch transform when each large request needs its own near-real-time answer back; batch transform is for scoring a whole dataset, not individual queued requests.

Batch transform is the only inference option with no persistent endpoint: a transform job reads a dataset from S3, spins up instances, distributes records across them, writes one .out prediction file per input file back to S3, then tears down. The per-record payload is set by MaxPayloadInMB, which must not exceed 100 MB. Nothing is left running afterward, so it is the cheapest answer when the task is a fixed offline scoring run rather than live serving.

Trap Standing up a persistent endpoint to score a fixed dataset once, paying to keep it running when batch transform leaves nothing behind.

A multi-model endpoint (MME) hosts a large number of models on one shared serving container and one fleet, loading each model into memory on first request (named with the TargetModel header) and evicting the least-recently-used models when memory fills. It cuts cost sharply for many similar models, the classic per-customer or per-region SaaS fleet, and supports CPU- and GPU-backed instances. All models must use the same ML framework because they share one container.

Trap Putting models that need different frameworks on an MME; they all share one container, so different-framework models require a multi-container endpoint.

Because an MME loads models on demand rather than up front, the first request for a model not currently in the container's memory waits while SageMaker AI downloads it from S3 and loads it. An unloaded model stays on the instance's storage volume so it can reload without re-downloading. MME therefore works best when the application tolerates occasional cold-start latency on infrequently used models and reserves dedicated single-model endpoints for high-traffic or strict-latency models.

Trap Hosting a high-TPS, strict-latency model on a shared MME where it competes for memory; a dedicated single-model endpoint gives predictable latency.

A multi-container endpoint hosts up to 15 distinct containers on a single endpoint, which is how you serve models that use different frameworks together. You can invoke one container directly with the TargetContainerHostname header, or chain the containers as an inference pipeline so each container's output feeds the next. This is the different-framework counterpart to an MME, which can only host same-framework models in its one shared container.

Trap Using a multi-model endpoint when the requirement is models in different frameworks behind one endpoint; that case needs a multi-container endpoint.

An inference pipeline is a SageMaker AI model made of a linear sequence of 2 to 15 containers, where the first container handles the request and each intermediate response feeds the next container. Because the containers are co-located on the same instances, feature processing and prediction run with low latency, often reusing the Spark ML or scikit-learn container built during training. A pipeline can serve real-time predictions or run inside a batch transform job.

Trap Standing up separate endpoints and network calls for preprocessing and prediction when an inference pipeline co-locates them on one set of instances for lower latency.

SageMaker AI ships managed containers for its built-in algorithms and prebuilt Deep Learning Containers for frameworks such as TensorFlow, PyTorch, and MXNet, so a model that fits a supported framework needs nothing built. You bring your own container (BYOC) only when you need a custom runtime, an unusual dependency, or your own serving stack: package the code into a Docker image that honors the SageMaker AI serving contract and push it to Amazon ECR.

Trap Building a custom container for a model that a provided framework container already supports, taking on maintenance for no benefit.

A bring-your-own inference container must implement the SageMaker AI serving contract: it responds to POST /invocations with predictions and to GET /ping for health checks, and the image is stored in Amazon ECR. Honoring this contract is what lets SageMaker AI host any custom image the same way it hosts a provided one.

CPU instances such as the c and m families are the cheapest inference compute and handle classical models, tree ensembles, and lightweight workloads well. They are the default choice unless the model genuinely needs hardware acceleration, so paying for a GPU for a small tabular model is wasted cost.

Trap Provisioning a GPU instance for a lightweight or classical model that runs fine and far cheaper on CPU.

GPU instances in the g and p families provide the parallel matrix math that deep neural networks need, so a large vision or language model that is too slow on CPU belongs on a GPU. The g family targets cost-effective inference and the p family targets the heaviest training and inference, so match the family to the model's size and throughput need.

AWS Inferentia, the inf1 and inf2 instances programmed through the AWS Neuron SDK, is purpose-built for deep-learning inference and often beats general-purpose GPUs on price-performance once a model is compiled for it. Reach for Inferentia when the goal is the lowest inference cost per throughput at scale, after compiling the model with the Neuron toolchain.

Trap Assuming a model runs on Inferentia unchanged; it must first be compiled with the Neuron SDK to target the inf1/inf2 hardware.

SageMaker Neo compiles a trained model into a hardware-optimized form for a specific target and ships a small-footprint runtime, giving faster inference and a smaller package without retraining the model. It compiles models from frameworks such as PyTorch, TensorFlow, MXNet, and ONNX for cloud instances (including Inferentia) and for edge devices on ARM, Intel, Nvidia, and similar processors, and can quantize parameters to INT8 or FP16. When inference must run on a resource-limited edge device with no reliable network, Neo is the deployment answer rather than a cloud endpoint.

Trap Routing every prediction from a disconnected edge device back to a cloud endpoint when Neo can compile the model to run on the device itself.

SageMaker Inference Recommender runs load tests across candidate instance types and reports latency, throughput, and cost, so the instance choice for an endpoint is measured rather than guessed. Reach for it when a scenario asks which instance type to deploy a model on and the answer is not obvious from the model's size alone.

Among endpoint types, serverless inference and asynchronous inference both scale their compute to zero during idle periods so you stop paying when no requests arrive, while a real-time endpoint stays provisioned and bills continuously. This is why a steady-traffic model uses real-time and an intermittent one uses serverless or async: the cost model follows the traffic pattern.

Trap Assuming a standard real-time endpoint scales to zero on idle; only serverless and asynchronous endpoints do, so an idle real-time endpoint keeps billing.

Asynchronous inference and batch transform both handle large or slow inference, but they differ in shape: async queues individual requests that arrive over time and returns a per-request answer to S3, while batch transform runs one job over an entire dataset with no persistent endpoint. Pick async when callers submit requests and need each answer back; pick batch transform when the task is to score a fixed dataset in one offline run.

SageMaker Batch Transform partitions S3 objects by key and maps whole objects to instances, so a single input file is processed by exactly one instance while the rest sit idle no matter how many you provision. Split the data into at least as many S3 objects (under a common prefix) as instances to distribute the work in parallel.

Trap Adding more instances to a one-file job — the extra instances stay idle because one object can only map to one instance.

For batch transform, SplitType=Line breaks input on newline boundaries into records, BatchStrategy=MultiRecord packs as many records as fit per request up to MaxPayloadInMB (default 6 MB) while BatchStrategy=SingleRecord sends one record per request, and MaxConcurrentTransforms sets parallel requests per instance. AWS requires MaxPayloadInMB be no greater than 100 MB, and if MaxConcurrentTransforms is set, MaxConcurrentTransforms × MaxPayloadInMB must also not exceed 100 MB.

Trap Setting MaxConcurrentTransforms × MaxPayloadInMB above 100 MB — the job configuration is rejected.

Batch transform's DataProcessing parameter filters columns with JSONPath: InputFilter selects which columns reach the model (e.g. $[1:] to exclude a leading ID column), JoinSource=Input joins the original record back to the prediction, and OutputFilter chooses what lands in the output file. This carries a passthrough key like a customer ID alongside predictions without feeding it to the model.

AWS Lambda can serve lightweight ML inference with the model on an EFS mount or baked into an ECR container image, and CPU scales in proportion to memory (one vCPU at 1,769 MB, up to 6 vCPUs near the 10,240 MB maximum). Because loading a model can take tens of seconds, put the load outside the handler so it runs during init, and enable provisioned concurrency on a version/alias to pre-initialize environments and eliminate cold-start latency.

Trap Loading the model inside the handler — every cold start pays the full load time on the first request.

A Lambda function must be attached to the EFS VPC (use subnets in at least two Availability Zones for resilience), EFS must have a mount target in every AZ the function uses, an access point connects the function (you can't mount the file-system root directly), and the security groups must allow NFS traffic on port 2049 between the function and the mount targets. A missing 2049 rule or absent mount target shows up as connection timeouts, often only when the function scales out.

Trap Granting the elasticfilesystem IAM permissions but leaving port 2049 blocked in the security group — the mount still times out.

An ECR lifecycle policy expires images automatically with no custom code: rules use tagStatus (tagged/untagged) plus tagPatternList (e.g. prod*) and countType=imageCountMoreThan to keep the N most recent matching images, or countType=sinceImagePushed to expire images older than a set number of days. Use the lifecycle-policy preview to see what a rule would delete before applying it.

Trap Combining tagPatternList and tagPrefixList in one rule — a rule may specify only one of them (both may only be used when tagStatus is tagged).

ECR basic scanning uses AWS-native technology to scan for operating-system package vulnerabilities on push (or manually); ECR enhanced scanning integrates with Amazon Inspector to continuously re-scan for both operating-system and programming-language package vulnerabilities as new CVEs appear, and Inspector maps images to the ECS tasks and EKS pods running them. Enhanced scanning emits an event to EventBridge, which you can route to SNS to alert on critical/high severity.

Trap Relying on basic scan-on-push when the requirement is continuous monitoring — basic scanning does not re-scan for newly disclosed CVEs.

An ECR pull-through cache rule mirrors images from an upstream registry (e.g. Docker Hub) into your private ECR and keeps them synced (checking upstream at most once per 24 hours per tag); after the first cached pull, subsequent pulls are served from your private registry so they no longer contact the upstream. For authenticated upstreams like Docker Hub, store credentials in a Secrets Manager secret whose name uses the ecr-pullthroughcache/ prefix and point the EKS manifests at the ECR registry URI.

Data drift (covariate shift) means the live input feature distribution moved away from the training distribution, and you can detect it by comparing live feature statistics to a training baseline without knowing whether the predictions were right. Concept drift means the relationship between inputs and the correct label changed, so the same inputs now imply a different answer, and you can only catch it by comparing predictions against real outcomes and watching accuracy fall. The distinction decides which monitor can even see the problem.

Trap Assuming an input-statistics monitor will catch concept drift; if the inputs look unchanged but the input-to-label rule moved, only ground-truth comparison reveals it.

Data Capture is the prerequisite for SageMaker Model Monitor: you turn it on in the endpoint configuration for a real-time endpoint, or in the batch transform job for batch monitoring, and SageMaker AI logs each inference request input and prediction output to S3. You set a sampling percentage rather than capturing every request, and on a persistent real-time endpoint you can change the sampling frequency or toggle capture over time. Model Monitor automatically parses this captured data and compares it to your baseline, so a monitoring schedule with capture disabled has nothing to analyze.

Trap Creating a monitoring schedule but never enabling Data Capture on the endpoint, so the scheduled jobs run against no captured data.

SageMaker Model Monitor supports four and only four monitor types: Data quality (drift in input feature statistics), Model quality (drift in prediction metrics like accuracy), Bias drift, and Feature attribution drift. Bias drift and Feature attribution drift are the two powered by SageMaker Clarify. Knowing the set lets you eliminate distractors that invent a fifth type or attribute one to the wrong service.

All four monitor types share the same loop: compute a baseline of metrics and constraints from the training dataset, run a monitoring schedule that recomputes those metrics on captured live data, flag any value outside the baseline constraints as a violation, and emit metrics to CloudWatch where an alarm notifies you. Learning the loop once covers all four; only the metric being computed differs by type.

Model Monitor builds its baseline from the dataset that was used to train the model, computing reference metrics and suggesting constraints; live predictions are then compared against those constraints and anything outside is reported as a violation. Baselining against training data is what makes a deviation meaningful, because it measures how far production has moved from what the model learned.

Trap Baselining on recent production data instead of the training set, which hides the very drift you are trying to detect by treating the drifted state as normal.

The Model quality monitor grades predictions against real outcomes, so it requires ground-truth labels merged with the captured predictions; this is how concept drift, an accuracy decay, surfaces. Labels often arrive late or never, so when they are unavailable, fall back to data-quality or feature-attribution drift monitoring, which need only the inputs and predictions.

Trap Choosing Model quality monitoring in a scenario with no ground-truth labels; without outcomes you cannot grade predictions, so a data-quality or feature-attribution monitor is the answer.

The Data quality monitor recomputes statistics on the captured input features and compares them to the training baseline, making it the direct detector for data drift. It needs only the inputs, no labels, so it runs continuously and cheaply and is the right pick when a question says the incoming data looks different from training and never mentions outcomes.

Bias drift monitoring recomputes bias metrics such as DPPL on a rolling window of live data and alerts when they leave an allowed range, while Feature attribution drift uses NDCG over Clarify's SHAP attributions to detect when the importance ranking of features diverges from the baseline. Both are SageMaker Clarify integrated into Model Monitor, which is what makes them the over-time, on-a-live-endpoint detectors rather than point-in-time scans.

A standalone SageMaker Clarify processing job is point-in-time detection: it measures bias on a dataset or trained model, or produces a SHAP explanation, once. Clarify running inside Model Monitor on a schedule is the ongoing drift detector that watches a live endpoint over time. Match the answer to whether the scenario is a pre-launch check or a production-over-time concern.

Trap Reaching for a one-off Clarify job when the scenario says bias is changing over time in production; ongoing bias monitoring is the Bias drift monitor, not point-in-time detection.

Model Monitor calculates statistics and metrics on tabular data only. It can still monitor an image classifier by watching its tabular label output, but it cannot monitor the raw image pixels going in, so to monitor non-tabular inputs you monitor an engineered tabular feature representation instead. This limit appears as a distractor whenever a question proposes monitoring raw images, audio, or text directly.

Trap Proposing Model Monitor to watch raw image or text inputs directly; it computes metrics on tabular data only, so monitor a tabular feature representation.

Model Monitor works on an endpoint that hosts a single model; it does not support monitoring a multi-model endpoint, where many models share one container behind one endpoint. A scenario that needs both MME density and built-in drift monitoring has a conflict the exam expects you to spot.

Trap Assuming a multi-model endpoint can be watched by Model Monitor; MME is unsupported, so the design must use single-model endpoints to get built-in monitoring.

Deploy the old and new model as two production variants behind one endpoint and split live traffic by setting each variant's weight; two variants with equal weight each take 50% of requests. Both serve real users, so you compare their CloudWatch metrics to pick the winner. This is the real-traffic comparison answer, distinct from a shadow test, because the candidate actually responds to a slice of users.

Once an A/B test names a winner, call UpdateEndpointWeightsAndCapacities to change the variant weights, which reroutes traffic with no endpoint downtime: ramp the new variant 50/50, then 75/25, then 100/0, then delete the loser. There is no need to recreate or update the endpoint itself to move traffic.

Trap Tearing down and recreating the endpoint to shift traffic between variants; UpdateEndpointWeightsAndCapacities reweights live with zero downtime.

To bypass the weighted random split and send a request to one named production variant, pass the TargetVariant parameter on InvokeEndpoint; SageMaker AI then routes that request to the variant you named and the targeting overrides the configured traffic distribution. This is how you smoke-test or directly compare a single variant without changing weights.

A shadow test deploys the candidate as a shadow variant and routes a copy of live inference requests to it in real time within the same endpoint, but only the production variant's responses are returned to the calling application. The shadow's responses are discarded or logged for offline comparison, so you measure real latency, error rate, and behavior on production traffic without any user receiving the candidate's output. Reach for it when the requirement is to validate on live traffic with no chance of affecting users.

Trap Using an A/B test when the requirement is zero user impact; A/B serves the candidate to a slice of real users, so only a shadow test withholds the candidate's responses.

Shadow tests do not work with serverless inference, asynchronous inference, Marketplace containers, multi-container endpoints, multi-model endpoints, or Inferentia (Inf1) instances; requesting a shadow test on such an endpoint fails validation. When a scenario combines one of these features with a shadow-test requirement, the design has to change.

To turn drift detection into action, connect the Model Monitor CloudWatch alarm to an Amazon EventBridge rule that starts a retraining workflow, typically a SageMaker Pipelines execution or a Step Functions state machine, which retrains on fresh data and registers the new model version for approval. This closes the loop so a threshold breach automatically launches retraining rather than waiting on a human to notice.

An automated retraining loop should register each new model version in the SageMaker Model Registry, where versions start as PendingManualApproval and a transition to Approved can initiate the CI/CD deployment. This adds a controlled gate so a freshly retrained model is reviewed or auto-approved before it replaces the production variant, rather than deploying blind on every drift event.

The AWS Well-Architected Machine Learning Lens treats a deployed model as a perishable asset and makes continuous monitoring of both data quality and model quality, plus an automated response when either degrades, a core operational practice. When a question frames monitoring as a design-principle or best-practice choice, the ML Lens monitoring guidance is the reference being tested.

To break down endpoint response time, watch two AWS/SageMaker invocation metrics: ModelLatency is the interval a model takes to respond to a SageMaker Runtime request — it includes the local communication to send the request to and fetch the response from the model container, plus the time to run the inference in the container. OverheadLatency is the extra time SageMaker adds, measured from when SageMaker receives the request until it returns the response to the client, minus ModelLatency. Both are published in microseconds, so a 500 ms threshold is 500000.

Trap Reading ModelLatency in milliseconds and setting the alarm threshold to 500 instead of 500000.

To ignore brief spikes, use an 'M out of N' alarm: set EvaluationPeriods to N (the window of periods examined) and DatapointsToAlarm to M (how many must breach). '2 of 3' or '3 of 5' fires only on sustained breaches. Because SageMaker latency metrics are in microseconds, convert the threshold (500 ms -> 500000).

Trap Treating EvaluationPeriods and DatapointsToAlarm as equal — that demands every period breach, defeating the noise tolerance.

For fast scale-out — especially generative-AI endpoints with long, streaming requests — target-track on the high-resolution predefined metric SageMakerVariantConcurrentRequestsPerModelHighResolution (CloudWatch metric ConcurrentRequestsPerModel), which counts the simultaneous requests a model container handles, including requests queued inside the container. It emits data every 10 seconds, versus the standard InvocationsPerInstance metric that emits once per minute, so the policy scales out much more quickly on rising concurrent traffic. (Scale-in still happens at standard speed.)

Trap Using SageMakerVariantInvocationsPerInstance for a bursty gen-AI endpoint — its one-minute resolution detects spikes too late.

In Clarify bias monitoring a metric value (e.g. DPPL) closer to zero is more balanced. You specify an allowed range A (for example (-0.1, 0.1)) the metric should stay within during deployment. To stay robust on small windows, Clarify builds a Normal Bootstrap Interval C around the computed value; it interprets an overlap of C with A as 'the live bias is likely within the allowed range,' and raises a bias_drift_check alert only when C and A are disjoint (Clarify is confident the metric is outside the allowed range). constraint_violations.json records the facet, facet_value, metric short code, and check type.

Trap Assuming a value numerically near zero is safe — if its confidence interval falls entirely outside the allowed range, it still violates.

DefaultModelMonitor.suggest_baseline() runs a Deequ-on-Spark job (the sagemaker-model-monitor-analyzer container) on the training data that outputs statistics.json (per-feature stats) and constraints.json (suggested constraints). Data drift is the baseline_drift_check, which fires when the distribution distance between current and baseline data exceeds monitoring_config.comparison_threshold. To make drift detection less sensitive, raise that threshold in constraints.json and pass the modified file to the monitoring schedule; violations then appear in constraint_violations.json.

Trap Deleting or re-running the baseline to quiet false positives instead of just raising monitoring_config.comparison_threshold in constraints.json.