Shared-Versus-Personal Test
The single question the configuration objective depends on: does this element shape output the team collectively owns? If yes, it belongs in version-controlled configuration every member inherits. If no, it stays personal. Project context, conventions, standard procedures, delegated roles, tool connections and permitted operations pass the test; editor choice, keybindings and local paths fail it.
Exam context: The failure mode when the test is skipped is quiet divergence, not chaos. In a question, the divergence reads as harmless. "Tooling preferences are personal" is the tempting wrong answer, and it is exactly the reasoning that produced the divergence the question describes.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Scope Layering
Four configuration layers that work together: organisation-managed, project-committed, personal, and local-uncommitted. Each layer fits a different job because of its position in a defined precedence order. The configuration is designed in layers; the order is what makes each layer capable of the job assigned to it.
Exam context: Questions rarely ask for the order. They ask where an element belongs, which is decided by who must not be able to override it, not by who happened to configure it first.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Organisation-Managed Layer
The top of the precedence order, carrying policy individuals must not override. Nothing beneath it can undo what it sets. That is why it is the right place for a control the organisation cannot allow a developer to disable. It is also the wrong place for anything a team should be able to change.
Exam context: The classic layer mismatch puts organisation-wide policy where a team can change it. The opposite mismatch puts a team standard somewhere nobody inherits it. Both are wrong for the same reason.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Project-Committed Configuration
The team's shared standard, held in the repository: reviewed in pull requests like any other code, improved once for everyone, and inherited automatically by anyone who clones. It is the layer that makes a practice a standard rather than a habit several people happen to share.
Exam context: The competing option is always a document — a wiki page, an onboarding deck, a training session. A document is not inherited, is not reviewed, and enforces nothing.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Local Uncommitted Layer
The gitignored layer for machine-specific values: local paths, sandbox endpoints, a personal scratch setup. It exists so that things which vary per machine never enter shared history, where they would be wrong for everyone else and permanent.
Exam context: The wrong option commits these "so setup is easier for the team". Anything committed is visible to everyone with repository access. It remains in history after deletion. That is why a credential committed once must be rotated, and deleting it is not enough.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Guidance
Written instruction to the model, loaded as context. It shapes what the agent tries to do and is the right instrument for conventions, build commands, architectural decisions and repository etiquette. It is influential and it is not binding: the documentation states that such files are treated "as context, not enforced configuration".
Exam context: This is the substitution most typical of this domain. A question that says an operation must be prevented is not asking for a better-worded instruction, however emphatic.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Enforced Control
A permission rule or lifecycle hook applied by the client regardless of what the model decides. Where guidance shapes intent, an enforced control changes what is possible: "Settings rules are enforced by the client regardless of what Claude decides to do."
Exam context: The right answer and the wrong option often name the same rule, one as a sentence in an instruction file and one as a mechanism. Guidance and enforcement can coexist — keep the sentence, add the mechanism — but only one of them is the answer to "must never happen".
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Rule Composition
The property that makes layered permissions a real control: restrictive rules merge across scopes rather than override each other. So a denial at any layer stays in force, and a managed list can be extended but not reduced. A control placed high is therefore a minimum that lower layers cannot remove, not a default.
Exam context: The wrong option assumes a permission granted at one scope widens what another scope forbids. It never does, which is what lets an organisation delegate configuration without delegating its boundaries.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Onboarding Acceptance Test
The check that tells you whether a team has a standard: a new engineer clones the repository and starts work, and whatever they inherit without being told is the standard. Everything else is a gap held in someone's memory, home directory or browser bookmarks.
Exam context: A useful way to choose between two plausible options. If the standard survives only because a particular person explains it, the option that commits it is right, and the option that routes work through an experienced engineer is wrong.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Instruction-File Budget
The recognition that shared instruction files are loaded at the start of every session and therefore add cost to every request, relevant or not. The discipline is brevity, specificity and internal consistency, since "if two rules contradict each other, Claude may pick one arbitrarily".
Exam context: The bloated instruction file is an anti-pattern that is easy to miss. The important rules are hard to find among the other content, and adherence to them falls. So a longer file achieves less. When a section has grown into a procedure rather than a fact, it should be packaged instead.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Path-Scoped Rule
A narrow convention attached to the part of the codebase it governs, loading only when the agent works with matching files. In a large repository it is what keeps area-specific rules out of everyone else's context while still committing them for the people who need them.
Exam context: The monorepo version of the shared-versus-personal judgement: repository-wide rules at the root, area conventions alongside the code, each directory's owner maintaining its own. "Load everything for everyone" is the alternative, and it adds cost to every request.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Credential Injection Proxy
The pattern that keeps automation authenticated without giving it a secret. A proxy outside the agent's boundary injects credentials into outgoing requests. So the agent "never sees the credential itself", an endpoint allowlist is enforced in one place, and every request is logged in one place.
Exam context: The stronger answer whenever an option offers broad, long-lived credentials as a way to make work easier. Anthropic's secure-deployment guide names three security principles for the whole area: security boundaries, least privilege and defence in depth.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Outcome Measure
A property of the work with a before and an after: cycle time from ticket to merged change, defect escape rate (the share of defects that reach production), review latency (how long a change waits for review), time for a new joiner to make a safe change, incident time-to-resolution. It is the only kind of figure that answers whether the tooling helped.
Exam context: The right answer to "did it work" names measures like these and something to compare them against. Anything measuring the tooling rather than the work is answering a different question, however precise it looks.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Adoption Statistic
A usage figure: sessions, active users, suggestion accept rate (the share of suggestions that developers accept), lines accepted, the share of merged changes containing assisted code. Anthropic positions its own analytics to be read "alongside DORA metrics, sprint velocity, or other engineering KPIs", never instead of them.
Exam context: The tempting wrong answer, precisely because it is the number teams actually hold. A perception survey is the same error in a milder form: it measures sentiment about the tooling, with no baseline either.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Pre-Declared Baseline
The comparison point named before the period being measured begins. Declared in advance it is evidence; reconstructed afterwards it is not evidence, only a claim, because the choice of comparison was made with the result already visible.
Exam context: The honest answer also states the limit: a same-period comparison shows whether the numbers moved, not why they moved. An option that names the cause from a before-and-after comparison alone claims too much.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Cheap Check
A fast, objective pass or fail on an output: a test suite, a build exit code, a linter, a schema check, a diff against a fixture. Its presence is what lets an automated loop finish without a human taking part, and Anthropic's guidance is to give the agent "a check it can run" before letting it work.
Exam context: The sorting question for any task in a scenario is what checks this cheaply. Work whose correctness only an experienced human can judge, slowly, is the worst candidate for automation rather than the most valuable.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Verification Loop
What a human becomes when the automated work has no check of its own: every mistake waits for someone to notice it. Output then arrives faster than people can judge it, so a review bottleneck that receives automated work becomes a larger review bottleneck.
Exam context: The mechanism behind the counter-intuitive right answer. The painful, unverifiable task feels like the one worth automating first, and it is the one that changes a productivity gain into a longer review queue.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Packaging
Converting a proven individual procedure into a shared, version-controlled artefact. Three consequences make it the exam-relevant half of most workflow answers: outcome quality stops depending on who ran it, improving it once improves it for everyone, and the gain remains when someone resigns.
Exam context: The half of the right answer that is easy to miss. An option that measures the improvement honestly but leaves the winning procedures in individuals' memories is second-best for exactly this reason. It is written to catch candidates who are close to the pass mark.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Reuse Unit
The form a packaged practice takes, chosen by what is being reused: a repeatable procedure becomes a shared workflow anyone can invoke by name, a recurring specialist task becomes a defined role with its own instructions and restricted tool access, and a recurring context need becomes shared project context rather than four private copies.
Exam context: Naming the unit is part of the answer. "Write it down somewhere" is not packaging, because nothing inherits a document and nothing reviews it.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Independent Review
Review performed by something that does not share the author's context. Whatever produced a change still holds the assumptions it wrote it under. It will confirm its own reasoning back fluently. So review runs in a fresh context or with a different reviewer. Anthropic's docs say such a reviewer "isn't swayed by the reasoning that produced the code".
Exam context: Self-review presented as review is a wrong option that appears often. The reviewer has its own failure mode too. A reviewer prompted to find gaps will report some even when the work is sound. So scope it to correctness and stated requirements rather than taste.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Merge Authority
The decision to land a change, kept with a human. Machine review contributes a signal rather than a verdict: Anthropic's managed review "never approves or blocks the pull request", and its check run does not conclude as a failure.
Exam context: The balance the exam rewards. One extreme option removes the human entirely. The opposite extreme requires a human to retype every generated change. Both discard judgement, and neither is ever the answer.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Reversibility Leash
The rule that autonomy is set by how cheaply an action can be undone, not by how much the team trusts the tooling. Limit what automation may execute, gate irreversible actions behind an approval, protect the branches that matter, and let continuous integration be the objective check that no confident explanation can override.
Exam context: Unattended runs are where the restriction matters most, which is why broad, long-lived credentials offered as a way to make work easier are always wrong: they make the work easier by removing the control.
See also: 7.2 AI-Assisted Developer Workflows: Measure the Work, Package the Practice
Evidence Before Change
The first move when a production agent misbehaves: read what actually happened — the inputs, the retrieved context, the tool calls and their results, the outputs, and the versions in use — before altering anything. A fix applied before the failure is understood usually changes something and occasionally fixes something. Such a fix always destroys the evidence.
Exam context: The answer that is most reliably right in the domain, and its tempting wrong answer is the one the exam includes most reliably: rewriting the prompt or the shared instructions first, when nothing yet implicates them.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Containment
Stopping ongoing harm, as a decision separate from diagnosis: revert to the last known-good version, disable the offending capability, or make the action wait for an approval. It gives the team time and it is not a diagnosis, because a reverted system no longer shows the failure, and the failure is not understood.
Exam context: Containment offered where there is no ongoing harm is a wrong option. Containment that reverts everything at once carries a second cost the exam tests: several changes reverted together leave nobody able to say which one was responsible.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Blast Radius
The test that decides whether to contain or diagnose first. An external effect still accumulating — money moving, messages sent, records altered outside the team's control — gets contained immediately. When a degradation is internal and reversible, it is more useful to keep it as evidence than to restore the system.
Exam context: Read the question for what the failure is doing outside the team, and ignore how uncomfortable it sounds. Discomfort is not blast radius, and a rollback destroys the failing cases as soon as it is applied.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Change Stream
One of the versioned inputs that can change a system's behaviour: prompt and instruction versions, model versions, corpus refreshes, configuration changes, dependency and connector updates. Each needs a version and a recorded deployment time to be usable in an incident.
Exam context: "What changed, and when did the symptom start" narrows the search before a single trace is opened, and it does so without touching the system. A stream with no recorded deployment time cannot be correlated against anything, so versioning is a capability the team needs to run the system, rather than tidiness.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Isolation by Removal
The technique of removing variables until the behaviour changes, then reintroducing them one at a time to find which one is responsible. It is Domain 4's one-variable rule arriving in an incident, and it is why two changes deployed in the same time window are tested separately rather than reverted together.
Exam context: The discipline that separates the right answer from the plausible wrong one when a question gives you two recent changes. Reverting both may restore behaviour while showing nothing about the cause.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Agent Hypothesis
An agent's account of its own behaviour. The account is fluent and coherent. It is generated from the same context that produced the behaviour, and it holds no privileged access to the cause. Useful as a hypothesis to test, never as a finding, and unusually persuasive because it is well written.
Exam context: The investigation cycle ends when a human confirms it against the trace. Non-determinism decides what counts as confirmation. One clean re-run does not clear a hypothesis, and one failing run does not prove it. So the confirmation is a pattern across collected cases.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Access Gap
The difference between what an investigation plan assumes and what the person on call actually holds at 2am: trace visibility, rollback rights, an approval that only moves in office hours. The team creates or removes it by design, well before any incident.
Exam context: This is the half of the objective that belongs to Domain 7 rather than Domain 4. An on-call engineer without trace access has no first move, and no amount of diagnostic discipline compensates for it.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Incident Artefact
What an incident leaves behind so that the system becomes more resilient after each incident: a fix verified against the case that actually failed, a regression case added to the suite, a runbook update written while the gap is recent, and any access gap the incident exposed either closed or recorded.
Exam context: The trap for candidates who nearly pass is the option that ships the fix and closes the ticket. It stops one step before the end. When an incident is closed with no artefact, the team pays its full cost a second time, under a new ticket number.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change