The mechanics you can't reason your way to

Lessons 0003–0006 trained you to ask "what's the root cause?" That's the right instinct for most of the exam. But three task statements are not judgment calls at all — they have one correct factual answer, and reasoning harder does not help you:

• 2.5 — Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob)
• 3.6 — Integrate Claude Code into CI/CD pipelines
• 1.7 — Manage session state, resumption, and forking

Why this matters for pacing: reports say the first ~15 questions eat the most clock. Recall questions are the ones you should answer in 15 seconds so you bank time for the architectural ones. Any recall question you have to think about is costing you twice.

Grep's parameters — the level of detail the exam actually reaches

Knowing "Grep searches contents" is not enough. A certsafari item asked how to match class headers wrapped across lines (class OrderHandler(\n BaseHandler, LoggingMixin\n):) — a single-line search misses them. The answer is a parameter, not a different tool.

Exam tell: when a search nearly works — finds some matches but not the wrapped/multi-line ones — reach for multiline: true plus scoping, not for a different tool. Globbing every file and reading them all is the distractor, and it's the same read-everything anti-pattern as §3.

Also: Grep is ripgrep regex, not POSIX — metacharacters need escaping (finding interface{} in Go takes interface\{\}).

Two details docs confirm that distractors are built from

• Grep respects .gitignore; Glob does not by default. So "why didn't my search find the file in dist/?" has a real answer.
• Glob results are capped at 100 files, sorted by modification time. A truncation flag comes back so the pattern can be narrowed.

When Edit fails because the anchor text isn't unique, the guide's answer is: Read the full file, then Write it back.

Verbatim from the guide (2.5): "When Edit fails due to non-unique text matches, using Read + Write as a fallback for reliable file modifications."

Build understanding incrementally. Start with Grep to find entry points, then Read to follow imports and trace the flow — rather than reading all files upfront.

For tracing a function through wrapper modules: first identify all the exported names, then search for each name across the codebase.

Verbatim from the guide (2.4): "Enhancing MCP tool descriptions to explain capabilities and outputs in detail, preventing the agent from preferring built-in tools (like Grep) over more capable MCP tools."

The fix is the tool description — consistent with Domain 2's master rule that descriptions are the primary mechanism for tool selection.

a) Self-review doesn't work — use an independent instance

The session that generated the code is less effective at reviewing it than a fresh instance. Same context carries the same confirmation bias.

Verbatim from the guide (3.6): "Session context isolation: why the same Claude session that generated code is less effective at reviewing its own changes compared to an independent review instance."

Your Q15 miss: you picked "add self-review instructions to the generation prompt." But the scenario stated Claude already considered those cases and rationalized them. More self-critique in the same context reaches the same conclusion. The answer is a second instance that never sees the generator's reasoning. Extended thinking loses for the same reason — more deliberation inside the biased context.

b) Re-running a review posts duplicate comments — feed it the prior findings

When you re-run after new commits, include the previous findings in context and instruct Claude to report only new or still-unaddressed issues.

Same shape for test generation: provide the existing test files so it doesn't propose scenarios the suite already covers.

The pattern: duplicate/redundant output → the missing piece is what already exists in context. Not a dedup post-processor.

c) Batch API cannot run this workflow at all

If the review loop calls tools mid-analysis (request a file, get it back, continue), batch is architecturally out — not merely slow. The async fire-and-forget model has no way to execute a tool mid-request and hand results back.

Your Q8 miss: you picked the 24-hour latency answer. Latency is real, but that option said the workflow "could otherwise function" — and it couldn't. When one option names a hard impossibility and another names an inconvenience, the impossibility is the "primary technical constraint." (Lesson 0006 §3 drills this same trap.)