AWSAWS Certified Generative AI Developer - Professional2026-100 Prerequisites
Separate instructions from evidence and support
Completed by the knowledge check
Learning objective
Distinguish prompt engineering, context engineering, and grounding. You should be able to decide whether a failed answer needs clearer instructions, different information in the model’s input, or verification against supporting evidence. The RAG stage model follows in 0.9; detailed context assembly belongs to 1.5.11.
Core idea
Prompt engineering improves how you express the task. Context engineering selects and assembles what the model receives when it performs that task. Grounding connects generated claims to supporting information rather than accepting them because they sound plausible.
The boundaries overlap because instructions are part of the model’s input, and retrieved evidence arrives through that input too. The useful distinction is the question you are asking: “Did we express the task clearly?”, “Did we provide the right information?”, or “Does that information support the answer?” Changing wording cannot supply an absent policy, and supplying a policy cannot guarantee that the model applies it correctly.
How it works
Express behavior through prompt engineering
AWS defines prompt engineering as crafting and optimizing input prompts through wording, punctuation, and separators. For architecture decisions, treat it as designing instructions and demonstrations that make expected behavior explicit. Role instructions, output requirements, and few-shot examples are covered in 0.7.
In an ordinary Bedrock Converse request, system carries task instructions or persona context, and messages carries conversation content. If a response ignores a requested distinction between a quoted policy and the customer’s claim, clearer labels and instructions can address the ambiguity. If no relevant policy reaches the model, rearranging those labels cannot solve the evidence problem.
Judge a prompt change against a stable input set. Otherwise, replacing both instructions and retrieved passages makes it difficult to tell which change caused the improvement. Prompt regression testing belongs to 1.6.6.
Assemble information through context engineering
In this guide, context engineering means the application work of selecting, ordering, and budgeting instructions, conversation history, retrieved documents, and tool results for a model invocation. It is a design discipline, not the name of a single Bedrock operation.
Amazon Bedrock Knowledge Bases provides a concrete retrieval boundary. Retrieve returns information from a knowledge base in retrievalResults. Those results include content, source location, metadata, and a relevance score. Your application can inspect evidence before placing it into Converse messages. RetrieveAndGenerate combines retrieval and response generation when you choose that managed boundary instead.
Select information for the question and its constraints. A refund policy for a different product version is context, but it is unsuitable context for deciding this customer’s eligibility. Conversation history can identify the product; source metadata can identify the applicable policy. Authorization and metadata filter design are covered in 1.4.6. They are enforced application concerns, not permissions granted by a prompt instruction.
Context assembly also decides what to leave out. Repeated passages, obsolete policy versions, and unrelated conversation turns compete with the evidence the answer needs. Preserve the question, applicable instructions, and evidence relationships when reducing input. Token limits and conversation reduction are covered in 0.2 and 1.3.9 rather than redefined here.
Establish support through grounding
Grounding asks whether the response’s claims follow from the supplied evidence. Retrieval is one way to obtain that evidence, but an application can also supply a reference document directly. A database tool result can support a claim about an order status when the result actually describes the right order.
Bedrock Guardrails contextual grounding checks distinguish two signals: grounding measures factual support relative to a reference source, while relevance measures whether the response addresses the query. The documented check requires a grounding source, a query, and the response to assess. The source tags include grounding_source and query. Its supported use cases include summarization, paraphrasing, and question answering; AWS explicitly excludes conversational QA/chatbot use cases. Do not present this check as a universal validator for every conversation. Enforcement details belong to 3.1.1 and 3.1.2.
A response can pass one conceptual test and fail another. A correct quotation of a cancellation policy is grounded in that source but irrelevant to a question about delivery. A confident delivery date can answer the question while lacking support in the supplied order record. Evaluate both relationships.
Grounding also has a source boundary. An answer can faithfully reproduce a stale policy. That establishes support relative to the policy you supplied, not currency or correctness against every external fact. Verify source suitability before using answer support as an acceptance signal.
Key distinctions and trade-offs
Use the failure mechanism to choose the intervention:
| Observed defect | Primary concern | Useful intervention |
|---|---|---|
| The model performs the wrong task | Prompt engineering | Clarify the task, labels, and expected response |
| The needed fact never reaches the model | Context engineering | Retrieve or supply the applicable evidence |
| Irrelevant history crowds out the policy | Context engineering | Select and budget the retained input |
| The answer introduces an unsupported exception | Grounding | Compare the claim with the supplied source |
| The source itself is obsolete | Source quality and context selection | Replace the source and repeat evaluation |
More context is not automatically better. Adding unrelated evidence increases input while making the relevant distinction harder to inspect. Stronger instructions can encourage abstention, but only an enforced application policy can decide what response the product releases.
Similarly, a high retrieval score describes relevance within the retrieval system. It is not a probability that every generated claim is true. RetrieveAndGenerate citations identify source relationships, but you still need to assess whether the cited passages support consequential claims; see 3.1.6.
Architecture / decision scenario
A product-support assistant answers refund questions. It gives an incorrect exception with a fluent explanation. The team first inspects the exact model input instead of increasing the strength of the phrase “be accurate.”
One test case has no refund policy at all. The context assembly is repaired by using Retrieve and selecting passages for the customer’s product version. Another case contains the right policy, but the prompt asks for a creative resolution. The team changes the system task to explain eligibility from the provided evidence and identify missing information.
A third case still invents an exception that the policy does not contain. That requires claim-support evaluation and an acceptance rule, not another retrieval result merely because it has a high score. The team treats the conversational assistant separately from the documented Guardrails contextual-grounding scope. It uses Amazon Bedrock Knowledge Bases RAG evaluation with Builtin.Faithfulness to assess hallucination relative to retrieved text on reviewed cases and withholds unsupported decisions. See 0.12 for the metric distinctions. Each intervention addresses a different failure boundary.
Common exam traps
- Treating context engineering as a synonym for rewriting instructions.
- Assuming RAG guarantees grounded or correct answers.
- Equating a retrieval score with generated-answer factual confidence.
- Treating a cited but obsolete source as proof of a current policy.
- Assuming instructions can enforce document permissions.
- Applying a grounding-check feature outside its documented use-case scope.
What to remember
- Prompt engineering expresses what the model should do.
- Context engineering determines what information reaches the model.
- Grounding tests support between evidence and generated claims.
- Relevance to the question and support from the source are distinct signals.
- Repair the failed boundary before changing unrelated parts of the system.
Knowledge check
A refund assistant states a wrong exception. The exact model input for that case contains no refund policy at all. A teammate proposes adding “Be accurate and follow refund policy” to the system field. What should the team do instead?
system fieldFor another case, the model input contains the correct policy for the customer’s product version, but the system instruction asks the model to “propose a creative resolution,” and answers offer remedies the policy does not provide. Which change addresses this case?
A response quotes the cancellation policy word for word, but the customer asked about delivery dates. How should the evaluation classify the response?
A response accurately summarizes the refund policy it cites, but that policy was superseded last month. What must change before the answer can be accepted as current guidance?