Developer Productivity: CCAR-P domain 7 study guide

Domain 7 is Developer Productivity & Operational Enablement, 7% of the CCAR-P exam and its smallest domain. It tests the platform view of Claude Code: how you configure it for a whole engineering organisation, how you improve team workflows with it, and how you find the cause when a session or setup misbehaves.

What the official guide covers

The Claude Certified Architect Professional exam guide (version 1.0, effective July 2026) lists three tasks under Domain 7, "Developer Productivity & Operational Enablement":

Settings layers for a team

Claude Code reads settings from several files. A key set at a higher level overrides the same key lower down:

Two behaviours matter for design. List keys such as permissions.allow merge across files rather than replace each other, unless managed settings set allowManagedPermissionRulesOnly, which makes managed rules the only ones that apply. And permission rules are checked deny first, then ask, then allow, so an allow rule anywhere cannot carve an exception out of a deny rule.

Settings are one part of the team setup. The others have their own CCAR-F pages: shared conventions in CLAUDE.md (3.1 CLAUDE.md hierarchy), rules for parts of the codebase (3.3 Path-specific rules), shared commands and Skills (3.2 Slash commands and skills) and shared MCP servers (2.4 MCP server integration).

Example: organisation policy and team defaults

An organisation's managed file sets the lines no one may cross. It also turns on telemetry, which Claude Code ignores in a repository's settings files.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["registry.npmjs.org", "github.com"]
    }
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317"
  }
}

Each team commits its own defaults in .claude/settings.json:

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "ask": ["Bash(git push *)"]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh" }
        ]
      }
    ]
  }
}

The team's allow rule merges with the policy, so developers run build scripts without prompts, while the managed deny rules and the disabled bypass mode hold in every repository. Note two limits from the documentation. Allow rules in a committed project file apply only after each developer trusts the folder; deny and ask rules apply at once. And a Bash rule matches the command as Claude writes it, so it is not a security boundary around a program; the sandbox, which also blocks the denied read paths for sandboxed commands, closes that gap.

Managed settings also set the spend posture. A managed model sets the model each session starts on, though users can still switch; availableModels is the lock that limits which models /model, --model and the model key can select. effortLevel sets the default effort. Decide these before rollout, because an unmanaged default multiplies across every developer and every request.

Which layer for which requirement

Sharing Skills across teams

How you distribute a Skill decides who gets it and how you fix a bad version.

A plugin's hooks register when it loads and fire on every matching event, not only when its skills run, so read a plugin before you approve it for the marketplace. A shared Skill without an owner and a way back is a risk: one careless edit reaches every team at once. Keep its source in a repository so you can revert and resync.

Improving team workflows

Roll out through people, not an announcement. Give one champion per team access first, let them convert a real workflow, then have them bring in peers in small batches. This avoids two patterns: a few heavy users while everyone else ignores the tool, and teams that never move past asking Claude questions in chat.

• Shared starting point. A committed CLAUDE.md, settings file, .mcp.json and Skills mean a new developer gets the team's setup on clone.
• Plan before large changes. Plan mode suits multi-file changes with design choices (3.4 Plan mode vs direct execution).
• Automate repeatable work. Claude Code runs non-interactively in CI for reviews and checks (3.6 Claude Code in CI/CD).
• Keep exploration out of the main context. Subagents can search a large codebase and return a summary.
• Measure. With OpenTelemetry enabled, Claude Code exports metrics such as session count, commits, pull requests and token usage. Prompt text is redacted by default; logging it is a separate opt-in. Compare teams before and after a change rather than relying on impressions.
• Review AI-written code like any other code. Agree a checklist that every change must pass: tests cover the requirement and edge cases (correctness); inputs are validated, no secrets, least-privilege access (security); it follows team conventions (maintainability); and the person merging it can explain what it does and why (understanding). Automate what you can with tests and evals. Green tests on code nobody understands is how an unvalidated input reaches production.

Debugging and operational issues

The same habit applies to the Claude systems your teams run in production. Teach the path from symptom to cause rather than fixing each incident yourself:

Write each path into a runbook with an escalation route, so the team handles known problems and calls you only for new ones.

Rules that decide exam answers

• Policy goes in managed settings. A requirement that applies to every developer and must not be overridden belongs there, not in each repository or each laptop.
• Deny beats allow everywhere. Teams can add allow rules safely because they cannot override a deny rule.
• CLAUDE.md informs; settings and hooks enforce. A convention can be a note; a ban needs a rule or a hook.
• Commit what the team shares. Settings, .mcp.json, CLAUDE.md and Skills in the repository beat onboarding documents that each developer copies by hand.
• Unattended runs get an allow list, not bypass. dontAsk denies anything not pre-approved; bypassPermissions belongs only in isolated containers.
• Find the layer before changing it. /status, /mcp, /context and safe mode locate the cause before anyone edits a file.

Where it appears in the exam

Developer Productivity & Operational Enablement carries 7% of the CCAR-P exam, the smallest share. The guide's example tool for this domain is Claude Code. Expect a few situations about rolling Claude Code out to many developers, sharing configuration across teams, and finding why a setup or session is not behaving as expected.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A platform team is rolling out Claude Code to 200 engineers. No session may read .env files or use the bypass permissions mode, but each team must be able to allow its own build commands without prompts. Where should the platform team put these rules?

A. Deny rules in every repository's .claude/settings.json, added by a script.B. Deny rules in each engineer's ~/.claude/settings.json, written by the onboarding script.C. Deny rules and disableBypassPermissionsMode in managed settings, without allowManagedPermissionRulesOnly, so team allow rules still merge.D. A section in every CLAUDE.md telling Claude never to read .env files.

Answer: C. Managed settings cannot be overridden, deny rules beat any allow rule, and leaving managed-only rules off lets teams add their own allow rules. A and B can be edited or missed by any team or engineer, and D is guidance Claude may not follow every time.

Question 2

After a team installed a new plugin and an MCP server, Claude Code sessions became slow and keep hitting the context limit. What is the quickest way to find the cause?

A. Reinstall Claude Code on every affected machine.B. Switch the team to a model tier with a larger context window.C. Delete the project CLAUDE.md to free space.D. Run /context to see what fills the window, then restart with claude --safe-mode and re-enable customisations one at a time.

Answer: D. These checks show what is using the context and which customisation causes it. A changes nothing about the configuration, B hides the cause, and C removes useful context without evidence that it is the problem.

Build exercise

1. Draw the settings layers for your organisation and place each existing rule in the layer it belongs to.
2. Write a managed settings file and a team .claude/settings.json like the examples, and confirm with /status which sources load.
3. Add a deny rule in the managed file and an overlapping allow rule in the project file. Check that the deny rule wins.
4. Turn on telemetry to a local collector, run one session and confirm the session count metric arrives.

Practise this topic

• Claude Certified Architect Professional practice exam: free, 20 questions, no sign-up
• Claude Certified Architect hub
• CCAR-P study guide: all topics
• Worked example: CLAUDE.md hierarchy
• Previous topic: Stakeholder Communication and Lifecycle

Sources

• Claude Certified Architect, Professional Exam Guide, version 1.0, effective July 2026 (Anthropic), Domain 7: Developer Productivity & Operational Enablement
• Claude Code documentation: Settings files and precedence
• Claude Code documentation: Configure permissions
• Claude Code documentation: Monitoring
• Claude Code documentation: Troubleshooting