Designing FM Applications

Once you have a foundation model, a set of design decisions stands between it and a working feature. Which model, tuned how, grounded in whose data, adapted by what method, and able to act or not. This topic walks those decisions in the order you make them, so that by the end you can look at a scenario and know which choice it is really asking about. These are the choices the largest exam domain tests, and the same ones real teams make when they put a model into production.

What This Topic Covers

• The eight criteria the exam names for choosing a pre-trained model, and the design consequence of each
• Inference parameters (temperature, top-k, top-p, response length, stop sequences) and how they control a model's output
• Retrieval Augmented Generation (RAG): grounding a model in your own data at query time, and Amazon Bedrock Knowledge Bases
• The AWS vector database options for storing embeddings, and how to match one to your stack
• The customization spectrum from prompt engineering to continued pre-training, and the cost tradeoffs at each step
• AI agents for multi-step tasks, how Amazon Bedrock Agents orchestrate actions, and when an agent beats a plain call

Why It Matters

This topic sits inside the heaviest domain on the exam, and its questions are scenario-based rather than definitional. You are handed a situation and four plausible options and asked which fits. Passing means recognizing the one criterion, parameter, or approach a scenario turns on: modality over benchmark scores, RAG over fine-tuning for changing facts, the smaller model that still passes, the agent for a task that spans several steps. Get these right and you can reason about a foundation model application instead of memorizing facts about one, which is exactly the judgment the exam and the job both reward.