Shared-Versus-Personal Test
The single question the configuration objective turns 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 not chaos but quiet divergence, which reads as harmless in a stem. "Tooling preferences are personal" is the planted answer, and it is exactly the reasoning that produced the divergence the stem describes.
See also: 7.1 Team Tooling Configuration: Guidance Versus Enforcement
Scope Layering
The composition of four configuration layers, each fit for a different job by its position in a defined precedence order: organisation-managed, project-committed, personal, and local-uncommitted. The layering is the design; the order is what makes each layer capable of the job assigned to it.
Exam context: Items 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, which is precisely why it is the right home for a control the organisation cannot allow a developer to switch off, and the wrong home for anything a team should be able to evolve.
Exam context: The classic layer mismatch puts organisation-wide policy where a team can change it. The mirror 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: Its rival in the option set 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 distractor commits these "so setup is easier for the team". Anything committed is visible to everyone with repository access and remains in history after deletion, which is why a credential committed once is a credential rotated, not deleted.
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 domain's signature substitution. A stem 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: Keyed answer and distractor 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 surface: restrictive rules merge across scopes rather than override each other, so a denial at any layer stands, and a managed list can be extended but not reduced. A control placed high is therefore a floor, not a default.
Exam context: The planted 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 head, home directory or browser bookmarks.
Exam context: A useful tie-breaker between two plausible options. If the standard survives only because a particular person explains it, the option that commits it wins, and the routing-through-an-experienced-engineer option loses.
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 paid for on 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 a quiet anti-pattern: the important rules get lost in the noise and adherence falls, so a file that says more 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 costs on 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 actual credentials", 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 standing broad credentials as friction removal. Anthropic's stated principle for the whole area is "isolation, least privilege, and defense 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, review latency, 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 keyed 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, 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 planted distractor precisely because it is the number teams actually hold. A perception survey is the same error wearing softer clothes: 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 an argument, 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 claiming attribution from a before-and-after alone is overreaching.
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 close without a human inside it, 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 stem 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. Volume then arrives faster than judgement absorbs it, so a review bottleneck fed by automation becomes a larger review bottleneck.
Exam context: The mechanism behind the counter-intuitive keyed answer. The painful, unverifiable task feels like the one worth automating first, and it is the one that converts a productivity gain into a 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 survives a resignation.
Exam context: The quiet half of the keyed answer. An option that measures the improvement honestly but leaves the winning procedures in individuals' heads is second-best by exactly this margin, and it is written to catch near-passers.
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 and will confirm its own reasoning back fluently, so review runs in a fresh context or with a different reviewer: "A fresh context improves code review since Claude won't be biased toward code it just wrote."
Exam context: Self-review dressed as review is a standing distractor. The reviewer has its own failure mode too, since one 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 posts findings that "don't approve or block your PR", and its check run completes neutrally so it never blocks merging.
Exam context: The balance the exam rewards. One absolute removes the human entirely, and the opposite absolute 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 sized by how cheaply an action can be undone, not by how much the team trusts the tooling. Bound what automation may execute, gate irreversible actions behind an approval, protect the branches that matter, and let continuous integration be the objective gate no confident narration talks past.
Exam context: Unattended runs are where the restriction matters most, which is why standing broad credentials offered as friction removal are always wrong: they remove the friction 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 play — before altering anything. A fix applied before the failure is understood usually changes something, occasionally fixes something, and always destroys the evidence.
Exam context: The most reliably keyed answer in the domain, and its distractor is the most reliably planted: 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 gate the action behind an approval. It buys time and it is not a diagnosis, because a reverted system is quiet rather than understood.
Exam context: Containment offered where there is no ongoing harm is a distractor. Blanket containment 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. An internal, reversible degradation is worth more as evidence than as a restored system.
Exam context: Read the stem for what the failure is doing outside the team, and ignore how uncomfortable it sounds. Discomfort is not blast radius, and the failing cases are spent the moment a rollback lands.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Change Stream
One of the versioned inputs that can move 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, which makes versioning an operational capability rather than tidiness.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Isolation by Removal
The technique of stripping 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 landing in the same window are tested separately rather than reverted together.
Exam context: The discipline that separates the keyed answer from the plausible one when a stem hands you two recent changes. Reverting both may restore behaviour while teaching nothing.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change
Agent Hypothesis
An agent's account of its own behaviour: fluent, coherent, generated from the same context that produced the behaviour, and holding 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 loop closes when a human confirms it against the trace. Non-determinism sets the bar for 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 distance 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. It is designed in or out 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 resilience compounds: a fix verified against the case that actually failed, a regression case added to the suite, a runbook update written while the gap is fresh, and any access gap the incident exposed either closed or recorded.
Exam context: The near-passer trap is the option that ships the fix and closes the ticket, one step short. An incident closed with no artefact is paid for a second time at full price, wearing a new ticket number.
See also: 7.3 Debugging and Operational Resolution: Evidence Before Change