Foundation Model Integration, Data Management, and Compliance practice questions

Retrieval-augmented generation (RAG) for frequently changing source material that must be cited.

Three requirements decide the design: the content changes weekly, the change must show the same day, and answers must cite their source. Retrieval at request time satisfies all three because the model reads whatever is currently indexed and the retrieved chunks keep their source metadata. Fine-tuning and continued pre-training bake knowledge into weights, which goes stale between jobs, cannot cite, and requires the training operations the team wants to avoid. Stuffing the corpus into every prompt does not scale in cost or context size.

1. List the requirements: freshness, traceability, operational limits.
2. Freshness plus citations points to retrieval, not to changing model weights.
3. Check the corpus size against what one request can reasonably carry.
4. Pick the option that needs no training pipeline.

Exam tip: Changing facts that must be cited belong in retrieval; weights are for behaviour, not for this week's rules.

Combining techniques: retrieval for volatile facts, fine-tuning for a behaviour that prompting cannot hold.

The two problems have different causes. Stale prices are a knowledge-freshness problem, solved only by reading the source of truth at request time. The voice is a behaviour problem; the team has already exhausted prompting, and they own thousands of approved examples, so supervised fine-tuning is the justified next step. Training on the catalog cannot keep pace with intraday changes, continued pre-training is for domain knowledge from unlabeled text rather than style from examples, and retrieving the style guide repeats what already failed.

1. Split the requirement into its separate root causes.
2. Volatile facts: read them at request time.
3. Behaviour that prompting cannot hold, with good labeled examples: fine-tune.
4. Reject options that retrain on facts or repeat a failed approach.

Exam tip: Retrieve what changes, fine-tune how it should sound; one technique rarely fixes both.

When an FM must run on infrastructure you control: SageMaker AI endpoints versus Bedrock-managed hosting.

The deciding requirements are custom code inside the inference container and a mandated instance type. Only a SageMaker AI endpoint gives both, because you bring the container and choose the instance. Bedrock options, whether an imported model or a Bedrock fine-tune, are managed hosting: you provide weights or data, never container code, and AWS chooses the hardware. SageMaker serverless inference is CPU-only and so cannot serve this model.

1. Identify control requirements: container code, hardware choice, networking.
2. Bedrock hosting accepts weights or training data, not containers.
3. SageMaker AI real-time endpoints accept custom containers on chosen instances.
4. Rule out serverless inference whenever a GPU is required.

Exam tip: Need your own container or your own GPU choice? Host on a SageMaker AI endpoint, not in Bedrock.

Bringing externally customized open-weight models into Bedrock with Custom Model Import.

Two facts combine here. First, Bedrock Custom Model Import takes weights for supported architectures (Llama, Mistral, Qwen and others) from S3 in Hugging Face format and serves them through the Bedrock runtime on demand, so the team keeps one API and manages no capacity. Second, the SageMaker alternatives each break a constraint: a real-time endpoint bills for running instances even when idle, and serverless inference has no GPUs. Re-training in Bedrock with provisioned throughput adds a commitment the bursty traffic does not justify.

1. Check the model architecture and weight format against what Bedrock can import.
2. Match 'pay only while serving, no instances' to on-demand managed hosting.
3. Eliminate options that keep instances running or lack GPU support.
4. Prefer reusing existing weights over repeating training.

Exam tip: Own the weights but want serverless Bedrock APIs? Custom Model Import, if the architecture is supported.

Matching the invocation pattern to the latency need: batch inference for large offline workloads.

The job is large, offline and cost-sensitive. Bedrock batch inference takes a JSONL file of requests in S3, runs it asynchronously and writes results back to S3, at a lower price than on-demand for supported models. Per-object Lambda calls pay on-demand prices and invite throttling, the Priority tier pays more for speed nobody needs, and provisioned throughput is a standing commitment.

1. Ask whether anyone is waiting on each individual response.
2. Large and offline points to an asynchronous batch job.
3. Compare the pricing model of each option against the cost goal.

Exam tip: No one waiting and millions of records: use batch inference, not per-request calls.

SageMaker AI inference options: real-time, serverless, asynchronous and batch transform.

The combination of very large payloads, long processing, sporadic arrivals, near-real-time results and no idle cost describes asynchronous inference exactly: requests are queued from S3, results land in S3, SNS can announce success or failure, and the instance count can scale to zero. Real-time endpoints cannot accept these payloads or durations, serverless endpoints lack GPUs, and batch transform trades latency for bulk efficiency.

1. Note payload size and processing time first; they rule out real-time and serverless.
2. Sporadic traffic plus no idle cost points to an option that scales to zero.
3. Near-real-time results rule out a scheduled batch job.
4. Asynchronous inference meets all of these at once.

Exam tip: Big payloads, long runs, spiky arrivals: SageMaker AI asynchronous inference.