What this domain tests
7% — the smallest domain, roughly 4 or 5 of the 63 scored items, spread across only three task statements. That makes it cheap to bank: a little over one question per task statement, and the questions are governance and enablement judgment rather than command recall. Do not over-invest here relative to Integration (19%) or Solution Design (17%), but do not skip it — the material is short and the correct answers are consistent.
The recurring frame: you are the architect who has to make a developer tool safe and measurable at organization scale, not the developer using it. Almost every distractor in this domain is something that works fine for one enthusiastic engineer and fails as an organizational control — a convention in a README, a credential pasted into a config file, a productivity number that flatters the rollout.
One calibration note. Tooling surfaces, setting file names, and flags in this space change fast. This module teaches the layering and the decision rules, which are what the exam actually asks about; verify any specific file name, precedence order, or flag against current vendor documentation before quoting it (accurate as of August 2026).
Theory outline
1. Configuring Claude tools and environments for teams (Task 7.1)
Four decisions precede any rollout. An architect who cannot answer these four is not ready to deploy the tool to a team, regardless of how well the pilot went.
| Decision | The question | Who will ask |
|---|---|---|
| Surface | IDE extension, terminal CLI, desktop app, or direct API — and which are permitted | Platform, security |
| Identity and credentials | How are credentials issued, scoped, rotated, and revoked when someone leaves | Security |
| Capability | What is the tool allowed to do by default, and what requires approval | Security, engineering leadership |
| Data handling | What leaves the building, where it is stored, for how long, under which agreement | Legal and compliance |
The data-handling answer is the one to have ready first. It is the question legal asks before any capability discussion, and discovering it late has killed more rollouts than any technical limitation.
The configuration layering principle. Team tooling resolves configuration from several layers: an organization-managed layer, a project layer that is checked into the repository and shared by everyone working in it, and a per-user layer. The managed layer takes precedence specifically so that it cannot be overridden locally.
The architect's job is to put each rule in the right layer:
| Layer | Holds | Example |
|---|---|---|
| Organization-managed | Mandatory controls that must not be locally overridable | Denied commands, blocked network destinations, required approval gates, permitted MCP servers |
| Project (checked in, reviewed) | Conventions shared by everyone in the repository | Build and test commands, architecture notes, house style, project-scoped tool configuration |
| User | Personal preferences | Editor integration, display settings, personal shortcuts |
The anti-pattern is unmistakable once you know the shape: shipping a policy as documentation. "Please don't let it run migrations against staging" in an onboarding wiki is not a control. If a rule matters, it belongs in the layer that enforces it.
Permissions. Tool and command access is governed by a three-state model — allow (runs without asking), ask (prompts for confirmation), deny (blocked). Two design principles pull against each other and the exam tests whether you can hold both:
- Default-deny the dangerous half. Destructive filesystem operations, production credentials, deploys, outbound network calls to unapproved hosts, and anything irreversible start denied or gated.
- Allow the useful loop. Reading files, searching, running the test suite, and building should not prompt. A tool that asks permission forty times an hour gets abandoned, and abandoned tools produce no productivity and no audit trail either.
Both failure modes are wrong answers: blanket-allow leaves no audit story and no blast-radius limit; blanket-deny produces a tool nobody uses, which the exam treats as a failed rollout rather than a safe one.
MCP governance. Model Context Protocol servers extend the tool with third-party capability — and each one is a dependency that carries credentials and network egress. Treat the server list as an approved-dependency problem:
- Maintain a registry of approved servers, with an approval step before anything new is added.
- Keep credentials out of checked-in configuration. Credentials belong in a managed secret store or a vault mechanism that injects them outside the developer's environment, never pasted into a file that lands in version control.
- Scope least privilege per server — a read-only integration for a system of record the tool only needs to query.
- Review project-scoped server configuration like code, because adding a server to a shared repository silently grants that capability to everyone who opens it.
The project conventions file — a checked-in document describing build and test commands, architecture, and house rules — is quietly the highest-leverage configuration a team can adopt. It makes generated code match the codebase instead of matching generic idiom, and because it lives in the repository it is reviewed, versioned, and improved like any other artifact.
2. Improving developer workflows (Task 7.2)
Where the tooling earns its keep. Fit is not uniform, and an architect is expected to say so rather than promise blanket productivity.
| Work | Fit | Why |
|---|---|---|
| Orienting in an unfamiliar codebase | High | Search and synthesis over a large corpus is the core strength |
| Test generation and coverage backfill | High | Mechanical, verifiable by running the tests |
| Mechanical migrations and refactors | High | Repetitive, pattern-driven, verifiable by the build |
| First-pass code review | High | Catches real defects, and a human still gates the merge |
| Documentation and release notes | High | Draft-and-edit is faster than blank-page |
| Incident triage and log correlation | High | Volume reduction under time pressure — see task 7.3 |
| Novel architecture decisions | Low | The judgment and the accountability stay human |
| Security-critical primitives | Low | Cost of a subtle error is disproportionate |
| Anything the human cannot verify | Low | Unverifiable output is a liability, not a productivity gain |
That last row is the general rule the exam keeps returning to: the productivity gain is bounded by the reviewer's ability to verify the output. Work where verification is cheap and mechanical (tests pass, build succeeds, diff is readable) yields real acceleration. Work where verification is as hard as the original task yields the illusion of one.
Session patterns worth teaching a team:
- Give the whole specification up front in a single well-formed request rather than dribbling constraints across a dozen turns. Under-specified prompts revealed progressively produce more rework and more tokens.
- One session, one task. Mixing unrelated work in a single long session degrades relevance and makes the transcript useless later.
- Resume a named session for genuinely continuing work across days.
- Start fresh when prior results are stale. If the files changed underneath a paused session, its earlier reads describe a world that no longer exists — carry the conclusions forward in a written summary instead of resuming stale evidence.
CI integration. Non-interactive invocation lets the tooling run as a pipeline step: automated review comments on a pull request, documentation updates, changelog drafts, triage of failing tests. Design rules:
| Rule | Why |
|---|---|
| Bounded, single-purpose scope per job | A general-purpose agent in CI is an unbounded blast radius |
| Least-privilege credentials from the CI secret store | Pipeline credentials are long-lived and widely visible |
| Output as a comment or artifact, never an auto-merge | Keeps a human in the accountability path |
| An explicit false-positive budget | This is the real failure mode: a reviewer that flags noise gets muted or disabled, and then it protects nothing |
| A cost ceiling per job | A misconfigured loop in CI runs on every push |
The false-positive point is the one most often tested, because it is counterintuitive: an automated reviewer that is too aggressive fails socially rather than technically. Tune for precision at the cost of recall on a CI gate, and put the coverage-first pass somewhere a human is already reading.
Measuring impact. The architect is expected to choose outcome metrics the business already tracks and to establish a baseline before rollout.
| Prefer | Avoid |
|---|---|
| Cycle time from first commit to merge | Lines of code accepted |
| Review turnaround time | Number of prompts sent |
| Escaped defect rate and rework rate | Seats activated |
| Time-to-first-meaningful-commit for new hires | Self-reported satisfaction alone |
| Mean time to resolve incidents | Raw suggestion-acceptance rate |
Two disciplines separate a credible measurement from a marketing number: baseline before rollout, and where possible compare a pilot cohort against a control group rather than comparing the team to its own memory. And beware the acceptance-rate trap — accepted output that gets rewritten in the next sprint has produced churn, not productivity, which is why rework rate belongs next to any acceptance figure.
Enablement is a program, not a license purchase. The pattern that works: a pilot cohort, measured; champions who share what worked; a shared library of prompts, conventions, and Skills so good practice compounds instead of being rediscovered; office hours during the ramp; and onboarding that starts people in the same project conventions file everyone else uses. Expansion follows measurement, not enthusiasm.
Cost controls belong to the architect, not to finance: per-team or per-workspace budgets with alerting, sensible model and reasoning-depth defaults for routine work, caching for shared prefixes, and enough visibility that a runaway loop is caught in hours rather than at the invoice.
3. Supporting debugging and operational issue resolution (Task 7.3)
What the tooling is genuinely good at during an incident: compressing an alert storm into a narrative, correlating symptoms with recent changes, reconstructing a failure path from a stack trace, proposing hypotheses ranked by evidence, drafting a fix with a regression test, and writing the post-incident summary while the details are fresh.
What the architect must put in place so that is safe:
| Control | Why |
|---|---|
| Read-only by default on production investigation paths | Investigation and remediation are different privileges; conflating them means a diagnosis can become an unreviewed change |
| Scoped access to logs and traces, with secrets and personal data redacted at the source | Production telemetry is full of both, and it flows into a transcript |
| No deploy, migration, or write tooling on the incident path | Removes the capability rather than relying on restraint under pressure |
| Human approval for any state-changing action | The accountable person stays in the loop when the system is already degraded |
| A separate, deliberately privileged remediation path | So the safe default does not become a reason to bypass the whole setup at 3am |
Evidence before action is the operating discipline. Require the tool to cite what it based a conclusion on — the specific log line, trace span, or commit — and verify that citation before acting on it. A confident, fluent explanation is not a verified root cause, and a signal that pattern-matches a known failure may have an entirely different cause this time. Restarting the service that "always" fixes this class of alert is exactly how an unrelated root cause survives to recur.
Use fresh context for incidents. A resumed session carrying yesterday's file reads and command output looks authoritative and describes a system that has since changed. Seed a new session with a written summary of what is known instead.
Anti-patterns:
- Automated remediation with no human gate, justified by response time.
- Piping raw production logs containing customer data into a general-purpose workspace with no redaction and no retention answer.
- Treating a plausible explanation as a diagnosis and closing the incident on it.
- Using the investigation session's access to "just fix it," which is how read-only becomes write-in-practice.
- No post-incident capture — the review that turns one outage into a permanent test case is the part that compounds.
Worked problems
Problem 1. An engineering organization is rolling Claude Code out to 200 developers. Security requires that nobody can run deployment commands from the tool and that only approved MCP servers may be connected. The team lead proposes documenting both rules in the onboarding guide and asking developers to configure their own settings accordingly. Assess.
A. Reasonable — developer trust and autonomy scale better than centralized control B. Inadequate — mandatory controls belong in the organization-managed configuration layer, which takes precedence and cannot be overridden locally C. Reasonable, provided each developer signs an acknowledgement of the guide D. Inadequate — the correct fix is to deny all command execution organization-wide
Approach: The signature anti-pattern of this task statement is shipping a policy as documentation. A rule that security owns must live in the layer that enforces it, above anything a developer can edit. Everything else — conventions, preferences — can live lower.
Why the others fail: A and C both leave enforcement to good intentions; an acknowledgement produces a paper trail, not a control. D over-corrects into the other failure mode: denying all command execution removes the read-and-test loop that makes the tool useful, and an unused tool is a failed rollout.
Answer: B
Problem 2. An automated pull-request reviewer runs in CI. In its first month it posted an average of eleven comments per pull request, most of them style preferences and speculative concerns. Developers have started resolving all of its comments without reading them. Select two changes that best address the underlying problem.
A. Tighten the reviewer's scope and raise its reporting bar so it flags defects that would cause incorrect behavior, a test failure, or a security issue — not style B. Increase the frequency of the reviewer so developers see it more often C. Give the reviewer authority to block the merge until every comment is resolved D. Track a precision metric on its findings and tune against it, treating false positives as the primary failure mode E. Remove the reviewer entirely, since automated review does not work
Approach: The failure here is social, not technical: a noisy gate gets muted, and once it is muted it protects nothing regardless of how good its occasional real findings are. The fix is precision — narrow what it reports on a blocking surface, and measure false positives as the metric that matters so the tuning has a target.
Why the others fail: B amplifies the noise. C escalates a tool developers have already learned to ignore into a mandatory obstacle, which converts muting into resentment and rubber-stamping. E discards a capability over a tuning problem — and the same reviewer, scoped for coverage rather than blocking, is valuable in a non-gating context.
Answer: A and D
Problem 3. A director asks the architect to demonstrate the return on a six-month AI tooling rollout. The vendor dashboard reports suggestion acceptance rate and weekly active seats. What should the architect report instead, and what should have been done at the start?
A. Report acceptance rate and active seats; they are the available data and directly reflect usage B. Report business outcomes the organization already tracks — cycle time to merge, review turnaround, escaped defects, onboarding time to first meaningful commit — against a baseline captured before rollout, ideally with a comparison cohort C. Survey developers on whether they feel more productive and report the average D. Report total tokens consumed as a proxy for work performed
Approach: Task 7.2 expects outcome measurement against a pre-rollout baseline. Acceptance rate is the canonical vanity metric — accepted output that is rewritten next sprint shows up as high acceptance and zero productivity, which is why rework and escaped defects belong alongside any acceptance figure. The second half of the question is the part candidates miss: the baseline had to be captured before the rollout began.
Why the others fail: A reports activity, not outcome. C is a useful supplement and a poor primary — sentiment moves with novelty. D measures spend and calls it output.
Answer: B
Problem 4. During a production incident, an on-call engineer wants to use Claude Code to investigate. The service reads from a database containing customer records, and remediation may require a configuration change and a restart. How should the architect have configured the incident path?
A. Full production access, so the engineer can diagnose and remediate in one session without switching contexts B. Read-only access to scoped logs and traces with secrets and personal data redacted at source, no deploy or write tooling on the investigation path, and a separate approved path with human sign-off for the state-changing remediation C. No production access at all; all investigation happens against a staging replica D. Full production access, with all actions logged for review afterward
Approach: Investigation and remediation are different privileges, and the safe design separates them: remove the capability from the investigation path rather than relying on discipline under pressure, and provide a deliberately privileged, human-approved path for the change so the safe default does not get bypassed entirely at 3am.
Why the others fail: A and D put write access on the investigation path — logging is a detective control that tells you afterward what a fluent, confident, wrong diagnosis already did. C sounds safe and is not workable: many production incidents do not reproduce on staging, so this simply pushes the engineer to work around the tooling.
Answer: B
Problem 5. An alert fires that matches the signature of a memory leak the team has seen twice before, and both times a rolling restart resolved it. The assistant, given the alert and recent logs, produces a fluent explanation concluding the same leak has recurred and recommends a restart. What should the on-call engineer do?
A. Restart immediately — the pattern match plus the assistant's agreement is sufficient evidence B. Ask for the specific log lines, metrics, or trace spans supporting the conclusion, verify them directly, and check what changed recently before taking a state-changing action C. Ignore the assistant's conclusion; automated diagnosis is not reliable during incidents D. Restart, and open a follow-up ticket to determine the actual cause afterward
Approach: Evidence before action. A confident explanation is a hypothesis, and a signal that pattern-matches a known failure may have a different cause this time — which is exactly the case a restart would mask while the real fault survives. The discipline is to demand the citation, verify it, and correlate against recent change before doing anything that changes system state.
Why the others fail: A treats fluency as verification. C discards a genuinely useful triage capability rather than using it correctly. D is the most tempting: it restores service and promises rigor later, but a restart destroys the very state that would have identified a different root cause, and the follow-up investigates a system that no longer exhibits the fault.
Answer: B
Exam traps
- Policy shipped as documentation. If a rule matters, it lives in the organization-managed configuration layer that cannot be locally overridden — not in an onboarding wiki, and not in an acknowledgement form.
- Both permission extremes are wrong. Blanket-allow leaves no blast-radius limit; blanket-deny produces an abandoned tool. The right answer denies the destructive and outbound half and allows the read-and-test loop.
- MCP servers treated as features rather than dependencies. They carry credentials and egress: approved-server registry, secrets outside checked-in config, least privilege per server, project-scoped configuration reviewed like code.
- Secrets in checked-in configuration. Any option that pastes a credential into a file that lands in version control is wrong, however convenient.
- Promising uniform productivity. The gain is bounded by how cheaply the human can verify the output — high on tests, migrations, and orientation; low on novel architecture, security primitives, and anything unverifiable.
- Under-specified prompts spread across many turns. Give the whole task up front; scope one session to one task; resume for continuing work; start fresh when prior tool results are stale.
- Auto-merge from a CI agent. Output belongs in a comment or artifact with a human in the accountability path.
- Ignoring the false-positive budget. A noisy automated reviewer gets muted and then protects nothing. Tune for precision on any blocking surface.
- Vanity productivity metrics. Acceptance rate, seats, prompts, and tokens measure activity. Report cycle time, review turnaround, escaped defects, onboarding time, and MTTR against a pre-rollout baseline — and pair any acceptance figure with a rework rate.
- Write access on the incident path. Read-only investigation with redacted, scoped telemetry; a separate human-approved path for remediation. After-the-fact logging is not a substitute for removing the capability.
- Confident explanation accepted as verified root cause. Demand the citing evidence, verify it, and check what changed before running anything that alters system state.
- Raw production telemetry with no redaction or retention answer. Logs are full of customer data, and it lands in a transcript.