0Pricing
Claude Architect · Leçon

Lire une requête de scénario

Repérez le domaine, la contrainte et le coût de l’échec.

Lire une requête de scénario est une leçon Claude Architect gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Claude Architect, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Claude Architect comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

Why Reading Comes First

The Claude Certified Architect exam is scenario-based: every question is a short situation followed by four options, exactly one correct. You see 4 of 8 scenarios, scored 100-1000, and you pass at 720.

Most wrong answers aren't knowledge gaps - they're reading gaps. The prompt always tells you which domain it lives in, what constraint must hold, and what it costs when the system fails. Miss any of those three and a plausible distractor will catch you.

This lesson trains one skill: dissect a scenario into domain, constraint, and failure cost before you ever look at the options.

The Three Signals

Train your eye to extract three signals from any scenario:

  • Domain - which of the five exam areas is being tested. This tells you which mental model applies.
  • Constraint - the hard requirement the answer MUST satisfy (e.g. "must be deterministic", "runs in CI", "context resets between subagents").
  • Failure cost - what breaks if the constraint is violated (financial, legal, safety, or just a slow report). High cost changes the right answer.

Read the prompt three times if needed - once per signal. The options are designed so the wrong ones satisfy two signals but violate one.

Signal 1 - Naming the Domain

The exam weights five domains. Knowing the split tells you what shows up most and which model to reach for:

  • D1 Agent Architecture & Orchestration - 27% (the largest)
  • D3 Claude Code Config & Workflows - 20%
  • D4 Prompt Engineering & Structured Output - 20%
  • D2 Tool Design & MCP - 18%
  • D5 Context Management & Reliability - 15%

Keywords map fast: "coordinator/subagent" - D1; ".mcp.json / tool description" - D2; "CLAUDE.md / plan mode / -p" - D3; "JSON Schema / few-shot" - D4; "summarization / lost-in-the-middle" - D5.

# Keyword -> domain map you keep in your head:
DOMAIN_HINTS = {
    "coordinator|subagent|delegate": "D1 Agent Architecture (27%)",
    ".mcp.json|tool description|isError": "D2 Tool Design & MCP (18%)",
    "CLAUDE.md|plan mode|-p|slash command": "D3 Claude Code (20%)",
    "JSON Schema|few-shot|tool_choice": "D4 Prompt Eng & Output (20%)",
    "summarization|lost-in-the-middle|provenance": "D5 Context & Reliability (15%)",
}

Spotting the Domain in Practice

Read this stem and name the domain before reading on:

"A coordinator delegates three independent lookups to subagents. One subagent returns empty; the others succeed. How should the system respond?"

Signals: "coordinator", "subagents", "delegates" - this is D1 Agent Architecture & Orchestration, specifically the Multi-Agent Research scenario. Now your mental model loads: subagents don't inherit history, distinguish an access FAILURE from a valid EMPTY result, and return partial results with coverage annotations rather than aborting the whole workflow.

Naming the domain pre-loads the correct anti-patterns to reject.

from anthropic import Anthropic

client = Anthropic()
# Coordinator delegates; each subagent gets context EXPLICITLY -
# subagents do NOT inherit the coordinator's conversation history.
subagent_prompt = (
    "You are a research subagent. Context: " + shared_facts + "\n"
    "Task: look up Q3 revenue for ACME. Return partial results "
    "and a coverage note if data is missing."
)

Signal 2 - The Constraint

The constraint is the requirement the answer cannot violate. It is often a single load-bearing phrase. Watch for these triggers:

  • "must never" / "guarantee" / "always block" - demands DETERMINISTIC enforcement (a hook), not a prompt.
  • "in CI" / "in a pipeline" - demands non-interactive -p with --output-format json.
  • "blocking" / "pre-merge" / "time-sensitive" - rules OUT the Batch API (no latency SLA).
  • "shared via VCS" vs "personal" - project ./CLAUDE.md vs user ~/.claude/CLAUDE.md.

The constraint is what separates two options that otherwise look identical.

Constraints That Force Determinism

The single most common constraint trap: a rule with financial, legal, or safety consequences. The fact sheet is blunt - hooks are 100% deterministic; prompts are ~90% probabilistic. When failure is costly, prompt guidance is the wrong answer.

If the stem says "refunds over $500 must require approval", the correct option is an outgoing-call hook that blocks the action - not "add a clear instruction to the system prompt". Same logic for identity verification: a programmatic precondition (block process_refund until get_customer returns a verified ID) beats any wording.

# Deterministic enforcement - a hook, not a prompt.
def pre_refund_hook(tool_call, state):
    if tool_call.name == "process_refund":
        if not state.get("verified_customer_id"):
            return block("Identity not verified")
        if tool_call.input["amount"] > 500:
            return block("Refund > $500 requires human approval")
    return allow()

Signal 3 - The Failure Cost

Failure cost is the lever that changes which trade-off wins. The exam rewards matching the mechanism's strength to the cost of being wrong.

  • High cost (money/law/safety): choose deterministic guarantees - hooks, preconditions, structured validation. Never settle for "probably right".
  • Low cost (an overnight audit, a draft report): cheaper, slower, model-driven paths are fine - Batch API at 50% off, adaptive decomposition.

A correct mechanism applied where the cost doesn't justify it can still be the wrong answer if a simpler option fits - but under-protecting a costly failure is always wrong.

Cost Maps to Mechanism

Tie the cost to the right tool. The Batch API is 50% cheaper with up to a 24h window but no latency SLA and no multi-turn tool calling - perfect for an overnight compliance audit, disqualified for a pre-merge check.

If a scenario says "validate each pull request before merge", the failure cost is a blocked developer and a broken main branch - that's time-sensitive, so Batch is out and an interactive -p review session is in.

# Time-sensitive / blocking -> NON-interactive CI run, NOT Batch.
claude -p "Review the diff for correctness bugs only" \
  --output-format json \
  > review.json
# Batch API (50% cheaper, <=24h, no SLA) is for overnight audits,
# never for a pre-merge gate.

Mapping All Three Together

Now combine the signals on a full stem:

"A support agent processes refunds. Policy: refunds above $500 need human sign-off. The team added a sentence to the system prompt but a few large refunds still slipped through. What should they do?"

  • Domain: D1 - Customer Support Agent.
  • Constraint: the $500 rule must hold every time ("must").
  • Failure cost: financial - unapproved money leaving.

Three signals point the same way: replace the probabilistic prompt with a deterministic outgoing-call hook. The reading did the work; the answer is now obvious.

signals = {
    "domain": "D1 - Customer Support Agent",
    "constraint": "refunds > $500 MUST get human sign-off",  # 'must'
    "failure_cost": "financial",                              # high
}
# high cost + 'must' -> deterministic enforcement
verdict = "Outgoing-call hook (block), NOT a system-prompt sentence"

Distractors Attack One Signal

Distractors are engineered to satisfy two signals and quietly break the third. Learn the shapes:

  • Right domain, right intent, wrong mechanism strength - "add explicit wording to the prompt" where a hook is required.
  • Right mechanism, wrong constraint - "use the Batch API" for a blocking check.
  • Plausible but a known anti-pattern - parsing text for "done", iteration caps as the primary stop, requiring a possibly-absent schema field, single-pass multi-file review, same-session self-review.

When two options feel close, find the signal they disagree on - that's the whole question.

A Repeatable Reading Routine

Run this routine on every scenario, in order:

  • 1. Domain - one keyword scan; name D1-D5.
  • 2. Constraint - underline the load-bearing phrase ("must", "in CI", "blocking", "shared").
  • 3. Failure cost - financial/legal/safety = high; report/draft = low.
  • 4. Predict the answer BEFORE reading options.
  • 5. Eliminate any option that violates the constraint or matches a top anti-pattern.

And remember: there's no penalty for guessing. After eliminating, commit to your best remaining option and move on - answer every question.

# Mental checklist as pseudocode you run per question:
for scenario in exam:
    domain   = name_domain(scenario)        # D1..D5
    constraint = find_must_phrase(scenario) # the hard requirement
    cost     = failure_cost(scenario)       # high | low
    guess    = predict_answer(domain, constraint, cost)
    answer   = eliminate_antipatterns(options, constraint) or guess
    # never leave it blank - no penalty for guessing

Quick Check

Apply the three-signal routine to the scenario in the question.

Recap - Read Before You Answer

Reading a scenario well is the highest-leverage exam skill. Lock in the routine:

  • Domain - keyword-scan to D1-D5; the right mental model loads with it.
  • Constraint - find the load-bearing phrase; "must/guarantee" forces determinism, "in CI" forces -p, "blocking" rules out Batch, "shared" picks project CLAUDE.md.
  • Failure cost - high (money/law/safety) demands hooks and preconditions; low tolerates cheaper model-driven paths.

Predict before reading options, eliminate anything that breaks the constraint or matches a top anti-pattern, and - since there's no guessing penalty - always commit to an answer. Read three signals first, and the correct option stops being a guess.

Questions Fréquemment Posées

La leçon « Lire une requête de scénario » est-elle gratuite ?

Oui — le texte complet de « Lire une requête de scénario » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Claude Architect, passe à CoddyKit PRO. Le cours Claude Architect comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Lire une requête de scénario » ?

Repérez le domaine, la contrainte et le coût de l’échec. Tu pratiques Claude Architect avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Claude Architect ?

Aucune expérience préalable n'est requise. Claude Architect sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Lire une requête de scénario » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Claude Architect ?

Oui. Chaque leçon Claude Architect inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Comment les questions à scénario sont notées
  2. Lire une requête de scénario
  3. Éliminer les mauvaises réponses
  4. Correction complète d’un examen blanc
← Retour à Claude Architect