Claude Certification Guide CCAR-P

Curriculum › Developer Productivity & Operational Enablement · 7% of the exam

Configuring Claude Code for teams

What you’ll be able to do

  • Place each piece of Claude Code configuration at the right scope: managed, project-shared, project-local or user
  • Use permission rules (allow, ask, deny) and managed settings to enforce organizational policy
  • Choose between CLAUDE.md guidance and hooks or permissions for rules that must always hold
  • Share MCP servers, Skills, subagents and commands with a team without leaking secrets
  • Roll out and maintain a team configuration across many repositories

What you need to know

Two kinds of configuration: guidance and enforcement

Claude Code configuration does two different jobs, and most team problems come from confusing them.

  • Guidance shapes what Claude tries to do: CLAUDE.md memory files (conventions, commands, architecture notes), Skills, custom slash commands and subagent definitions. Claude reads and follows it, but following it is model behavior, not a guarantee.
  • Enforcement constrains what Claude is able to do: permission rules in settings files and hooks that run deterministic code at lifecycle events, for example before a tool runs. These hold regardless of how the model interprets a prompt.

The rule of thumb: conventions and context go in guidance; anything that must never happen (reading secrets, pushing to a protected branch, running destructive commands, calling production systems) needs enforcement. "Never read .env files" in CLAUDE.md is a request; a deny rule for those paths is a control.

Scopes and who receives them

Settings files exist at several scopes, and the scope decides who gets the setting and who can override it:

  • Managed (enterprise policy) settings: deployed by IT or platform teams to developer machines. They take the highest precedence and cannot be overridden by users or projects. This is where organization-wide policy belongs.
  • Shared project settings (.claude/settings.json): committed to the repository, so every contributor receives them through version control. Team defaults for that codebase go here.
  • Local project settings (.claude/settings.local.json): per-developer, not committed. Personal tweaks for one repo.
  • User settings (~/.claude/settings.json): one person's defaults across all projects.

Command-line arguments can override for a single session, but not over managed policy. Memory files follow the same logic: project CLAUDE.md (and .claude/rules/ files) travel with the repo, the user file in ~/.claude/ does not. If two developers see different behavior on the same repo, check which files are actually loaded (for memory, /memory; for permissions, /permissions) before rewording anything.

Permissions: allow, ask, deny

Permission rules name tools and, where useful, patterns, such as a specific Bash command prefix or a file path. Deny blocks the action, ask requires confirmation, allow lets it run without a prompt. Deny rules take precedence over allow rules, which is what makes a managed deny list a reliable policy.

Design permissions like any least-privilege policy. Allow narrowly the safe, frequent commands the team actually runs (the test suite, the linter, read-only git commands) so developers are not trained to click through prompts. Deny sensitive paths and dangerous commands at the managed or shared project level. Avoid blanket allows such as "all Bash" to stop prompt fatigue; that trades a minor annoyance for unbounded command execution.

illustrative — shared project .claude/settings.json
{ "permissions": { "allow": ["Bash(npm run test:*)", "Bash(npm run lint)", "Bash(git diff:*)"], "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(git push:*)"] } }

Hooks for checks that must always run

Hooks run your own commands at defined points in Claude Code's lifecycle, for example before a tool call (where a hook can block the call) or after a file edit (where it can run a formatter or a policy scanner). Use them for rules that permissions cannot express as a simple pattern: block edits to generated files, require a ticket reference in commit messages, run a secret scanner on written files. Because hooks are code, they behave the same for every developer and every session, and they can be distributed through project or managed settings.

Sharing capabilities without sharing secrets

  • MCP servers: a project-scoped MCP configuration (.mcp.json) can be committed so the whole team gets the same integrations. Reference credentials through environment variables or each developer's own authentication, never inline tokens. Scope each server to what the team needs; a read-only database connection is a different risk from a read-write one.
  • Skills, commands and subagents: put team workflows (a release checklist, a migration procedure, a code-review subagent with read-only tools) under .claude/ in the repo so they are versioned and reviewed like code.
  • Across many repositories: hand-copying configuration into each repo guarantees drift. Package shared Skills, commands, agents, hooks and MCP definitions as a plugin distributed from an internal marketplace, or another single source of truth, and keep organization-wide policy in managed settings.

Rollout as a change, not a memo

Treat team configuration like any platform change: version it, review changes in pull requests, start with a pilot team, document what each rule is for, and collect feedback on blocked actions and prompt fatigue. Over-restrictive settings drive developers to work around them; under-restrictive ones become a security finding.

Key concept

Scope decides who gets a setting and whether it can be overridden; guidance (CLAUDE.md, Skills) shapes behavior while permissions, hooks and managed settings enforce it, so every hard rule belongs in enforcement.

Questions here usually describe a rule that "Claude ignored", an inconsistency between developers, or a security requirement. Ask whether the rule was guidance or enforcement, and whether it lives at a scope that reaches everyone who needs it and cannot be overridden by those who shouldn't.

Practice scenario

ScenarioA platform team rolls Claude Code out to 300 engineers across 120 repositories. Security requires that Claude never read credential files and never push directly to main. The pilot used a long CLAUDE.md stating both rules, each repo has a slightly different copy, and a postgres MCP server is configured in each repo's .mcp.json with a shared service password inline. Engineers complain about constant permission prompts and several have allowed all Bash commands in their user settings.
Work it through, then open this

Move the two security rules from prose to enforcement: deny rules for credential paths and direct pushes in managed settings, so no project or user setting can loosen them. Remove the inline password from every .mcp.json, rotate it, and switch to environment-variable or per-user credentials with a read-only role unless writes are genuinely needed. Replace the per-repo copies with a shared plugin or another single source for common Skills, hooks and MCP definitions, keeping only repo-specific context in each project CLAUDE.md.

Address the prompt fatigue directly by allowing the narrow, safe commands engineers actually run, so the blanket “allow all Bash” workarounds stop being attractive; managed policy can also restrict them.

Build exercise — Audit and restructure a team configuration

Advanced · 45 min

What you’ll learn

  • Separating guidance from enforcement
  • Placing settings at the right scope
  • Removing secrets and drift from shared configuration

  1. List every rule in your team’s CLAUDE.md and settings files and tag each as guidance or must-hold.

    • Why: Must-hold rules expressed only as guidance are the most common gap.
    • You should see: One or more must-hold rules that exist only in prose.

  2. For each must-hold rule, write the deny rule or hook that enforces it and choose the scope (managed or shared project) where it must live.

    • Why: Enforcement at the wrong scope can be overridden or never reaches some developers.
    • You should see: Organization-wide rules in managed settings, repo-specific ones in .claude/settings.json.

  3. Search shared configuration for inline credentials and for duplicated content across repos, and plan a single source of truth.

    • Why: Committed secrets and drifting copies are recurring operational and security findings.
    • You should see: No secrets in version control and a plan to distribute shared pieces from one place.

Exam traps

Writing a security rule into CLAUDE.md and treating it as enforced

Memory files guide behavior but do not guarantee it. Use deny rules or hooks for anything that must never happen.

Putting team conventions in a personal user-level file so they never reach teammates

User-level files are not in version control. Team conventions belong in project files that travel with the repo.

Committing API keys or tokens inside a shared MCP configuration

Anything committed is visible to everyone with repo access and persists in history. Reference credentials through environment variables or per-user auth.

Granting broad allow rules to stop permission prompts instead of narrowing them to safe commands

Blanket allows remove the control entirely. Allow the specific, frequent safe commands and keep prompts for the rest.

Relying on each developer’s settings for a policy that must hold organization-wide

Developer settings can be changed by the developer. Organization policy belongs in managed settings, which take precedence.

Copying the same configuration into every repository by hand so it drifts

Copies diverge and updates are missed. Distribute shared configuration from a single source such as a plugin.

Sources

Quick check

An SRE organization is designing a Claude-based incident-triage assistant. Which design is most appropriate?