7% of the exam — about 4 of the 63 questions — across 3 sub-objectives.
Domain 7 is roughly four questions and worth about an hour of study. They are gettable, and most candidates leave them because the domain looks peripheral next to architecture and safety.
The framing that helps: this domain is about a team using the tooling consistently, not about an individual being productive with it.
Configure Claude tools and environments for teams (e.g., Claude Code)
The questions are about distribution and consistency. One engineer configuring their own environment is not the scenario; twenty engineers who should behave the same way is.
Configuration that lives in a repository, versioned and reviewed, beats configuration each person sets up locally, for the same reason any shared standard does: it can be changed once and audited. Scenarios describing drift between team members, or a rule everyone was told about and half apply, are pointing at this.
Permissions follow least privilege here as everywhere. A team environment with broad access because it was simpler to grant is a finding, not a design.
From the free practice form
A platform team rolls out Claude Code to 14 engineers and results diverge: some get output that follows the repo's conventions and test patterns, others get generic code that ignores the monorepo structure. Each engineer wrote their own personal notes file for the assistant, and several have none. The engineering manager proposes a mandatory two-hour prompt-writing training. What is the most effective way to make assistant output consistent across the team?
Second question, same objective
One month after a team adopted an AI coding agent under an 'allow everything' policy, two incidents hit: a session ran a destructive database reset while fixing a failing test, and shared transcripts were found to contain production API keys the agent had read from a local .env file. Which TWO changes most directly prevent both classes of incident from recurring?
Improve developer workflows using AI-assisted tooling
The recurring point is that generated work needs a verification step, and the step should be defined rather than assumed. What gets checked, by whom, before it merges.
The trap is measuring output rather than outcome. More code produced faster is not an improvement if review time rises to absorb it, and scenarios that report a productivity gain alongside a growing review queue are describing a cost that moved rather than disappeared.
Match the tooling to work that is genuinely repetitive and well specified. Judgement-heavy work is where assistance helps least and gets proposed most.
From the free practice form
An agent reviews every pull request and pushes fix commits directly to the branch. A subtle regression reached production: the agent's fix compiled and passed the existing tests but silently changed a business rule, and no human ever looked at the commit. The team wants to keep AI in the pipeline. What is the strongest structural change?
Support debugging and operational issue resolution
Debugging an LLM system differs from debugging a deterministic one because it does not crash. It returns something reasonable and wrong, so the first question is what evidence exists at all.
You need the request, the response, and the context around both to reconstruct a single run: which prompt version, which model, what was retrieved, what the downstream system did with the result. A system that cannot answer those cannot be debugged, only guessed at.
Reproducibility is the practical constraint. Sampling makes an identical input produce a different output, so a bug that appears occasionally needs a captured trace rather than an attempt to reproduce it on demand.
From the free practice form
During a sev-2, an on-call engineer pasted a stack trace into an AI assistant, which confidently blamed a caching service. The real cause was a bad upstream deploy. The assistant had no access to deploy history, metrics, or logs. How should the team change its triage workflow?