Multi-instance & multi-pass review architectures
Design multi-instance and multi-pass review architectures.
This subtopic (4.6) sits in Prompt Engineering & Structured Output (D4) on Anthropic's Claude Certified Architect — Foundations (CCA-F) exam. The bank holds 18 practice questions here — 4 easy, 8 medium, and 6 hard — with 5 free to try, answers and explanations included. 3 of the free questions are below; the rest are in the practice stream.
What the exam tests here
- multi-pass review — per-file local passes plus cross-file integration passes
- independent review instances more effective than self-review instructions
- self-review limitations — model retains reasoning context from generation
- verification passes with model self-reported confidence for review routing
Free practice questions: Multi-instance & multi-pass review architectures
Your CI pipeline invokes Claude Code with --print and --output-format json to review pull requests touching 30+ files across auth, billing, and API layers. Single-pass reviews miss cross-module contract drift (e.g., a renamed auth claim still referenced by billing). How should you structure the review passes to catch these issues while keeping PR comments actionable?
Show answer & explanation
Correct answer: A. Run one per-file local pass for style and correctness, then a second integration pass seeded with the local findings plus a module dependency graph.
Multi-pass review separates concerns: local passes catch per-file defects cheaply, then a dedicated integration pass reasons over cross-file contracts using the local findings as evidence. 'Run a single pass over the concatenated diff' overloads one context and loses per-file precision. 'Spawn parallel per-file passes and merge' never performs cross-file reasoning. 'Sequential per-file passes where each call receives the full diff' grows context unboundedly and biases later files.
Your CI/CD pipeline posts PR comments from a Claude review. The review uses --output-format json with a confidence field. On 15% of reviews, the model reports high confidence but a second human audit finds missing security findings. What review routing best addresses this?
Show answer & explanation
Correct answer: D. Run an independent second Claude instance to audit high-confidence outputs, overriding the score when it disagrees
Self-reported confidence can be miscalibrated; an independent second Claude instance reviews the output without anchoring to the first instance's reasoning, catching findings the original pass missed. 'Route below threshold...' only filters low-confidence outputs and misses high-confidence failures. 'Increase temperature...' adds randomness but does not add verification. 'Instruction to lower scores...' relies on the same instance's judgment that may be wrong.
Your CI pipeline generates PR comments and then instructs the same Claude instance to review them for accuracy before posting. The review rarely finds errors even when engineers later identify false positives. Which architectural change most directly addresses this?
Show answer & explanation
Correct answer: B. Invoke a separate claude -p process for the review step, starting from a fresh context with no generation history
An independent claude -p invocation starts with a clean context window and no prior generation reasoning, eliminating the self-confirmation bias that causes in-session review to miss errors. 'Be critical and skeptical' is a prompt instruction that does not remove the shared context causing the bias. 'Increase temperature' adds noise but preserves the same biased context. 'Run the review after posting' lets false positives reach engineers before correction.
2 more free questions on this subtopic in the practice stream, plus 13 in the full bank. Keep practicing →