Free MLA-C02 practice questions

SageMaker AI training input modes: File (copy first), FastFile (stream with file semantics) and Pipe (stream through FIFO pipes).

File mode, the default, copies the whole dataset to the instance's storage before the script runs, which is where the 40 minutes go. FastFile mode keeps POSIX file access but streams objects from S3 as the script reads them, so the job starts almost immediately and needs no code change. Pipe mode also streams but changes the interface to named pipes, and FSx for Lustre works but adds a file system and VPC setup the team does not want.

1. Identify the cause: File mode downloads the full dataset before training starts.
2. Note the constraints: no script change and no new storage service.
3. Rule out Pipe mode (different read interface) and FSx for Lustre (new infrastructure).
4. Choose FastFile mode on the same S3 prefix.

Exam tip: Slow start in File mode with a file-based script and S3 data: switch to FastFile.

Shortlisting a foundation model starts with hard task requirements such as input size, modality and language; price and quality are compared among models that pass them.

The deciding requirement is that a document of hundreds of pages goes into one request. The context window (the input tokens a model accepts) is therefore a pass/fail filter. Output token limits, embedding dimensions and price are real selection criteria, but each is compared only among models whose context window can hold the contract.

1. Find the hard requirement: the full contract in one request.
2. Translate it into a model attribute: input tokens accepted, the context window.
3. Filter the model catalog on that attribute first.
4. Compare price, latency and quality among the models that remain.

Exam tip: Hard requirements (context window, modality, language) filter the list; cost and quality rank what is left.

Batch transform is SageMaker AI's offline inference option for scoring whole datasets in S3.

The workload is a large dataset scored on a schedule with no interactive caller. Batch transform reads the input from S3, spins up the instances for the job only, writes predictions to S3 and stops. The endpoint-based options all exist to answer requests as they arrive; they can be bent to this job but cost more and add request plumbing.

1. Notice that no application needs an answer in real time.
2. Notice the input is a complete dataset already in S3.
3. Match offline scoring of a stored dataset with no idle cost to batch transform.

Exam tip: Whole dataset in S3, no live caller: batch transform, not an endpoint.

CloudWatch generative AI observability provides a prebuilt Model Invocations view for Amazon Bedrock; request-level inputs and outputs appear only when model invocation logging is sent to CloudWatch Logs.

Two needs decide this: a prebuilt metrics view and per-request prompt/response detail. The Model Invocations view in CloudWatch generative AI observability covers the metrics out of the box, and its invocation table is populated from Bedrock model invocation logs delivered to CloudWatch Logs. Logging only to S3 leaves that table empty, CloudTrail never records payloads, and a hand-built metric dashboard is what the team wants to avoid.

1. List the requirements: prebuilt metrics, per-request content, no custom dashboards.
2. Recognise the prebuilt GenAI view in CloudWatch for Bedrock invocations.
3. Remember that request content comes from model invocation logging, which is off by default.
4. Check the destination: the view reads the logs from CloudWatch Logs, not from S3.

Exam tip: Prebuilt Bedrock invocation dashboards come from CloudWatch generative AI observability; prompts and responses need invocation logging to CloudWatch Logs.

Two independent channel settings: the input mode (File, FastFile, Pipe) decides how data reaches the container; the S3 data distribution type (FullyReplicated, ShardedByS3Key) decides which objects each instance gets.

Two facts must be combined. First, the default FullyReplicated distribution gives each instance the entire dataset, which is why every instance runs out of space and why the workers would train on identical data; ShardedByS3Key splits the objects across the instances. Second, Pipe mode delivers data through a FIFO pipe rather than as files, so it breaks the unchanged script that opens files from a local path. File mode with ShardedByS3Key fixes both the storage and the data split without touching the script.

1. Separate the two settings: input mode and data distribution type.
2. Distribution: the script expects distinct data per worker, so choose ShardedByS3Key.
3. Input mode: the script reads local files and must not change, so rule out Pipe mode.
4. Combine them: File mode with ShardedByS3Key.

Exam tip: Distinct data per worker is ShardedByS3Key; reading ordinary files without code changes rules out Pipe mode.