Claude Architect · Lektion

Einen Szenario-Prompt lesen

Erkennen Sie Bereich, Einschränkung und Kosten eines Fehlers

Lektion 2 von 413 Schritte

Einen Szenario-Prompt lesen ist eine kostenlose Claude Architect-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Claude Architect-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Claude Architect-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

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.

Kostenlos starten

Lerne Python mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse
26
Lektionen
104

Häufig gestellte Fragen

Ist die Lektion „Einen Szenario-Prompt lesen“ kostenlos?

Ja — der vollständige Text von „Einen Szenario-Prompt lesen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Claude Architect-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Claude Architect-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Einen Szenario-Prompt lesen“?

Erkennen Sie Bereich, Einschränkung und Kosten eines Fehlers Du übst Claude Architect mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Claude Architect zu starten?

Keine Vorkenntnisse erforderlich. Claude Architect auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Einen Szenario-Prompt lesen“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Claude Architect-Lektion Code schreiben und ausführen?

Ja. Jede Claude Architect-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Wie Szenariofragen bewertet werden
  2. Einen Szenario-Prompt lesen
  3. Falsche Antworten ausschließen
  4. Kompletter Probetest mit Erklärung
← Zurück zu Claude Architect