MLA-C02 sample questions — 25 answered and explained

S3 request-rate scaling: 503 Slow Down means too many requests per prefix; small files multiply requests.

Amazon S3 supports a high request rate per partitioned prefix (thousands of writes per second) and scales as you add prefixes. A job that sends millions of small PUTs into one prefix exceeds that rate and receives 503 Slow Down. Two complementary fixes: spread writes across more prefixes, and reduce the number of requests by writing fewer, larger files, which also helps training jobs that read the data. Transfer Acceleration and Versioning do not change request limits, and backoff retries only absorb throttling without fixing its cause or the small-file reads.

1. Read the error: 503 Slow Down is S3 throttling request rate per prefix.
2. Spread the requests across multiple prefixes.
3. Cut the request count by writing larger files.
4. Reject options that only retry, target network distance or keep the request count.

Exam tip: 503 Slow Down: spread across prefixes and write fewer, bigger files.

Amazon Data Firehose is the managed, no-consumer-code path for delivering streaming data to S3.

When data only needs to land in S3 with minutes of latency and no processing, Amazon Data Firehose is the least-effort option: producers send records, Firehose buffers by size or time and writes objects to S3. A Kinesis data stream with a KCL consumer, MSK with a connector, or a Flink application can all reach S3, but each adds code or infrastructure to run.

1. Note the requirements: S3 destination, minutes of latency, no transformation.
2. Note the constraint: no consumer applications to build or operate.
3. Eliminate options that need custom consumers or clusters.
4. Choose Amazon Data Firehose.

Exam tip: Stream to S3 with no code and minutes of latency: Amazon Data Firehose.

Kinesis Data Streams for multiple independent consumers and replay: enhanced fan-out plus retention.

Kinesis Data Streams keeps records for a retention period (24 hours by default, extendable) so consumers can re-read them, and enhanced fan-out gives each registered consumer a dedicated read pipe per shard with push delivery and low latency. The shared-throughput near-twin keeps seven days of data but makes the three applications split each shard's read capacity and poll with higher latency. Firehose cannot be read by applications, and SQS deletes messages after processing.

1. List the requirements: several consumers, dedicated throughput, low latency, seven-day replay.
2. Recall that Kinesis retention can be extended beyond the 24-hour default.
3. Recall that enhanced fan-out gives each consumer its own throughput.
4. Eliminate delivery-only and delete-on-consume services.

Exam tip: Many consumers each at full speed plus replay: Kinesis Data Streams with enhanced fan-out and longer retention.

Firehose record format conversion: JSON input, Glue Data Catalog schema, Parquet or ORC output.

Firehose can convert records to Parquet or ORC, but only from JSON input, using a Glue table for the schema. CSV records therefore need a Lambda data transformation to JSON before the conversion step. Choosing a JSON deserializer without the transform fails on CSV input; dynamic partitioning and file extensions do not change the format; and building Parquet inside Lambda breaks because Firehose concatenates records into its own objects.

1. Note the input: CSV records.
2. Recall that Firehose format conversion takes JSON input and a Glue schema.
3. Add a Lambda transform to bridge CSV to JSON.
4. Reject options that rename files or build Parquet outside the converter.

Exam tip: Firehose to Parquet: JSON in, Glue schema, and a Lambda transform first if the source is not JSON.

Firehose dynamic partitioning writes records to S3 prefixes derived from fields inside each record.

Plain Firehose prefixes can use timestamp namespaces, which group by delivery time. To group by a value inside the record, enable dynamic partitioning and extract the key with inline JSON parsing (or a Lambda function), then reference it in the S3 prefix. Glue table partitions describe existing data, and buffer settings only change object size and timing.

1. Identify the need: group objects by a field in the payload.
2. Recall that timestamp namespaces only group by time.
3. Recall dynamic partitioning with inline JSON parsing.
4. Choose dynamic partitioning keyed on customer_id.

Exam tip: Partition S3 output by a field in the record: Firehose dynamic partitioning.

Columnar formats (Parquet, ORC) suit analytical reads of a few columns; row formats (CSV, JSON, Avro) suit record-at-a-time access.

Athena can query all four formats, so the deciding factor is cost, which Athena bills by bytes scanned. A columnar format such as Apache Parquet stores each column together, so readers fetch just the 10 columns they need and use column statistics to skip data. CSV, JSON Lines and Avro store whole records together, so every query scans all 300 columns and costs many times more.

1. Note the access pattern: a few columns out of many, plus filters.
2. Note the cost model: Athena bills by data scanned.
3. Compare formats on bytes scanned: row formats read every column.
4. Choose compressed Parquet.

Exam tip: Few columns out of many, billed by data scanned: Parquet is the most cost-effective format.

Built-in algorithm CSV input conventions: target in the first column, no header.

SageMaker AI built-in algorithms that accept text/csv, including XGBoost, assume the target variable is the first column and that the file has no header record. With the target last, the algorithm learns to predict whatever feature is in the first column, which matches the symptom. Both parts of the layout have to be right.

1. Recall the CSV convention for built-in XGBoost.
2. Check the column position: the target goes first.
3. Check the header: there must be none.
4. Pick the option that gets both right.

Exam tip: Built-in algorithm CSV: label first, no header.

Unsupervised anomaly detection finds unusual data points when no labeled examples of the anomaly exist.

The deciding detail is the absence of labels. Random Cut Forest learns the structure of normal data and gives each point an anomaly score, so engineers can review the highest scores. XGBoost and k-NN classification both need labeled classes, and DeepAR is a forecasting algorithm rather than an anomaly scorer.

1. Note the goal: flag unusual readings.
2. Note the data: no labels.
3. Choose an unsupervised anomaly-scoring algorithm.
4. Reject supervised classifiers and forecasters.

Exam tip: Anomalies without labels: Random Cut Forest.

Hosting choice is part of the build-versus-managed trade-off: the same custom model can run on self-managed endpoints or on a serverless managed service.

Three facts combine. The model is a fine-tuned Llama, an architecture that Bedrock Custom Model Import accepts from Hugging Face-format weights in S3. Traffic is sporadic, so on-demand hosting that scales to zero when idle beats an always-on endpoint on cost, and the stem accepts the cold start that follows an idle period; the real-time endpoint with a minimum of one instance is the workable but more expensive option. And SageMaker Serverless Inference, the obvious low-cost serverless choice, has no GPU support, which a 70B model needs. Provisioned Throughput is committed capacity for the base model without the custom weights.

1. List constraints: custom weights, sporadic traffic, cost is the deciding dimension.
2. Check GPU needs: a 70B model needs accelerators.
3. Remove options that cannot use GPUs or cannot load the custom weights.
4. Compare what remains on idle cost: choose Bedrock Custom Model Import over an always-on endpoint.

Exam tip: Custom weights of a supported open architecture plus spiky traffic: Bedrock Custom Model Import, not an always-on endpoint.

A managed AI service with a pre-trained model is the lowest-effort choice when its built-in capability already matches the business need.

Sentiment in four classes (positive, negative, neutral, mixed) is exactly what Amazon Comprehend's pre-trained DetectSentiment returns. No labels, no training and no ML staff are needed. Every other option trains or customizes a model, which needs labeled data the retailer lacks.

1. Check whether a managed AI service already does the task.
2. Note the constraints: no labels, no data scientists, short deadline.
3. Choose the pre-trained API.
4. Reject options that need training data.

Exam tip: If a pre-trained AI service already solves the task, use it before building a model.

Hybrid search in Amazon Bedrock Knowledge Bases combines semantic vector search with keyword search over the raw text.

Embeddings capture meaning well but are weak at exact strings such as part numbers and SKUs, so a semantic-only search returns similar-sounding parts. Setting the search type to HYBRID adds text matching to the vector search while keeping semantic matching for descriptive questions. It is supported for Amazon RDS, OpenSearch Serverless and MongoDB vector stores with a filterable text field. More results or query decomposition do not change how relevance is computed.

1. Diagnose the symptom: conceptually similar but wrong documents.
2. Identify the cause: exact identifiers such as part numbers are lost in semantic matching.
3. Add keyword matching to the search: hybrid search type.
4. Confirm the vector store supports hybrid search.

Exam tip: Exact codes and identifiers getting lost in semantic search: switch to hybrid search.

Vector store choice for a knowledge base depends on feature support (hybrid search, filters, graph) as well as storage and query cost.

The mandatory requirement is hybrid retrieval. Bedrock supports hybrid search for Amazon RDS (Aurora), OpenSearch Serverless and MongoDB vector stores that have a filterable text field; other stores fall back to semantic search. S3 Vectors fits the cost profile and is the tempting answer, but it cannot meet the requirement. A reranker cannot recover chunks that retrieval never returned, and GraphRAG serves a different kind of question. When a cheaper store lacks a mandatory feature, cost is secondary.

1. Separate the mandatory requirement (hybrid search) from the preference (cost).
2. Recall which knowledge base vector stores support hybrid search.
3. Eliminate stores without it, even if cheaper.
4. Check that workarounds such as reranking cannot add missing recall.

Exam tip: Mandatory keyword plus semantic retrieval rules out S3 Vectors; reranking cannot fix missed recall.

GraphRAG combines vector retrieval with a knowledge graph so that answers can follow relationships between entities across documents.

The question is multi-hop: component to module, supplier to component, recall to supplier, across different documents. Plain vector retrieval finds chunks similar to the question but does not connect entities. A knowledge base backed by Amazon Neptune Analytics with GraphRAG extracts entities and relationships and uses them during retrieval. More chunks, hybrid search or Kendra each solve a different retrieval problem.

1. Recognise the question type: several linked facts in different documents.
2. Note why vector similarity alone falls short: it does not link entities.
3. Choose a graph-based retrieval pattern.
4. Reject options that only change how many or which chunks match.

Exam tip: Multi-hop questions across related entities: GraphRAG.

Multi-model endpoints host many same-framework models on shared instances and load them on demand.

Thousands of models, one framework, infrequent access and tolerance for cold-start latency are the textbook signals for a multi-model endpoint. Callers name the model with the TargetModel parameter; SageMaker AI downloads it from S3, caches it and unloads idle models when memory runs short.

1. Count the models and check they share a framework/container.
2. Check access frequency and cold-start tolerance.
3. Choose a multi-model endpoint for many similar, mostly idle models.

Exam tip: Many similar models, one container, occasional use: multi-model endpoint.

Multi-model endpoints time-share memory; heavy hitters belong elsewhere and memory sizing controls unloads.

Two problems need two fixes. Slow responses for regularly used models come from cache eviction: when memory is full, SageMaker AI unloads models and must reload them, so more memory per instance keeps more models warm. The flagship store breaks the multi-model pattern, which works best when models have similar traffic; AWS recommends dedicated endpoints for high-TPS or strict-latency models.

1. Link "frequent unloads" to instance memory pressure.
2. Link the single high-TPS, low-latency model to a dedicated endpoint.
3. Reject options based on the wrong invocation parameter or unsupported endpoint types.

Exam tip: Unloads mean memory pressure; one hot model means a dedicated endpoint.

A serial inference pipeline chains containers behind one endpoint call.

The requirement is sequential processing through different containers with a single call. Two options can deliver one call: a Step Functions workflow over three endpoints, and a serial inference pipeline. The serial inference pipeline (a PipelineModel) hosts 2 to 15 containers together behind one endpoint and pipes each response into the next container on the same instance, so there is one endpoint to run and no extra network hops. Step Functions works but means three endpoints plus a workflow to operate. Multi-container Direct mode calls one container at a time.

1. Notice that every request must pass through all containers in order.
2. List the options that give the caller one call: Step Functions over endpoints, or a serial inference pipeline.
3. Choose the serial inference pipeline: one endpoint, no orchestration layer to operate.

Exam tip: Containers in sequence per request: serial inference pipeline.

Multi-container endpoints in Direct mode host different containers and route by TargetContainerHostname.

The models need different containers and are called independently. A multi-container endpoint with Direct invocation hosts them on shared instances, and each request names its container. A multi-model endpoint serves every model from one shared container and suits many similar models, so these three framework containers would have to be repackaged; Serial mode chains containers; production variants run on separate instances.

1. Check whether the models already share one serving container (they ship in three).
2. Check whether requests need one model or a chain (one).
3. Choose a multi-container endpoint with Direct invocation.

Exam tip: Different frameworks, one model per call, one endpoint: multi-container, Direct mode.

Inference components allocate resources per model on a shared endpoint and scale each one independently, down to zero.

Three needs combine: per-model GPU allocation on shared instances, independent scaling, and releasing resources when idle. Inference components declare compute requirements per model (for example NumberOfAcceleratorDevicesRequired) and scale a CopyCount through Application Auto Scaling, including to zero. The alternatives share hardware without per-model allocation, or do not share hardware at all.

1. Note the need for GPU allocation per model on shared instances.
2. Note independent scaling per model, including to zero.
3. Recognise that only inference components provide both.

Exam tip: Several FMs on one endpoint with their own resources and scaling: inference components.

Amazon Bedrock on-demand inference is the pay-per-token, no-infrastructure FM option.

Two options avoid instance choices and endpoint management: Bedrock on-demand inference and Bedrock Provisioned Throughput. Provisioned Throughput bills reserved model units by the hour and pays off only for steady, heavy use; on-demand bills per token, so low and unpredictable traffic costs least there. JumpStart and Bedrock Marketplace deploy to endpoints whose instances the team chooses and pays for per instance-hour.

1. List the constraints: no instance choices, no endpoints to manage.
2. Eliminate endpoint-based deployments (JumpStart, Bedrock Marketplace).
3. Compare the two Bedrock options on cost for low, unpredictable traffic: per-token on-demand beats hourly Provisioned Throughput.

Exam tip: Low, unpredictable FM traffic with nothing to provision: Bedrock on-demand is cheapest.

SageMaker Clarify bias drift monitoring tracks post-training bias metrics for a facet on live traffic against a baseline.

The problem is an outcome gap between groups in production, which is bias drift. A bias drift monitor runs on a schedule against captured traffic, computes post-training bias metrics for the configured facet (age group) and compares them with baseline constraints. Pre-training bias jobs only look at the static training set, and data quality or attribution drift watch different signals.

1. Identify the signal: approval rates differ between age groups.
2. Recognise this as a post-training bias metric on live data.
3. Choose the monitor that recomputes it on a schedule: bias drift.

Exam tip: Outcome gaps between groups appearing in production = Clarify bias drift monitor.

A drift-triggered retraining loop: Model Monitor -> CloudWatch metric alarm -> EventBridge rule -> SageMaker Pipelines execution.

The monitor already detects drift; the work is wiring its result to the pipeline with the least to build and maintain. Publishing the monitor's metrics to CloudWatch lets an alarm reflect drift, and an EventBridge rule on that alarm's state change can start the pipeline as a native target, with no code. A scheduled Lambda function that parses the violation report also works, but it is custom code to maintain. Matching on job completion fires on every run, drift or not.

1. Find a signal that changes only when drift happens: a CloudWatch alarm on the drift metric.
2. Find a no-code way to react to that signal: EventBridge, which can start a SageMaker pipeline directly.
3. Compare with the workable polling Lambda function: it adds code, so it loses on operational overhead.
4. Reject triggers that fire on every run.

Exam tip: Drift alarm -> EventBridge -> pipeline: trigger on the alarm, not on the monitoring job finishing.

Text drift for a Bedrock application is measured on logged prompts (for example by comparing embedding distributions), because Model Monitor data capture applies to SageMaker AI endpoints, not Bedrock.

Two facts combine. First, SageMaker Model Monitor needs data captured from a SageMaker AI endpoint or batch transform job, so it cannot watch Bedrock traffic. Second, the prompts are already in the invocation logs, and topic shift in free text is best measured in embedding space (for example distance between the current and baseline embedding distributions or cluster proportions). A scheduled job publishing a custom metric gives the weekly, alarmable measure. A fixed evaluation set and token counts cannot reveal new topics.

1. Check where the data lives: Bedrock invocation logs in S3.
2. Rule out Model Monitor, which needs SageMaker endpoint or batch transform capture.
3. Choose a representation that captures topic: embeddings, not token counts.
4. Automate the comparison and publish a metric that can drive an alarm.

Exam tip: For GenAI input drift, compare embeddings of logged prompts with a baseline; Model Monitor does not watch Bedrock.

SageMaker Pipelines publishes execution status change events to Amazon EventBridge, which can route failures to notifications.

Event-driven detection is the lowest-overhead way to catch workflow failures. SageMaker Pipelines sends execution (and step) status change events to EventBridge; a rule that matches the Failed status and targets an SNS topic notifies on-call within minutes, with no code. A scheduled Lambda function that polls executions also works, but it is code to build and maintain. Matching the Starting status pages on every run, and forwarding every log line floods the on-call engineer without identifying failed runs.

1. Look for an event the service emits on failure.
2. Match the Failed status, not other states.
3. Prefer the event rule over a workable polling function, because it needs no code.

Exam tip: Workflow failure alerts: EventBridge rule on the service's status-change event, filtered to Failed.

CloudWatch anomaly detection builds an expected-value band from a metric's history, including seasonality, and alarms when values fall outside it.

A seasonal metric defeats fixed thresholds. CloudWatch anomaly detection trains on the metric's history, models daily and weekly patterns, and produces a band; an alarm on that band fires only on genuinely unusual volume in either direction, and the band retrains itself. A composite of weekday and weekend static alarms can partly work, but its thresholds must be tuned and retuned by hand, so it loses on operational overhead. Metric math against the previous hour still flags the normal Monday ramp, and Contributor Insights solves a different problem.

1. Notice the metric is seasonal and static thresholds fail.
2. Look for a feature that learns expected values from history.
3. Compare with hand-tuned composite thresholds: workable but higher overhead.
4. Alarm on the anomaly detection band.

Exam tip: Seasonal metric + no hand-tuned thresholds = CloudWatch anomaly detection alarm.

CloudWatch Logs anomaly detection learns a log group's normal patterns and surfaces new or unusual ones without predefined patterns.

The deciding constraint is that the errors are unpredictable and the job does not fail. A metric filter needs a known pattern, and state-change rules only see failures. A CloudWatch Logs anomaly detector learns the usual log patterns of the group and flags new patterns or unusual frequencies, which is exactly how a new parsing error would show up.

1. Note that the job succeeds, so state-change events will not help.
2. Note that the error text is unpredictable, so fixed filters will miss it.
3. Choose a detector that learns normal log patterns.

Exam tip: Unknown error patterns in logs = CloudWatch Logs anomaly detection; known patterns = metric filters.