Objectives in this domain

Design prompts with explicit criteria to improve precision and reduce false positives.
Section 4.1medium
Apply few-shot prompting to improve output consistency and quality.
Section 4.2medium
Enforce structured output using tool use and JSON schemas.
Section 4.3medium
Implement validation, retry, and feedback loops for extraction quality.
Section 4.4hard
Design efficient batch processing strategies.
Section 4.5medium
Design multi-instance and multi-pass review architectures.
Section 4.6hard

Sample question from this domain

Free samplePrompt Engineering & Structured Outputmedium

The Merge Gate team runs Claude Code inside the CI pipeline for their payments service, where a job reviews each pull request diff and posts comments back to the pull request. The review prompt instructs the model to flag any potential security concern. Across 300 pull requests, engineers dismiss 41 percent of the posted comments, and the same string-concatenation construct is flagged on one pull request and passed over on another with no code difference between them. Which statement best explains that inconsistency?

AThe instruction names a category without stating a decision boundary, so each run resolves what counts as potential against that diff alone, and the precision of the output cannot settle at any particular level. Correct
BThe job runs without a build-time budget, so a longer review reads more of the repository and reaches findings that a shorter review on another pull request never gets to.
CThe job holds no record of earlier pull requests, so it cannot apply the precedent that a previous review set for the same construct on a different branch.
DThe unified diff format hides the lines surrounding each hunk, so the model infers the missing context differently on each run and arrives at a different conclusion about the same construct.

A criterion that names a category without stating its boundary leaves each review run to set its own threshold, so precision cannot stabilise. Precision is a property of the decision boundary, not of the category label. An instruction such as flag any potential security concern gives the model a class name and no rule for membership, so on every invocation the model infers a threshold from the diff in front of it. Two runs on equivalent code can land either side of that inferred line, which is exactly the pattern the team observed. Writing the boundary explicitly, for example that a finding requires attacker-controlled input reaching the construct, moves the decision from inference to a stated test.

Why A is correct: Correct. The word potential admits everything from a proven injection path to a theoretical one, so the model supplies the missing threshold itself on each invocation and the flag rate follows that inference rather than the team's intent.

Why B is wrong: Build time does change how much material a run covers, which makes this tempting, but the two pull requests here carry the same construct in the diff itself, so coverage is not what separates them.

Why C is wrong: It is true that each CI run starts without the history of previous runs, but a precedent is not what decides the call here; a written boundary in the prompt would settle the construct without any memory of past reviews.

Why D is wrong: Limited surrounding context is a real constraint on diff review and can affect hard cases, but it does not account for a 41 percent dismissal rate spread across findings the engineers judge to be non-issues on sight.

Other domains in this exam

Agentic Architecture & Orchestration27% of the exam
Tool Design & MCP Integration18% of the exam
Claude Code Configuration & Workflows20% of the exam
Context Management & Reliability15% of the exam

See also the CCAR-F cert hub, the study guide, and the cheat sheet.