Exam domain covered: D7 — Developer Productivity & Operational Enablement (7%)
Approximate module runtime: 45 minutes of Anthropic learning content
Module 5 in the Exam Context
Domain 7 carries 7% of the exam weight — the smallest domain. But it's one where architects make practical errors in real deployments, so the exam tests precise knowledge rather than broad coverage. The four areas the exam focuses on:
- Skills distribution mechanisms — match the mechanism to the reach and rollback requirement
- Spend posture — what to set before the first bill, not after
- Verification checklist for AI-generated code — all four dimensions, and which one can never be automated
- Runbook structure — symptom → cause → action, and why session anchoring is a trap
Skills Distribution Mechanisms
Four mechanisms distribute Claude capabilities to a team, with different reach and rollback tradeoffs:
| Mechanism | Reach | Rollback | Best for |
|---|---|---|---|
| Org-provisioned | Widest — entire organisation | No native rollback | Baseline capabilities everyone needs |
| Plugin | Group-targeted (team, role, department) | Versioned; rollback supported | Team or role-specific tools |
| Project Skill | Repo-scoped | Scoped to the project | Workflow-specific procedures tied to a codebase |
| API Skill | Programmatic, per-call | Version-pinned | Deterministic, automation-driven usage |
The Reach vs Rollback Tradeoff
The exam asks you to match a distribution requirement to its mechanism:
- "We need every engineer in the company to have access to this" → Org-provisioned (widest reach, but no native rollback — think carefully before distributing this way)
- "We need to roll back to the previous version if this breaks the finance team's workflow" → Plugin (versioned, rollback supported)
- "This procedure is only relevant to the payment-service repository" → Project Skill (repo-scoped)
- "This automation pipeline must always use exactly version 2.1 of this capability" → API Skill (version-pinned, programmatic)
The org-provisioned rollback gap: org-provisioned has the widest reach but no native rollback. If a security issue is discovered in an org-provisioned skill, remediation requires re-provisioning — there is no "rollback to previous version" button. This is a deployment risk that must be considered before using this mechanism for anything other than stable, thoroughly vetted capabilities.
Spend Posture — Set Before the First Bill
Spend posture is the configuration that controls how the team uses Claude before unmanaged usage accumulates. It must be set before the first team member uses Claude, not after the first invoice arrives.
Four components of spend posture:
| Component | What to configure | Why it matters |
|---|---|---|
| Model defaults | Which model tier is the default (not "whatever they choose") | Unmanaged model choice multiplies across every team member — one engineer defaulting to the largest model for every task is an invisible spend multiplier |
| Allowlists | Which capabilities are accessible to which roles | Prevents individuals from enabling high-cost features for use cases that don't warrant them |
| Effort guidance | Prompting conventions that prevent unnecessary token usage | Common patterns: "use concise responses for questions you can answer in < 3 sentences" |
| Spend / rate / per-user caps | Hard limits enforced at the platform level | Provides a safety net when individual guidance doesn't stick |
The exam scenario: a team of 200 engineers begins using Claude without configuring model defaults. After 60 days, the invoice is unexpected. The correct diagnosis is a missing spend posture — specifically, no model default. The correct fix is configuring defaults and caps before the next billing period, not telling engineers to "be more careful."
The Champion-Per-Department Rollout Pattern
Why Direct Batch Rollout Fails
Enabling 50 team members simultaneously across an organisation typically produces:
- Most usage stalls at basic chat (users don't know what Claude can do in their specific context)
- Each person solves the same setup friction independently
- No shared configuration emerges — everyone drifts toward personal setups
- The organisation ends up with 50 personal configurations that can't be maintained or improved collectively
The Champion Pattern
- Enable one champion per team first — give them full access, let them discover and solve the friction for their team's actual workflow
- Capture the champion's solved configuration — CLAUDE.md, MCP connections, permission posture, and prompting patterns — into version-controlled shared configuration
- Seed adoption in batches from that baseline — subsequent team members start from the proven configuration, not from scratch
- Champion absorbs the remaining friction as the rest of the team onboards
This produces adoption at the pace of friction removal, not at the pace of individual discovery.
Shared Configuration vs Personal Configuration
The architectural principle: teams should start from a shared baseline, not from personal defaults.
Shared configuration components:
| Component | What it contains | Where it lives |
|---|---|---|
| CLAUDE.md | Team context, coding conventions, architectural constraints, repo structure | Committed to the repository |
| Tool / MCP configuration | Which integrations are wired and how | Version-controlled configuration files |
| Permission posture | Agreed allowlists and capability limits | Version-controlled; reviewed on change |
A team where every member has a different Claude configuration is a team with no institutional knowledge about how Claude is being used. When a problem occurs ("why did Claude make this architectural decision?"), there is no shared baseline to diff against.
The Verification Checklist for AI-Generated Code
AI-generated code must pass four dimensions before production:
| Dimension | What it checks | Can it be automated? |
|---|---|---|
| Correctness | Does it do what was asked? Does it handle the specified inputs correctly? | Partially — tests and static analysis cover much of this |
| Security | Does it introduce vulnerabilities? (injection, auth bypass, secrets exposure, insecure dependencies) | Partially — SAST tools catch common patterns |
| Maintainability | Can the team read, debug, and extend this code? Does it follow conventions? | Minimally — linters check surface conventions, not architectural fit |
| Human understanding | Does a member of the team actually understand what this code does and why? | Never |
The Human-Understanding Dimension
Human understanding is the dimension that can never be automated away, and it's the one the exam specifically tests.
Why it matters: code that passes all automated checks but that no one on the team understands is the slow-burn failure mode. It goes live, passes CI, and becomes unmaintainable the moment it needs to change — because no one can safely reason about its behavior.
Diligence: this dimension is what the study guide calls "diligence" — taking responsibility for verifying and vouching for AI-generated output. An engineer who ships code they don't understand is not being efficient; they are deferring risk.
The session anchoring trap: the same Claude session that wrote the code cannot be the final reviewer of that code. The model is anchored to its own output and will rationalize rather than critique. Code review must use a fresh session or a human reviewer.
Runbook Structure
A runbook captures the symptom-to-cause-to-action path for recurring operational issues:
Symptom: [observable signal in production]
↓
Cause: [what this signal indicates about the system state]
↓
Action: [specific steps to take, in order]
↓
Escalation: [when to escalate, and to whom]Why the cause layer matters: without it, engineers facing a symptom take actions based on pattern-matching ("last time this error appeared, I restarted the service"). If the underlying cause differs this time, the action is wrong. The cause layer forces the engineer to confirm the diagnosis before acting.
Escalation path: a named definition of who handles what, and when an issue leaves the team. The escalation path is the organisational counterpart to the runbook's technical knowledge. Without it, escalation is improvised — which means during an incident is when the team discovers who to call.
Operational Principles for AI-Augmented Teams
Diagnose before rewrite: when a Claude workflow produces unexpected results, inspect the traces (inputs, retrieved content, tool calls, outputs) before touching the system prompt. The most common cause of unexpected output is unexpected input — not a bad system prompt.
Independent review principle: the same session that wrote the code cannot be the final reviewer of that code. Apply this also to documentation, architectural decisions, and content generated at scale — the producing session is anchored to its output.
Shared runbooks over Slack expertise: operational knowledge that exists only in one engineer's head (or in a Slack thread) is not institutional knowledge. Any issue resolved more than once should be in the runbook.
Module 5 Trap Patterns
Trap 11 — Architectural complexity justified by the wrong reason: in a team enablement context, this appears as distributing org-provisioned skills "because we can afford the platform tier" rather than because the capability belongs to everyone. Reach is a deployment characteristic, not a justification for widest distribution.
Session anchoring in code review: "I asked Claude to review the code it just wrote" is never a valid review step. It looks like a review step and produces review-shaped output, but the model is anchored to its output and will rationalize rather than critique.
Key Rules to Memorise
- Skills distribution: org-provisioned (reach, no rollback) / plugin (versioned, rollback) / project Skill (repo-scoped) / API Skill (version-pinned)
- Spend posture: model defaults + allowlists + effort guidance + spend/rate/per-user caps — set before the first bill
- Champion rollout: enable one champion per team first, capture their config, seed the rest from that baseline
- Verification checklist: correctness / security / maintainability / human understanding
- Human understanding is the dimension that can never be automated away
- Runbook: symptom → cause → action → escalation (cause layer prevents wrong-action pattern-matching)
- Independent review: same session that wrote cannot be final reviewer
- Diagnose from traces before editing system prompts