D7 · Developer Productivity & Operational Enablement

This is the smallest domain – 7%, roughly 4 of 63 items – but it is high-yield because the answers are concrete. It tests whether you can configure Claude Code for a team (not just yourself), wire AI into developer workflows and CI, support operations, measure productivity, and run a safe-adoption enablement programme with guardrails. Correct answers favour checked-in, managed, least-privilege configuration over per-developer ad-hoc setup.

Learning objectives

By the end of this page you should be able to:

Configure Claude tooling for teams: managed policies, checked-in settings.json, the CLAUDE.md hierarchy, shared Skills/commands/subagents, MCP server catalogues.
Improve workflows with AI-assisted tooling: code review, test generation, migration, CI integration with headless mode.
Support debugging and operations: runbooks, trace analysis, cost dashboards.
Measure developer productivity meaningfully.
Run enablement programmes with guardrails for safe adoption.

7.1 Configuring Claude Code for teams

Individual configuration does not scale or govern. Teams need shared, versioned, policy-enforced configuration.

The CLAUDE.md hierarchy and settings precedence

Asset	Location	Team practice
Coding standards / context	`./CLAUDE.md` (checked in)	Single source of team conventions; `@path` imports for shared docs
Permissions / hooks / env / model	`.claude/settings.json` (checked in)	`permissions.allow/deny/ask`; deny destructive commands by default
Managed policy	enterprise/managed	Enforce org-wide rules developers cannot override
Skills	`.claude/skills/<name>/SKILL.md`	Shared, progressively loaded capabilities
Slash commands	`.claude/commands/*.md`	Reusable prompts with `$ARGUMENTS`
Subagents	`.claude/agents/*.md`	Own system prompt, tools allowlist, model; isolated context
MCP servers	`.mcp.json` (project scope)	A vetted catalogue; scopes local/project/user

Exam signal

“Standardise across the team / enforce a rule no one can override” → managed policy and checked-in .claude/settings.json + ./CLAUDE.md, not per-developer files. “Personal, don’t commit” → CLAUDE.local.md / settings.local.json.

Least privilege in team config

Set permissions.deny for destructive or out-of-scope actions and keep subagent tools allowlists narrow (D3 least privilege). Secrets go in env/secret managers, never in CLAUDE.md (D5).

Managed-policy settings example (enterprise)

Managed policy is admin-controlled and cannot be overridden by user, project, or local files. Deploy it via your MDM/config-management to the managed settings path so it applies to every developer and every repo.

Because this lives in managed policy, a developer’s settings.local.json allowing Bash(rm -rf:*) has no effect — the managed deny wins.

Shared Skills / commands / subagents catalogue layout

Check a shared catalogue into the repo so every developer inherits the same vetted assets:

Exam signal

‘Every developer should get the same reviewer/skill/MCP set’ → a checked-in .claude/ catalogue (project scope), not per-developer installs. ‘No one may override the security rule’ → managed policy.

7.2 AI-assisted developer workflows

Workflow	How Claude Code helps	Mechanism
Code review	Automated review pass on diffs	Subagent/slash command; CI headless mode
Test generation	Generate/extend unit and edge-case tests	Slash command; Skill
Migration	Large-scale refactors/version migrations	Plan mode → apply; subagents
Codebase exploration	Answer “where/why” questions	Built-in tools; read-only plan mode
CI integration	Non-interactive automation	Headless `claude -p "…" --output-format json\|stream-json` with `--allowedTools`, `--permission-mode`

# Headless code-review step (non-interactive, restricted tools)
claude -p "Review the staged diff for security and style issues; output findings as JSON." \
  --output-format json \
  --allowedTools "Read,Grep" \
  --permission-mode plan

Use plan mode (Shift+Tab) for read-only exploration before making changes, and structured output (--output-format json) so CI can parse results and gate the build.

CI code-review integration (headless Claude Code)

A GitHub Actions job that runs a headless, read-only review on every pull request and posts findings, gating the merge on high-severity issues:

Note the least-privilege posture: read-only tools, plan mode, structured output the pipeline can parse and gate on.

7.3 Operational support: runbooks and trace analysis

Need	Enablement asset
Recover from incidents	Runbooks (D6) with rollback and on-call steps
Diagnose failures	Trace analysis via correlation IDs and span trees (D3)
Control spend	Cost dashboards; `/cost` in Claude Code; token/cost telemetry per team
Repeatable ops tasks	Shared slash commands and Skills for common fixes

AI-assisted operations still respect the guardrails from D5: human approval on irreversible actions, least-privilege tools, secrets out of context.

A runbook / trace-analysis flow

When a Claude-backed feature misbehaves in production, the runbook drives a repeatable diagnosis:

Every step maps to something logged: correlation_id, request_id, model, stop_reason, usage, latency, and the tool sequence. Without those logs the runbook cannot start — which is why telemetry is an enablement prerequisite, not an afterthought.

7.4 Measuring developer productivity

Measure outcomes, not vanity metrics. Lines of code or raw acceptance counts mislead.

Metric	What it measures	Why it matters
Cycle time / time-to-merge	Idea → merged change	Core delivery speed; the headline outcome
Review latency	Time a PR waits for review	AI review passes can cut this materially
Defect escape rate	Bugs reaching production per change	Guards against speed-at-the-cost-of-quality
Change failure rate / rework	Share of changes needing fixes	Detects AI output that looks right but is not
Cost per PR	Token/API spend per merged change	Ties productivity to spend; feeds ROI

Meaningful signal	Vanity metric to avoid
Cycle time / time-to-merge	Lines of code generated
Change failure rate / rework	Number of AI suggestions accepted
Review throughput and quality	Prompts sent
Developer-reported friction removed	Tokens consumed (in isolation)

Exam signal

An option that measures productivity by lines of code or suggestions accepted is the trap; the correct answer ties productivity to delivery outcomes (cycle time, review latency, defect escape, change-failure rate, cost per PR) — the same per-segment, outcome-focused mindset as D4.

7.5 Enablement programmes and safe-adoption guardrails

Rolling AI tooling out to developers is a change-management exercise (D6) plus a safety exercise (D5). Do it in phases and let outcome metrics gate each expansion.

Rollout programme: pilot → champions → scale

Phase	Who	Goals	Exit criteria
Pilot	1–2 volunteer teams	Prove value; author baseline `CLAUDE.md`, Skills, commands, MCP catalogue; establish telemetry	Positive cycle-time/review-latency signal; no unsafe incidents
Champions	Embedded advocates per team	Spread good practice; run office hours; refine shared catalogue; train on limits and review	Champions self-sufficient; standards stable; feedback loop working
Scale	Org-wide	Enforce managed guardrails; onboard remaining teams; monitor outcome + cost dashboards	Adoption targets met; guardrails non-overridable; metrics trending right

Element	Purpose
Onboarding / training	Teach capabilities and limits; how to review AI output
Checked-in standards	`CLAUDE.md`, commands, Skills, MCP catalogue as the shared baseline
Managed guardrails	Policy-enforced permissions/deny lists; no override of critical rules
Champions / office hours	Spread good practice; capture feedback
Phased rollout + metrics	Build trust; measure outcome improvements before expanding
Review discipline	AI output is reviewed like any contribution (human-in-the-loop)

7.6 Hooks and deterministic enforcement for teams

Hooks are the deterministic layer that turns team policy into non-bypassable behaviour. They fire on lifecycle events and, on PreToolUse, an exit code 2 blocks the action.

Hook event	Fires when	Team use
`PreToolUse`	Before a tool runs	Deny destructive commands, enforce policy (exit 2 blocks)
`PostToolUse`	After a tool runs	Lint/format, log, run tests on edits
`UserPromptSubmit`	On each user prompt	Inject context, scan for secrets/PII
`SessionStart`	Session begins	Load project context, print standards
`Stop` / `SubagentStop`	Turn/subagent ends	Verify completion, gate on checks
`PreCompact`	Before compaction	Snapshot state
`Notification`	On notifications	Route to Slack/pager

Hook, not prompt

A team rule like “never force-push” belongs in a PreToolUse hook, not a CLAUDE.md sentence — the same programmatic-enforcement principle as D5’s guardrails. A developer (or the model) can ignore prose; a hook that exits 2 cannot be talked past.

7.7 An enablement programme charter (artefact)

A rollout is a programme with owners, phases and metrics — not an announcement.

Programme risk	Control
Shadow/ungoverned use	Provide the vetted catalogue early; make the paved road the easy road
Unsafe output shipped	Review discipline; PostToolUse tests; CI review gate
Runaway cost	`/cost`, cost dashboards, per-team budgets/alerts
Guardrail bypass	Managed policy (non-overridable), not project files

7.8 Scenario walkthrough: standardising Claude Code across 15 teams

Scenario. A platform group must roll Claude Code out to 15 teams. Requirements: one coding standard everywhere; a deny-list of destructive commands no developer can override; automated PR review in CI; a shared reviewer subagent and a house-style docs Skill; and a productivity dashboard the director trusts. Today, each developer has ad-hoc personal config and the director wants to measure “lines of code generated”.

Expert reasoning trace.

Non-overridable rules → managed policy. The deny-list and required review hook go in managed/enterprise policy, deployed via MDM — CLAUDE.local.md and project files are overridable and won’t satisfy “no one can override”.
Shared baseline → checked-in .claude/. ./CLAUDE.md (standards), .claude/settings.json (permissions/hooks/env/model), a reviewer.md subagent (read-only, narrow allowlist), a docs Skill, and a vetted .mcp.json catalogue — all in the repo so every team inherits them.
CI review → headless mode. claude -p … --output-format json --allowedTools "Read,Grep" --permission-mode plan, gating merges on high-severity findings. Least privilege: read-only, structured output.
Fix the metric. Reject “lines of code” (a vanity metric). Recommend cycle time, review latency, change-failure/rework rate, defect escape, cost per PR — delivery outcomes.
Roll out in phases. Pilot → champions → scale, gated by outcome metrics and guarded by managed policy.

Why the tempting alternatives are wrong: per-developer CLAUDE.local.md can’t enforce org-wide rules; interactive Claude can’t run in CI; giving the CI agent all tools breaks least privilege; measuring lines of code rewards volume, not delivered value.

7.9 Common misconceptions

Misconception	Reality	Why it matters on the exam
“`CLAUDE.local.md` can enforce a team rule.”	It’s personal and git-ignored; use managed policy for non-overridable rules.	Enforcement stems require managed policy.
“A CLAUDE.md sentence blocks destructive commands.”	Blocking needs a `PreToolUse` hook (exit 2).	Prompt-as-enforcement reappears in D7.
“CI can run interactive Claude.”	CI needs headless mode with restricted tools and structured output.	CI-integration stems test headless flags.
“More tools make a subagent more useful.”	Least privilege: narrow the allowlist to what the task needs.	Over-privileged subagent is a wrong answer.
“Lines of code / accepted suggestions measure productivity.”	Measure delivery outcomes (cycle time, failure rate, cost/PR).	Vanity-metric distractor is common.
“Mandating use drives adoption.”	Enablement + phased rollout + value reporting drives adoption.	Forced-use answers backfire.
“Secrets can live in CLAUDE.md for convenience.”	Secrets belong in env/secret managers, never model-visible config.	Exfiltration-risk trap.

Exam traps in this domain

Trap	Why it is wrong
Per-developer ad-hoc config for a team standard	Doesn’t scale or govern; use checked-in + managed policy
Putting a rule in personal `CLAUDE.local.md` to enforce org-wide	Personal, git-ignored; use managed policy
Giving subagents broad tool access	Violates least privilege; keep allowlists narrow
Secrets in CLAUDE.md or settings	Exfiltration risk; use env/secret managers
Interactive Claude in CI	CI needs headless mode with restricted tools
Measuring productivity by lines of code / accepted suggestions	Vanity metrics; measure delivery outcomes
Rolling out with no training on limits/review	Unsafe adoption; AI output must be reviewed
Skipping cost dashboards / `/cost`	No spend visibility; runaway cost
Ignoring plan mode before large changes	Skips read-only exploration; riskier edits
No override protection on critical policies	Developers can disable guardrails
Enforcing a destructive-command block with a CLAUDE.md sentence	Blocking needs a `PreToolUse` hook (exit 2), not prose
Rolling out as an announcement rather than a phased programme	No pilot/champions/scale; adoption and safety suffer
Assuming exit code 0 from a `PreToolUse` hook blocks a tool	Exit 2 blocks; 0 allows
Onboarding teams without the vetted `.claude/` catalogue	Encourages shadow/ungoverned config
No per-team cost budgets or alerts	Cost can run away unnoticed across teams

Practice questions

Q1 · A platform team wants a coding standard and a set of denied destructive commands enforced across all repos, with no developer able to override them. What is the BEST mechanism? (Select one)

A. Ask each developer to add rules to their CLAUDE.local.md. B. Managed/enterprise policy plus checked-in ./CLAUDE.md and .claude/settings.json with permissions.deny, since managed policy cannot be overridden. C. A shared Slack message with the rules. D. Email the standards quarterly.

Answer: B. Org-wide, non-overridable enforcement is exactly what managed policy provides, with checked-in project config as the shared baseline. Personal CLAUDE.local.md (A) is git-ignored and overridable; Slack (C) and email (D) are not enforcement.

Q2 · A team wants Claude to review diffs automatically in CI. What is the correct setup? (Select one)

A. Run interactive Claude and have a human paste the diff. B. Use headless mode: claude -p '…' --output-format json with a restricted --allowedTools and an appropriate --permission-mode, so CI can parse findings and gate the build. C. Give the CI agent all tools for flexibility. D. Disable permissions in CI to avoid friction.

Answer: B. CI is non-interactive, so headless mode with structured output and restricted tools is correct. Interactive use (A) can’t run in CI; all-tools (C) and disabled permissions (D) violate least privilege.

Q3 · How should a shared, progressively-loaded capability (e.g. a house style for API docs) be distributed to the team? (Select one)

A. Paste it into every prompt. B. As a checked-in Skill (.claude/skills/<name>/SKILL.md) loaded on demand. C. In each developer’s CLAUDE.local.md. D. In a personal settings file.

Answer: B. Skills package reusable capability and load progressively; checking them in shares them across the team. Pasting per prompt (A) bloats context; personal files (C, D) don’t share or govern.

Q4 · A manager proposes measuring AI productivity by counting lines of code Claude generates and suggestions accepted. What is the architect's guidance? (Select one)

A. Those are good primary metrics. B. Measure delivery outcomes — cycle time, change-failure/rework rate, review quality — because lines of code and accepted-suggestion counts are vanity metrics that don’t reflect value. C. Measure tokens consumed instead. D. Don’t measure productivity at all.

Answer: B. Productivity should tie to delivery outcomes, not volume metrics. Lines/acceptances (A) and tokens (C) are vanity signals; not measuring (D) forfeits the ability to demonstrate value.

Q5 · A subagent for codebase exploration is configured with write and shell tools 'just in case'. What is the correct configuration? (Select two)

A. Restrict the subagent’s tools allowlist to read-only exploration tools it actually needs. B. Keep the broad tool set for flexibility. C. Use plan/read-only mode for exploration and grant write access only where a task requires it. D. Put credentials in the subagent’s CLAUDE.md so it can act freely. E. Give it all MCP servers in the catalogue.

Answer: A and C. Least privilege: narrow the allowlist to what the exploration task needs and use read-only/plan mode, granting more only when required. A broad tool set (B) and all MCP servers (E) are excessive agency; credentials in CLAUDE.md (D) is an exfiltration risk.

Q6 · What should a safe developer-adoption programme include? (Select two)

A. Training that covers Claude’s limits and how to review AI output. B. Checked-in standards (CLAUDE.md, commands, Skills, MCP catalogue) plus managed guardrails and a phased rollout with outcome metrics. C. Immediate org-wide mandatory use with no support. D. Removing human review of AI-generated code to move faster. E. Letting each developer add unvetted MCP servers.

Answer: A and B. Safe adoption pairs enablement (training on limits/review) with governed, checked-in standards, guardrails and phased rollout. Forced use without support (C), removing review (D), and unvetted MCP servers (E) are unsafe.

Q7 · Which asset best gives operators visibility and control over Claude spend across teams? (Select one)

A. Lines-of-code reports. B. Cost dashboards fed by per-request token/cost telemetry, plus /cost in Claude Code sessions. C. A quarterly invoice only. D. Disabling logging to save money.

Answer: B. Per-request token/cost telemetry surfaced in dashboards (and /cost) gives real spend visibility and control. LOC reports (A) are unrelated; a quarterly invoice (C) is too coarse; disabling logging (D) removes the very data needed.

Q8 · Before a large automated migration across a codebase, what is the safest first step in Claude Code? (Select one)

A. Apply all changes immediately and review afterward. B. Use plan mode (read-only) to explore and produce a plan, then apply changes with appropriate permissions and tests. C. Give the agent unrestricted write and shell access. D. Skip tests to finish faster.

Answer: B. Plan mode explores read-only and produces a reviewable plan before edits, reducing risk on large changes. Applying blindly (A), unrestricted access (C), and skipping tests (D) all increase blast radius.

Q9 · An enterprise wants a deny-list of destructive commands and a required review hook applied to every developer and repo, immune to local overrides. Where should this live? (Select one)

A. Each team’s project .claude/settings.json. B. Managed policy settings (admin-controlled path), because it cannot be overridden by user, project, or local files. C. Every developer’s settings.local.json. D. A wiki page of guidelines.

Answer: B. Only managed policy is non-overridable and applies org-wide, which is exactly the requirement. Project settings (A) can be overridden per repo and are not guaranteed everywhere; settings.local.json (C) is personal and git-ignored; a wiki (D) is not enforcement.

Q10 · A platform team wants a phased, low-risk rollout of Claude Code across the org. Which sequence best reflects safe adoption? (Select one)

A. Mandate org-wide use on day one to maximise ROI. B. Pilot with 1–2 teams and establish telemetry, then champions to spread practice and refine shared standards, then scale org-wide with managed guardrails and outcome/cost dashboards. C. Let each developer adopt whatever they like with no standards. D. Roll out to everyone but disable review to move faster.

Answer: B. Pilot → champions → scale, gated by outcome metrics and guardrails, is the safe change-management pattern. A day-one mandate (A) and ungoverned free-for-all (C) skip the trust-building and standardisation; disabling review (D) removes the human-in-the-loop safeguard.

Q11 · A Claude-backed feature is misbehaving in production. Which TWO steps belong at the start of the runbook/trace-analysis flow? (Select two)

A. Capture the correlation ID and gather request IDs for the affected session. B. Immediately rewrite the system prompt and redeploy. C. Classify the failure as integration vs model-output using the HTTP status and stop_reason. D. Restart all services and hope it clears. E. Delete the logs to reduce noise.

Answer: A and C. Diagnosis begins by capturing identifiers and classifying the layer from concrete signals (status code, stop_reason) so the right fix is applied. Blind prompt rewrites (B) and restarts (D) skip diagnosis; deleting logs (E) destroys the evidence the runbook depends on.

Q12 · A director asks for a productivity dashboard for AI-assisted development. Which set of metrics should the architect recommend? (Select one)

A. Lines of code generated and number of suggestions accepted. B. Cycle time / time-to-merge, review latency, defect escape rate, change-failure/rework rate, and cost per PR. C. Prompts sent per developer per day. D. Tokens consumed per developer.

Answer: B. These tie productivity to delivery outcomes and cost, resisting gaming and reflecting real value. Lines of code and accepted suggestions (A), prompt counts (C), and raw token consumption (D) are vanity metrics that do not measure delivered value or quality.

Q13 · A platform team must guarantee that `git push --force` is blocked for every developer, unbypassable. Where does this belong? (Select one)

A. A sentence in ./CLAUDE.md. B. A PreToolUse hook (exit code 2 blocks the call) delivered via managed policy so it cannot be overridden. C. A note in each developer’s CLAUDE.local.md. D. A Slack reminder.

Answer: B. Deterministic, non-bypassable blocking is a PreToolUse hook (exit 2) enforced through managed policy. A CLAUDE.md sentence (A) is prose guidance; CLAUDE.local.md (C) is personal/overridable; Slack (D) is not enforcement.

Q14 · What exit code must a `PreToolUse` hook return to BLOCK the tool call? (Select one)

A. Exit 0. B. Exit 2. C. Exit 1 only. D. Any non-zero code prints a warning but never blocks.

Answer: B. A PreToolUse hook blocks the tool when it exits with code 2. Exit 0 (A) allows; the blocking semantics are specifically exit 2, not merely any non-zero (C, D).

Q15 · A platform group is rolling Claude Code to 15 teams and wants low risk. Which sequence and controls are BEST? (Select two)

A. Pilot with 2 teams and telemetry, then champions to spread practice, then scale org-wide. B. Enforce the deny-list and required review hook via managed policy (non-overridable) plus a checked-in .claude/ catalogue. C. Mandate org-wide use on day one to maximise ROI. D. Let each team choose its own unvetted MCP servers. E. Measure success by lines of code generated.

Answer: A and B. Phased rollout plus managed-policy enforcement and a shared checked-in catalogue is the safe pattern. A day-one mandate (C) skips trust-building; unvetted MCP servers (D) break governance; lines of code (E) is a vanity metric.

Q16 · A reviewer subagent for read-only code review is configured with write and Bash tools. What is the correct configuration? (Select one)

A. Keep the broad tool set for flexibility. B. Restrict the subagent’s tools allowlist to read-only tools (e.g. Read, Grep) it actually needs for review. C. Give it all MCP servers too. D. Put credentials in its agent file.

Answer: B. Least privilege narrows the subagent to the read-only tools its task needs. A broad set (A) and all MCP servers (C) are excessive agency; credentials in the agent file (D) are an exfiltration risk.

Q17 · During the enablement pilot, which exit criterion should gate expansion to the champions phase? (Select one)

A. A fixed calendar date regardless of results. B. A positive signal on at least one delivery-outcome metric (e.g. cycle time or review latency) with no unsafe incidents. C. The number of prompts developers sent. D. Lines of code generated by Claude.

Answer: B. Phase gates are outcome-based: demonstrate a delivery-outcome improvement safely before expanding. A calendar date (A) ignores results; prompt counts (C) and lines of code (D) are vanity metrics.

Q18 · A PostToolUse hook is proposed to run tests and formatters after Claude edits files. Is this appropriate, and why? (Select one)

A. No; hooks can only block, never run follow-up work. B. Yes; PostToolUse fires after a tool runs, making it the right place to lint/format and run tests on edits. C. No; testing must be manual. D. Yes, but only in UserPromptSubmit.

Answer: B. PostToolUse runs after a tool completes, which is exactly where post-edit linting/formatting/tests belong. Hooks do more than block (A); automated testing is appropriate (C); UserPromptSubmit (D) fires on prompts, not after edits.

Key takeaways

Configure for teams: managed policy (non-overridable) + checked-in ./CLAUDE.md and .claude/settings.json, not per-developer ad-hoc files.
Share Skills, slash commands, subagents and a vetted MCP catalogue; keep subagent tools allowlists narrow and secrets in env/secret managers.
Wire AI into workflows via headless mode in CI with structured output and restricted tools; use plan mode before large changes.
Support operations with runbooks, trace analysis and cost dashboards (/cost).
Measure productivity by delivery outcomes (cycle time, failure rate, quality), never lines of code or accepted-suggestion counts.
Run safe-adoption enablement: training on limits and review, checked-in standards, managed guardrails, and phased rollout with outcome metrics.
Enforce team rules with hooks (PreToolUse exit 2 blocks; PostToolUse lints/tests) delivered via managed policy, not CLAUDE.md prose.
Run rollout as a programme (pilot → champions → scale) with outcome-based exit criteria, not an announcement.
Keep subagents least-privilege (narrow tools allowlist), secrets in secret managers, and gate expansion on delivery-outcome signals, never vanity metrics.