8 Developer Productivity & Operational Enablement (7%) · CCAR-P

What the exam tests: rolling out Claude tooling, especially Claude Code, to engineering teams in a way that is secure, consistent, and measurably useful, and using it for debugging and operations. Official task statements: configure Claude tools and environments for teams, such as Claude Code; improve developer workflows with AI-assisted tooling; support debugging and operational issue resolution.

Configuring Claude Code for a team

Claude Code reads configuration at several levels. Know which level wins and what belongs where.

Project (shared) .claude/settings.json and CLAUDE.md committed to the repo

Team conventions, build and test commands, allowed tools,

hooks, shared MCP config (.mcp.json)

Project (local) .claude/settings.local.json, gitignoredPersonal overrides for one repo User ~/.claude/ settings and CLAUDE.md Personal preferences across projects Key controls:

CLAUDE.md gives Claude project memory: architecture notes, commands, coding standards, things to avoid. Keep it short and current; it is loaded into every session. Permissions use allow, ask, and deny rules for tools, commands, and file paths. Deny reading secrets (for example .env files), and require approval for risky commands such as deploys or force-pushes. Hooks run your own scripts at lifecycle events (before or after a tool call, at session start or stop). Use them for deterministic enforcement: block edits to protected paths, run format-

ters and linters, log actions for audit. A hook is guaranteed to run; an instruction in CLAUDE.md is only guidance.

MCP servers connect issue trackers, docs, observability, and databases. Approve them centrally, scope credentials, prefer read-only for production data. Subagents, skills, and custom commands package repeatable workflows (code review, migration, release notes) so the whole team runs them the same way. Sandboxing limits file system and network access for autonomous runs.

Improving developer workflows

High-value uses: understanding unfamiliar code, writing and running tests, refactors and migrations across many files, code review, documentation, and incident write-ups. Patterns that work:

Plan, then act. Ask for a plan, review it, then let Claude implement and run tests. Tests as the contract. Give Claude a failing test or a verification command so it can check its own work.

Headless automation. Run Claude Code non-interactively in CI for tasks such as triaging failures, fixing lint, or reviewing pull requests, with tightly scoped permissions and human review before merge.

Parallel work. Separate git worktrees or sessions let several tasks run without collisions.

Rollout and measurement

Pilot with a volunteer team, publish a starter CLAUDE.md and settings template, run short training on good prompting and review habits, then expand. Measure lead time, review turnaround, change failure rate, and developer satisfaction, not lines of code generated. Keep humans accountable for what merges.

Debugging and operations

Claude helps on call by reading logs, traces, and recent deploys through approved tools, forming hypotheses, and proposing fixes or rollback. Keep production access read-only by default, require human approval for any change, and capture the session for the post-incident review. For Claude-powered systems themselves, the runbook covers provider rate limits and errors (retry with backoff, queueing, fallback region or platform), quality regressions (roll back the prompt or model version), and cost spikes (per-feature budgets and alerts).

Deep dive: enabling teams at scale

The AI platform team

Once more than two or three teams build with Claude, a platform team pays for itself. Its job is to make the right way the easy way.

Platform capability What teams get

Model access gateway One place to get credentials, quotas, routing, caching, and cost attribution Approved MCP servers Reviewed connectors to enterprise systems, ready to use Retrieval service Shared ingestion, indexing, and permission-aware search Evaluation harness A standard way to define cases, run graders, and gate releases in CI Observability Tracing, dashboards, and alerts preconfigured

Guardrail library Input and output checks, PII redaction, injection screening Templates and golden

paths

Starter projects for common patterns (RAG assistant, extraction workflow, agent with approval steps)

Prompt and skill library Shared, versioned prompt modules and skills Office hours and reviews Architecture review, launch readiness checks The platform team does not build every product. Product teams own their use cases; the platform makes them faster and safer.

Golden paths

A golden path is a supported, documented way to build a common type of system. For example, "internal knowledge assistant" might include: a project template, the retrieval service configured with permission filters, a standard system prompt module, an evaluation set skeleton, dashboards, and a launch checklist. Teams that follow the path get faster approval because the controls are already in place.

Extending Claude Code for a team

Mechanism Use for Example

CLAUDE.md Project knowledge and conventions Build commands, architecture notes, coding rules Custom slash com‐

mands

Repeatable prompts a person triggers "/review-security", "/write-release-notes" Subagents Specialized helpers with their own instruc‐

tions and tool access
A test-writing subagent; a code-review subagent
with read-only tools

Skills Packaged expertise loaded when relevant Company API style guide; migration procedure Hooks Deterministic automation at lifecycle events Format on edit; block writes to protected paths; audit logging

MCP servers Connections to tools and data Issue tracker, docs, observability Plugins Bundles of the above, shared across teams A "payments engineering" plugin with commands, skills, and hooks

DEVELOPER PRODUCTIVITY & OPERATIONAL ENABLEMENT (7%)

Check the current Claude Code documentation for exact capabilities and configuration, since these features evolve.

Cost and usage controls

Attribute usage to teams and projects through separate keys, workspaces, or gateway tags. Set budgets and alerts per team; review the top consumers monthly.

Make model choice deliberate: defaults that fit most work, with access to more capable tiers for tasks that need them.

Watch for runaway automation (CI jobs or agents in loops) with spend limits per job.

Onboarding new engineers

A good onboarding path covers: the company's policy on AI use; how to set up Claude Code with the team's configuration; how to write a good task request; how to review AI-generated changes (correctness, security, tests, style); and where to get help. Measure time to first merged change for new engineers before and after.

Worked example 8.1: a team configuration for Claude Code

Brief. A 60-engineer payments team is adopting Claude Code. Security requirements: no reading of secrets, no direct pushes to the main branch, no production database access, and an audit trail of commands run.

Enterprise managed settings (deployed by IT, cannot be overridden). A sketch of the shape; confirm exact keys and syntax in the current Claude Code settings documentation. {

Project settings (committed to the repo).

"hooks": [{ "type": "command", "command": ".claude/hooks/format-and-log.sh" }]

}
]
}
}

Project CLAUDE.md (excerpt).

# Payments service

- Build: npm run build. Test: npm run test. Lint: npm run lint.

- Money amounts are integers in minor units (cents). Never use floats.

- All database access goes through src/db/repository.ts.

- Every change to src/ledger/ needs a test in tests/ledger/.

- Do not edit generated files in src/gen/.

Why this split. Security rules that must never be broken live in managed settings, where users cannot override them. Team conventions live in the repository so they are reviewed like code. Formatting and audit logging run as hooks because they must happen every time. Coding guidance lives in CLAUDE.md because it is advice, not enforcement.

Worked example 8.2: Claude Code in CI

Brief. The team wants Claude to triage failing builds and propose fixes overnight. Design.

On a failed main-branch build, CI runs Claude Code in headless (non-interactive) mode with a task prompt: read the failure, find the cause, propose a minimal fix, run the tests. It runs in an isolated container with the repository checked out, no production credentials, and network egress limited to the package registry.

Permissions allow reading, editing, and running tests; they deny pushing to protected branches.

Output: a pull request on a new branch with the diagnosis in the description, assigned to the on-call engineer.

A human reviews and merges. Metrics: share of failures with a correct diagnosis, share of proposed fixes merged, time to green.

Worked example 8.3: measuring a rollout honestly

Brief. After three months, leadership asks whether Claude Code is worth renewing for 400 engineers.

Measure Before After Source

Median lead time, commit to production Team's baseline Measured after Delivery pipeline data Pull request review turnaround Baseline After Code host data

Change failure rate Baseline After Incident records

Test coverage on changed code Baseline After CI reports

DEVELOPER PRODUCTIVITY & OPERATIONAL ENABLEMENT (7%)
Measure Before After Source
Developer satisfaction (survey) Baseline After Quarterly survey
Cost per engineer per month n/a Usage reports Billing

Present results with the comparison group (teams that adopted later) if possible, and show both gains and problems (for example, larger pull requests that take longer to review). Avoid vanity metrics such as "lines of code written by AI."

Worked example 8.4: on-call with Claude

Incident. Error rate on the checkout API rises to 4% at 02:10.

How a well-configured assistant helps.

The on-call engineer asks Claude to summarize recent deploys, error logs, and traces for checkout through read-only observability and deployment MCP servers.

Claude finds that a deploy at 01:55 changed a timeout setting, and errors are timeouts to the payment provider.

Claude proposes two options: roll back the deploy, or raise the timeout. It drafts the rollback command.

The engineer approves the rollback; the deployment tool runs it under the engineer's identity. Claude drafts the incident timeline for the post-incident review from the session. What stays human: the decision to act on production, and accountability for it.

Scenario drills

Developers keep pasting API keys into prompts. What two controls help?

A team's CLAUDE.md is 3,000 lines. What is the problem and the fix?

Each developer has configured different MCP servers, some with personal production tokens. What do you standardize?

A team wants Claude Code to run database migrations in production on its own. Your recommendation? Senior engineers say Claude's pull requests are too large to review. What do you change? Answers.

Secret scanning and deny rules for secret files, plus a secrets manager so keys never need to be handled by hand; training on the policy.

It consumes context in every session and buries important rules. Keep it short and current; move detailed procedures into skills or linked docs loaded when needed.

A central list of approved MCP servers in managed or shared project configuration, scoped service credentials or per-user OAuth, read-only for production data.

No autonomous production migrations. Claude prepares and tests the migration in staging; a human approves and runs it in production through the normal change process. Ask for smaller, focused changes in the task prompt and CLAUDE.md, require a plan before implementation, and set a review checklist.

Common traps

Relying on CLAUDE.md text to enforce a security rule that a deny permission or hook should enforce.

Letting each developer configure their own MCP servers with personal production credentials. Measuring adoption by AI-generated line counts.

Giving a CI agent write access to protected branches.

Check yourself

Where do you put an org-wide rule that no one may let Claude Code read .env files? Why use a hook instead of a CLAUDE.md instruction to run the formatter?

Three metrics for a Claude Code rollout?

What access should an on-call assistant have to production by default?

Answers: (1) A deny rule in enterprise managed settings. (2) Hooks run deterministically; instructions can be missed. (3) Lead time, review turnaround, change failure rate (also developer satisfaction). (4) Read-only, through approved tools, with human approval for any change.

DEVELOPER PRODUCTIVITY & OPERATIONAL ENABLEMENT (7%)