Free lesson · Claude Certified Architect - Foundations (CCA-F)
The Scenario Pool: How One Narrative Anchors a Block of Questions
The Structural Fact Most Candidates Miss
Interactive animation: Six scenarios in the pool, four drawn at random, about fifteen questions each - sixty in all.
CCAR-F is built around a pool of six scenarios. Four of them appear on your exam, selected without your input. Each selected scenario provides the narrative context for roughly fifteen questions.
Do the arithmetic: four scenarios times fifteen questions is sixty. That accounts for the entire exam.
This is not a detail about how some questions are framed. It is the architecture of the whole assessment. There are no standalone items. Every question you answer sits inside a narrative, and the narrative is not decoration - it carries the constraints that determine which answer is correct.
Most candidates study topic by topic and then meet a fifteen-question block about a customer support agent having never rehearsed the motion of holding a narrative in working memory across fifteen consecutive decisions. That gap is the reason this topic exists.
How Selection Works
graph TD
P[Scenario pool<br/>6 narratives] --> S1[Support agent]
P --> S2[Multi-agent research]
P --> S3[Claude Code in a team]
P --> S4[Data extraction]
P --> S5[Enterprise MCP]
P --> S6[Long-running analysis]
S1 --> F[Your exam form<br/>4 selected at random]
S3 --> F
S4 --> F
S6 --> F
F --> Q["~15 questions each<br/>60 total"]
This diagram shows the scenario selection mechanic. A pool of six narratives fans out into individual scenarios: a support agent, multi-agent research, Claude Code in a team, data extraction, enterprise MCP, and long-running analysis. Four of these six feed into your exam form, chosen at random. The form then produces roughly fifteen questions per selected scenario, totalling sixty questions.
Two consequences follow directly from the selection being random.
You cannot predict which four you will get, so you cannot skip preparation on any of them. A candidate who is comfortable with agentic support systems but has never thought about a structured extraction pipeline is gambling on a coin flip that will probably not go their way - the chance of avoiding any specific scenario is only one in three.
Domain coverage is distributed across scenarios rather than isolated within them. A Claude Code scenario is not a pure D3 block. It will pull in permissions and enforcement from D1, tool boundaries from D2, and instruction design from D4. The domain weights describe the exam overall, not any individual scenario.
Important: Because domains are mixed inside scenarios, you cannot compensate for a weak domain by hoping it clusters in a block you can afford to lose. A weak D5 will bleed points across all four of your scenario blocks rather than concentrating in one.
Why the Narrative Is the Answer Key
In a conventional certification, a question stem is self-contained: it states everything needed to answer. In a scenario exam, the stem is deliberately incomplete. It relies on the narrative for the constraints that discriminate between options.
This produces the exam's most reliable failure mode. A candidate reads an option, recognises it as sound general practice, and selects it - without checking it against the specific constraints in the narrative. The option was correct in the abstract and wrong for this system.
Consider the shape of it. A scenario establishes that a support agent handles billing disputes and that any action touching a customer's payment method requires human approval. Later, a question asks how to handle a case where the agent has high confidence in a refund decision. "Let the agent proceed autonomously when confidence is high" is defensible general practice. It is wrong here, because the narrative stated a hard requirement that confidence does not override.
The narrative introduced a constraint. The question tested whether you carried it forward.
Tip: Whenever an option feels obviously right, spend five seconds asking which sentence in the narrative supports it. If you cannot point to one, you are answering from general practice rather than from the scenario, and that is precisely the trap the format is built to catch.
Interactive animation: High confidence in a refund still goes to a human when the narrative made approval a hard requirement.
The Constraint Ledger
The technique that converts this structure from a liability into an advantage is to extract constraints once, in writing, before answering the first question in a block.
When a new scenario appears, read it fully and build a short ledger. You are looking for five categories:
| Category | What to capture | Example phrasing in a narrative |
|---|---|---|
| Hard requirements | Things that must always or never happen | "must be approved by a human," "cannot expose" |
| Prohibitions | Explicitly forbidden approaches | "without introducing new infrastructure" |
| Scale and volume | Numbers that make an approach viable or not | "thousands of documents per night" |
| Latency and cost posture | Whether the system is interactive or batch | "users wait for a response," "runs overnight" |
| Existing constraints | What is already in place and cannot change | "the team already uses," "an existing CI pipeline" |
Three to six lines is usually enough. The ledger is not a summary of the narrative; it is only the parts that could discriminate between two otherwise reasonable options.
graph TD
A[New scenario appears] --> B[Read fully once<br/>4-5 minutes]
B --> C[Extract constraint ledger<br/>3-6 lines]
C --> D[Answer Q1 to Q15<br/>from the ledger]
D --> E{Option contradicts<br/>a ledger line?}
E -->|Yes| F[Eliminate<br/>regardless of merit]
E -->|No| G[Evaluate on merit]
D --> H[Do not re-read<br/>the narrative]
This diagram shows the constraint ledger protocol as a sequence. A new scenario appears and is read fully once, taking four to five minutes. From that reading you extract a constraint ledger of three to six lines. All fifteen questions in the block are then answered from the ledger rather than from the narrative. A decision point checks whether each option contradicts a ledger line: if yes, eliminate it regardless of its technical merit; if no, evaluate it on merit. A separate branch emphasises not re-reading the narrative during the block.
The elimination rule in that diagram is the highest-value habit in the whole course. An option that violates a stated constraint is wrong even when it is the best engineering answer in general. The exam is testing design under constraints, and an answer that ignores a constraint has failed the actual task regardless of its technical quality.
Constraint Drift
Fifteen questions is long enough for a specific and predictable failure to occur: you remember the narrative's general shape but lose a specific constraint somewhere around question eight, and every subsequent answer is made against an incomplete picture.
This is constraint drift, and it is why the ledger is written rather than mental. A written ledger does not decay. Working memory under time pressure does.
Drift has a characteristic signature. Your early answers in a block are careful and grounded; your later answers start to sound like generic best practice. If you review a practice block and notice that pattern, you have diagnosed drift rather than a knowledge gap, and the fix is procedural rather than educational.
Warning: Constraint drift is frequently misdiagnosed as a content weakness. A candidate sees that they missed several D1 questions and schedules more agentic architecture study, when the actual cause was losing a latency requirement at question nine. Before remediating content, check whether your misses cluster late within scenario blocks.
The Six Scenario Archetypes
The pool's contents are described in public exam material at the level of context rather than detail. The recurring archetypes are:
| Archetype | Typical decision territory |
|---|---|
| Customer support resolution agent | Autonomy boundaries, escalation triggers, handling ambiguous requests |
| Multi-agent research system | Decomposition, topology selection, synthesis, source attribution |
| Claude Code across a development team | Configuration hierarchy, enforcement mechanism choice, permissions, CI |
| Structured data extraction pipeline | Schema design, fabrication prevention, validation gates, request mode |
| Enterprise MCP integration | Server scopes, authentication, least privilege, trust boundaries |
| Long-running analysis workflow | Compaction, durable state, confidence routing, human review |
Module 18 of this course reconstructs each archetype as a full lab with its own question block, so that you rehearse the fifteen-question motion before exam day rather than encountering it cold.
Interview: Notice how business-shaped these are. Each one reads like a client engagement rather than a technical exercise. If you have done delivery work for customers, lean on that instinct - the exam consistently rewards the answer a competent consultant would defend to a client, which usually means the simplest design that satisfies the stated requirements rather than the most sophisticated one available.
A Reading Protocol
Putting the pieces together into something you can execute under time pressure:
Algorithm: Per scenario block
- Read the narrative once, completely, without looking at any question. Budget four to five minutes.
- Write the constraint ledger - three to six lines covering hard requirements, prohibitions, scale, latency posture, and existing constraints.
- Note the system's shape in one line: is this interactive or batch, single-agent or multi, greenfield or constrained by what exists.
- For each question, read the response count first, then the stem.
- Eliminate any option that contradicts a ledger line, before evaluating anything on merit.
- Among survivors, prefer the simplest design that satisfies every stated constraint.
- Do not re-read the narrative. If you genuinely need a detail you did not capture, retrieve it once and add it to the ledger.
Step three is easy to skip and worth keeping. A single line describing the system's shape prevents a whole class of errors, because many wrong options are wrong at the shape level - proposing a synchronous interactive pattern for an overnight batch job, or a multi-agent topology for a workload that one agent handles cleanly.
Exercise: Starter. Take any technical case study you can find - a vendor architecture post works well - and extract a five-line constraint ledger from it in under four minutes. Repeat until the time is reliable.
Intermediate. Write your own scenario narrative of three or four paragraphs for one of the six archetypes above, deliberately embedding four hard constraints. Then write three questions where the correct answer depends on a constraint rather than on general knowledge. Writing the traps teaches you to see them.
Advanced. Take a fifteen-question practice block and record, per question, whether your answer was driven by a ledger line or by general practice. Then check your accuracy for each group. Most candidates find their general-practice answers are meaningfully less accurate, which is the format's central lesson delivered as personal data.
Quiz: Quick check: A scenario states that the system must not introduce any new infrastructure. A question later offers an option that solves the stated problem elegantly by adding a lightweight message queue. How should you treat it?
A) Select it - it is the best engineering solution to the problem asked B) Select it if no other option fully solves the problem C) Eliminate it - it contradicts a stated constraint, regardless of its merit D) It depends on whether the queue counts as infrastructure
Answer: C - an option that violates a stated constraint is wrong even when it is the superior general solution. The exam is testing design under constraints, and D is the reasoning that talks candidates into trap answers.