A Domain-by-Domain Revision Checklist

Revision for a professional exam fails when it is a reading exercise. The test is not whether you have seen a feature but whether you can choose between features under a constraint. Use this checklist as a set of prompts: for each line, try to state out loud what the thing is, what it is not, and what you would use instead. If you cannot, that is a gap.

Domain 1 — Foundation Model Integration, Data, and Compliance (31%)

• The Amazon Bedrock invocation surface: InvokeModel, InvokeModelWithResponseStream, and the model-agnostic Converse and ConverseStream APIs, including toolConfig for tool use.
• Inference profiles: what a cross-Region profile buys you (throughput, resilience) and what it costs you (requests may be served from another Region within the geography — a data-residency consideration).
• Knowledge bases: supported vector stores, the difference between Retrieve and RetrieveAndGenerate, and why citations matter.
• Chunking strategies — fixed-size, hierarchical, semantic, none, and custom transformation — and which one suits long structured documents versus short records.
• Embeddings: why you cannot mix embedding models between ingestion and query, and what re-ranking adds.
• Customisation: fine-tuning versus continued pre-training versus distillation versus Custom Model Import, and how each is served.
• Data handling: encryption with AWS KMS customer managed keys, S3 source data permissions, and evidencing that inputs are not used for training.

Domain 2 — Implementation and Integration (26%)

• Bedrock Agents: action groups defined by an OpenAPI schema or by function details, the Lambda executor, and return of control when your application executes the tool instead.
• Agent session state versus agent memory versus a knowledge base: within-request context, across-session summary, and retrieval over documents. Do not conflate them.
• Multi-agent collaboration: a supervisor agent delegating to collaborator agents, and when that beats one agent with many tools.
• Orchestration alternatives: AWS Step Functions Standard versus Express, Map and Distributed Map for fan-out, Retry and Catch for deterministic error handling.
• Event-driven glue: Amazon EventBridge, Amazon SQS, and AWS Lambda around a generative workload, including idempotency for retried invocations.
• Amazon Bedrock AgentCore components for running agents you have built yourself, including its runtime, gateway, memory, identity and observability pieces.
• API Gateway in front of a model-backed service: timeouts, streaming, and throttling.

Domain 3 — AI Safety, Security, and Governance (20%)

• Guardrails: content filters, denied topics, word filters, sensitive-information filters, contextual grounding checks, and the standalone ApplyGuardrail API for models not invoked through Bedrock.
• Guardrail versioning and how a draft differs from a published version.
• IAM for Bedrock: resource ARNs for foundation models, inference profiles, agents, knowledge bases and guardrails, plus condition keys.
• Network isolation: interface VPC endpoints for the Bedrock services, endpoint policies, and security groups.
• Auditability: AWS CloudTrail for the API calls, and Bedrock model invocation logging (separately enabled, delivered to Amazon S3 or Amazon CloudWatch Logs) for the prompts and completions themselves.
• Prompt injection: why it is a content problem that guardrails and least-privilege tools mitigate, and why it is not solved by IAM alone.

Domain 4 — Operational Efficiency (12%)

• Cost levers: on-demand versus batch inference versus Provisioned Throughput, prompt caching, model right-sizing, and shorter prompts through customisation.
• Latency levers: model choice, streaming responses, latency-optimised inference, caching, and removing hops.
• Throughput and quotas: service quotas, how throttling surfaces, and when Provisioned Throughput is the answer.
• Monitoring: CloudWatch metrics for invocations, latency and throttles; token usage in the response payload.

Domain 5 — Testing, Validation, and Troubleshooting (11%)

• Amazon Bedrock evaluations: automatic model evaluation, human evaluation, RAG evaluation, and using a model as a judge.
• Diagnosing a bad RAG answer: is it retrieval (wrong chunks returned) or generation (right chunks, wrong answer)? The fix differs completely.
• Contextual grounding checks as a runtime detector for ungrounded answers.
• Agent traces: reading the orchestration trace to see which action group was chosen and why.
• Regression testing prompts: golden datasets, and why a prompt change is a deployment.

How to weight this

Do not revise the list top to bottom in equal time. Domains 1 and 2 are 57% of the paper; if you have ten hours, roughly six of them belong there. But do not skip domains 4 and 5 entirely — they are the cheapest marks on the exam, because the concepts are fewer and the questions are more formulaic than in the big domains.

# Domain 2 in one artefact: an action group's OpenAPI schema. The agent reads
# the DESCRIPTIONS to decide when to call this operation, so vague wording
# here is the commonest cause of an agent that never calls its own tool.
openapi: 3.0.0
info:
  title: Claims Operations API
  version: 1.0.0
paths:
  /claims/{claimId}/status:
    get:
      operationId: getClaimStatus
      summary: Get the current status of a claim
      description: >
        Returns the workflow status of a single claim. Call this when the
        customer asks whether a claim is open, closed, or awaiting documents.
        Do not call this for questions about policy wording.
      parameters:
        - name: claimId
          in: path
          required: true
          description: The claim reference, for example CLM-4471.
          schema:
            type: string
      responses:
        "200":
          description: The claim's current status.
          content:
            application/json:
              schema:
                type: object
                properties:
                  claimId:
                    type: string
                  status:
                    type: string
                    enum: [OPEN, AWAITING_DOCUMENTS, CLOSED]
                  lastUpdated:
                    type: string
                    format: date-time

# Exam-relevant points in this one file:
#  - the schema lives in Amazon S3 (or is inlined) and is attached to the
#    action group;
#  - the executor is a Lambda function, OR you use return of control and
#    execute the call in your own application;
#  - the Lambda's resource policy must allow bedrock.amazonaws.com to invoke
#    it, and the agent's service role must allow the model invocation.