Step 3 — Bedrock & AI Services

Here’s where the exam stops being theoretical and starts asking “given this scenario, which AWS service solves it?” That question only has a clean answer once you know what each service is actually for, so let’s map the territory service by service.

Amazon Bedrock: The Model Marketplace

Amazon Bedrock is a fully managed service that gives you API access to foundation models from multiple providers, without you having to provision any GPU infrastructure, manage model servers, or negotiate separate contracts with each model vendor. You pick a model, call an API, get a response.

The defining idea behind Bedrock’s design is choice. Rather than betting an entire application on a single vendor’s model, Bedrock lets you evaluate and swap between providers through one consistent interface:

                     ┌─────────────────────────────┐
                     │        Amazon Bedrock         │
                     │      (unified API layer)       │
                     └───────────────┬─────────────┘
                                      │
        ┌───────────────┬────────────┼────────────┬───────────────┐
        ▼                ▼            ▼            ▼               ▼
   Anthropic          Amazon        Meta         Mistral         (other
    Claude             Nova         Llama         AI              providers
   family             family       family        family          over time)

Your application code talks to Bedrock’s API once; swapping the underlying model for a different provider’s model is largely a configuration change, not a rewrite. That’s a genuinely different value proposition than calling a single vendor’s proprietary API directly, and it’s a favorite exam theme: Bedrock’s core benefit is choice and no infrastructure to manage, not “it’s the only place to get generative AI on AWS.”

Beyond raw model access, Bedrock bundles four capabilities that matter enormously for the exam:

Bedrock Agents

An agent extends a foundation model beyond just answering questions — it can plan a multi-step task, decide which tools or APIs to call, execute those calls, and use the results to keep working toward a goal. Think of the difference between asking a model “what’s my order status” (a single lookup) versus “cancel my order and refund me” (a sequence: look up the order, check the cancellation policy, call the refund API, confirm back to the user).

User: "Cancel order #4471 and issue a refund if it's eligible"
        │
        ▼
┌───────────────────────────────────────────────────────┐
│                   BEDROCK AGENT LOOP                    │
│                                                          │
│   1. Reason: "I need order details first"                │
│         │                                                │
│         ▼                                                │
│   2. Act: call Orders API → get order #4471               │
│         │                                                │
│         ▼                                                │
│   3. Observe: order is within refund window               │
│         │                                                │
│         ▼                                                │
│   4. Reason: "Eligible — proceed with refund"              │
│         │                                                │
│         ▼                                                │
│   5. Act: call Refunds API → issue refund                 │
│         │                                                │
│         ▼                                                │
│   6. Respond: "Order cancelled, $42.00 refunded"           │
└───────────────────────────────────────────────────────┘

This reason-act-observe cycle is the core of agentic AI patterns, and it’s a heavily 2026-relevant exam topic — agentic workflows have moved from research curiosity to standard architecture pattern, and Bedrock Agents is AWS’s managed way to build them without hand-rolling the orchestration loop yourself.

Bedrock Knowledge Bases (RAG, Managed)

Rather than manually building a retrieval pipeline — chunking documents, generating embeddings, storing them in a vector store, writing retrieval logic — Knowledge Bases does this for you. Point it at a data source (S3, for example), and it handles ingestion, chunking, embedding generation, and retrieval, then feeds the relevant chunks into the model’s prompt automatically at query time.

Your Documents (S3)
        │
        ▼
┌──────────────────┐
│  Bedrock          │   1. Chunk documents
│  Knowledge Base   │   2. Generate embeddings
│  (managed RAG)    │   3. Store in vector index
└────────┬──────────┘
         │
User Question ──────▶  4. Retrieve relevant chunks
         │
         ▼
┌──────────────────┐
│  Foundation Model  │   5. Generate answer grounded
│  (via Bedrock)     │      in retrieved content
└──────────────────┘

This is the go-to answer whenever an exam scenario says something like “we need our chatbot to answer questions using our internal documentation, and answers must stay current as documents change” — that’s RAG, and Knowledge Bases is the managed way to do it on Bedrock.

Guardrails for Bedrock

Guardrails let you define content policies that filter both what goes into a model and what comes out — blocking specific topics, filtering harmful content categories, redacting personally identifiable information, and reducing hallucinated responses on grounded queries. Guardrails apply independent of which underlying foundation model you’re using, which matters if you’re comparing multiple models for the same application and want consistent safety behavior regardless of which one answers.

Model Customization

Bedrock also supports fine-tuning and continued pre-training for select models, letting you adapt a foundation model to your own labeled data without managing training infrastructure yourself. This sits between pure prompting and building a model from scratch — you get more specialized behavior at a fraction of the cost of training a new model.

Amazon Q: The Assistant Layer

Amazon Q is AWS’s family of generative-AI-powered assistants aimed at specific jobs — helping developers write and understand code, helping business users query and analyze data in natural language, and helping employees find answers across internal company content. Where Bedrock is the platform you build with, Amazon Q is closer to a ready-made assistant you point at a use case with much less custom development.

The distinction the exam wants: if the scenario says “we want to build a custom generative AI application with our own logic and data pipeline,” think Bedrock. If it says “we want an out-of-the-box assistant that helps our developers code faster or lets business users ask questions of our data,” think Amazon Q.

Pre-Built AI Services vs. Building on Bedrock/SageMaker

AWS offers a set of ready-made AI services, each aimed squarely at one task, exposed as a simple API call with no model selection or prompt engineering required.

Service	What It Does	Typical Trigger Phrase in a Question
Rekognition	Image and video analysis (object detection, facial analysis, content moderation)	“Detect objects/faces in images or video”
Comprehend	Natural language processing (sentiment, entities, key phrases, PII detection)	“Analyze sentiment or extract entities from text”
Textract	Extracts text and structured data from scanned documents and forms	”Pull data out of scanned invoices/forms”
Transcribe	Speech-to-text	”Convert audio/call recordings to text”
Polly	Text-to-speech	”Generate natural-sounding speech from text”
Translate	Language translation	”Translate content between languages”
Lex	Build conversational chatbots/voice bots	”Build a voice or chat interface with intents”

The decision logic the exam is really testing:

Does an existing AI service do EXACTLY this task out of the box?
        │
    ┌───┴───┐
   YES       NO
    │         │
    ▼         ▼
 Use the    Do you need generative/flexible reasoning,
 pre-built   or a custom-trained model on proprietary data?
 AI service          │
              ┌───────┴────────┐
          Generative/flexible   Fully custom model,
          reasoning needed      full control needed
                │                       │
                ▼                       ▼
           Amazon Bedrock          Amazon SageMaker

If a question describes extracting fields from a W-2 form, that’s Textract — don’t overthink it into a Bedrock RAG solution. If it describes a system that needs to reason over unstructured data, hold a conversation, and adapt tone, that’s pointing toward Bedrock. If it describes training a model on proprietary sensor data with a completely custom architecture, that’s SageMaker.

Exam Focus: What Questions Test From This Step

Bedrock’s core value proposition: unified API access to multiple foundation model providers, no infrastructure management
Recognizing agentic patterns (reason-act-observe, multi-step task execution) as what Bedrock Agents provides
Knowing Knowledge Bases as the managed RAG solution — automatic chunking, embedding, and retrieval
Guardrails for Bedrock as the content-filtering and PII-redaction layer, independent of which model answers
Distinguishing Amazon Q (ready-made assistant) from Bedrock (platform for building custom generative apps)
Matching a described task to the correct pre-built AI service (Rekognition, Comprehend, Textract, Transcribe, Polly, Translate, Lex) rather than over-engineering with Bedrock or SageMaker
The decision path: pre-built AI service vs. Bedrock vs. SageMaker, based on required flexibility and control