Fundamentals of Generative AI
Read this domain as a pipeline: concepts → fit → AWS service to build on
Carrying forward the AI/ML vocabulary from Domain 1, by the end of this domain you can name GenAI's building blocks, judge whether it fits a problem, and pick the AWS service to build on. Its three subtopics are deliberately sequential, not parallel. Generative AI Concepts gives you the vocabulary (tokens, embeddings, context window, foundation models (FMs), transformers, multimodal and diffusion models) that every later answer is phrased in. GenAI Capabilities & Limitations turns that vocabulary into a yes/no judgement: is generative AI the right tool for this business problem, and which model trade-offs matter. Only then does AWS GenAI Infrastructure ask which managed service you build on. An AIF-C01 scenario almost always touches all three layers at once: it describes a use case (capabilities), expects the right terms (concepts), and asks for a service (infrastructure). The cross-cutting idea is reuse: one expensive pre-training run produces a general-purpose FM that organizations adapt cheaply through prompting, retrieval, or fine-tuning rather than training from scratch, and AWS packages that adaptation as managed services so a candidate uses GenAI without building it.
Match the question's verb to the right subtopic
The blueprint splits Domain 2 by task verb, and the subtopics mirror it one-to-one. 'Define' / 'describe a concept' (tokens, chunking, embeddings, transformer-based LLMs, FMs, multimodal, diffusion) is Task 2.1 → generative-ai-concepts. 'Advantages / disadvantages', 'factors when selecting a model', and 'business value and metrics' are Task 2.2 → genai-capabilities-limitations. 'Which AWS service / feature to develop a GenAI application' is Task 2.3 → aws-genai-infrastructure. This mapping is reliable enough to use as a triage step before you read the answer options. A frequent trap is a question that sounds like infrastructure ('which service…') but is really testing a limitation, e.g. asking which feature reduces hallucinations points at Amazon Bedrock Guardrails, which only makes sense once you know hallucination is an inherent FM limitation, not a service bug.
Choose the highest-level managed service that still meets the requirement
Across the infrastructure subtopic the recurring AWS decision rule is to prefer the most managed option that satisfies the use case, descending only when you need more control. Top of the stack are finished applications: Amazon Q Business (enterprise assistant over your data) and Amazon Q Developer (coding/AWS assistant), which require no model work at all. Below that is Amazon Bedrock, a serverless single API to many providers' FMs (Amazon Nova/Titan, Anthropic Claude, Meta Llama, Mistral, Cohere, AI21, Stability) for when you build a custom application but still want AWS to operate the model. At the bottom is Amazon SageMaker AI, the full build-train-tune-host platform for teams that need control over the model itself; SageMaker JumpStart sits inside it as a pretrained-model hub. The trade-off is explicit: higher-level services give faster time to market and less operational burden, while lower-level services give more control at the cost of setup effort. AIF-C01 rewards the highest-level fit: pick Amazon Q before Bedrock, and Bedrock before SageMaker AI, unless the scenario demands the control only the lower layer provides.
Cost and limits are measured per token, and the cheapest model can be the right one
A single unit, the token, connects concepts, selection, and pricing. AWS defines a token as a sequence of characters a model treats as one unit of meaning (roughly 0.75 of an English word), and the same token count governs the context window (a shared budget for prompt plus completion) and the bill. The three Amazon Bedrock pricing modes, on-demand (pay per input plus output token, no commitment, for variable or low traffic), Provisioned Throughput (reserved fixed capacity for steady high volume), and batch inference (lower per-token price for a large, delay-tolerant job), are each owned in full by the infrastructure subtopic; pick the mode that matches the workload's traffic shape. Because larger, higher-capability models cost more per token and respond slower, a smaller or distilled model (a compact model trained to mimic a larger one) can be the correct business answer for a narrow, well-scoped task: there is no universally best FM. AIF-C01 consistently rewards matching the model and the pricing mode to the workload's volume, latency, and budget, not to raw capability.
Where to build a GenAI application on AWS: Amazon Q vs Amazon Bedrock vs Amazon SageMaker AI
| Dimension | Amazon Q | Amazon Bedrock | Amazon SageMaker AI |
|---|---|---|---|
| What it is | Finished GenAI assistant (application) | Serverless single API to many providers' FMs | Full build-train-tune-host ML platform |
| You provide | Your data/connectors and questions | Prompts and app logic; AWS runs the model | Data, model choice, and pipeline control |
| Control over the model | None. AWS operates it | Consume managed FMs; customize via fine-tuning | Full: train, fine-tune, host your own |
| Typical user | Business or developer end user | App builder wanting managed FMs | ML team needing model-level control |
| Setup effort / time to market | Lowest: turnkey | Low: no infrastructure to provision | Highest: you operate the build/serve stack |
| Pricing shape | Per user/subscription tier | Per token on-demand, or Provisioned Throughput/batch | Pay for training and hosting infrastructure |
| Pick it when | You want a ready assistant over your data/code | You build a custom app on managed FMs | You must control or train the model itself |