Home › Study guides › CCAR-P › Domain 7 › Lesson 7.1

CCAR-P · Domain 7 · 7% of the exam · Lesson 7.1 · 21 min read

Configuring Claude Code for teams: layers, shared setup and policy

Which Claude Code settings layer wins, what a team commits to its repository, what only managed policy can enforce, and how to govern access, models and spend.

Written against objective 7.1 of the official CCAR-P exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

7.1.1 Why 150 laptops need one configuration, not 150

Gloamhart Games runs three free-to-play multiplayer games, built by 150 engineers in 12 teams. Twenty of them piloted Claude Code for a month. Then Oriol, the head of security, read the pilot notes. One engineer had switched off permission prompts because they slowed him down. Another had pasted a personal database token into a config file. A third found that Claude had read a .env file holding a staging password, and nobody could say which laptops held production ones.

Sunniva, the lead architect, must now roll it out to everyone, and three groups want different things. Security sets two hard requirements: no one can read production secrets or push to main through Claude Code. The teams want their own commands and their own MCP servers (MCP, the Model Context Protocol, is the standard way to connect Claude to tools such as a build farm). Finance wants to see the cost, team by team.

The difficulty is that Claude Code is not a central service you configure once. It runs on each developer's machine, reads their files and runs commands in their terminal, and by default each person sets it up alone. Left that way, 150 laptops become 150 different tools, and nobody can prove what is enforced. The fix is layered configuration. Claude Code reads settings from several places: the organisation's policy at the top, the team's repository files below it and each person's preferences at the bottom. Fixed rules decide which value wins.

7.1.2 Which setting wins: layers and permission rules

Here is the question every rollout trips on: when the organisation, the team and a developer all set the same thing, which value wins? The answer is a fixed order across four settings files, plus anything passed on the command line for one session.

When a key is set in several places, the highest layer wins: managed settings, then command-line arguments, then project local, then shared project, then user. Lists are the exception: a list such as the permission allow list is merged across layers, so each layer adds entries without deleting another's. Think of an office building: the landlord's fire regulations bind every tenant, each company sets rules for its own floor, and each employee arranges their own desk. No desk arrangement moves a fire exit.

The keys that matter most are the permission rules, which decide what Claude Code may do without asking. An allow rule lets a tool or command run without a prompt, an ask rule always prompts, and a deny rule blocks it. Claude Code checks deny first, then ask, then allow, and the first match decides. A deny from ANY layer therefore beats an allow from every other layer. When no rule matches, the permission mode decides; by default, Claude Code asks before edits and most shell commands.

For Gloamhart this settles the first design question. If Oriol's rule against reading secret files lived in each repository's .claude/settings.json, any engineer with commit rights could delete it, and new repositories would start without it. In managed settings it binds every session on every laptop the policy reaches.

7.1.3 The team's setup belongs in the repository

Now the opposite problem. Gloamhart's matchmaking team has a /load-test command that drives its test cluster, and an MCP server for that cluster's metrics. In the pilot, each engineer rebuilt both by hand from a wiki page, and no two copies matched. One team's setup is not organisation policy, and it should not live in a wiki either. It belongs in the repository, versioned and reviewed like the code it serves.

The pattern to remember: shared things are committed under .claude/ or at the repository root, and personal things stay out of it. A developer's own instructions go in ~/.claude/CLAUDE.md or a git-ignored CLAUDE.local.md, and an MCP server added for personal use lands in ~/.claude.json (the local or user scope). Unlike settings, CLAUDE.md files never override each other: an organisation-wide one in the managed policy directory, the user's and the project's are all loaded together as context.

Where a team rule goes depends on whether it must happen every time. CLAUDE.md is advice: Claude reads it and usually follows it. A hook is the team's own script, which Claude Code runs at a fixed moment whatever Claude decides, such as a formatter after every edit or a check before every shell command. So "always format after editing" belongs in a hook in .claude/settings.json, not in a CLAUDE.md line that Claude may skip.

Two details make this safe. First, credentials never go in a committed file. A .mcp.json entry can reference an environment variable, which Claude Code expands on each machine, so the repository holds only the variable's name. Look at the Authorization header, and at the :- form that supplies a default URL.

{
  "mcpServers": {
    "loadtest-metrics": {
      "type": "http",
      "url": "${LOADTEST_URL:-https://loadtest.gloamhart.example}/mcp",
      "headers": {
        "Authorization": "Bearer ${LOADTEST_TOKEN}"
      }
    }
  }
}

Second, a repository cannot grant itself power on a new machine. Claude Code applies a project's allow rules and plugin marketplaces only after the developer accepts the workspace trust dialog for that folder, while deny and ask rules apply at once, because they only restrict. In an interactive session it also asks before connecting servers from .mcp.json.

Some tools serve all 12 teams, such as the build farm's MCP server. Copying them into a dozen repositories recreates the drift one level up. Sunniva packages them as a plugin, a bundle of skills, agents, hooks and MCP servers, published in Gloamhart's own marketplace, a git repository that catalogues plugins. The managed policy registers that marketplace on every laptop and switches the build-farm plugin on (the extraKnownMarketplaces and enabledPlugins keys). A plugin that only some teams need is switched on in those teams' repository settings instead.

7.1.4 What only the organisation can enforce, and what Claude Code cannot

Security's requirements are not a team's choice, so they go in managed settings, the policy an organisation deploys above every other layer. Server-managed settings come from the claude.ai admin console on a Teams or Enterprise plan and need no device tooling. An MDM profile (MDM is mobile device management, the tooling that already manages company laptops) is the stronger choice where devices are enrolled, because users cannot change it without admin rights. A managed-settings.json file in a system directory suits machines without MDM, including Linux, where the MDM route does not apply. Gloamhart's laptops are Macs enrolled in MDM, so Sunniva ships the policy as a configuration profile.

Some keys only a managed source can set, and most of them are locks. One, allowManagedPermissionRulesOnly, makes managed permission rules the only ones that count. Another, allowManagedMcpServersOnly, makes the managed allowlist of MCP servers the only one that counts, and strictKnownMarketplaces lists the only marketplaces anyone may install plugins from. In this excerpt of Sunniva's policy, look at the deny list, the disabled bypass mode (the permission mode that skips every prompt) and those last two keys.

{
  "permissions": {
    "deny": ["Read(**/.env)", "Read(**/.env.*)", "Read(**/secrets/**)"],
    "ask": ["Bash(git push *)"],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": { "enabled": true },
  "allowedMcpServers": [{ "serverUrl": "https://*.gloamhart.example/*" }],
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "gloamhart/claude-plugins" }
  ],
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": ["<gloamhart-organisation-uuid>"]
}

Notice what she left out. Managed denies already beat every allow, so she skips allowManagedPermissionRulesOnly and lets teams pre-approve their own build commands. The MCP allowlist admits any server on Gloamhart's internal domain, so teams can run their own, while a third-party server needs a review first.

Now the part that separates an architect's design from a configuration file: Claude Code's controls govern Claude Code; they are not the security boundary. A Bash rule matches the command as Claude writes it, so Bash(git push *) stops git push origin main but not git -C . push origin main. A Read deny stops Claude's file tools and commands that name the file, not a script that opens it. The sandbox narrows the gap: it applies operating-system limits, those Read denies included, to shell commands and every process they start. Yet managed settings bind Claude Code only, not an engineer's own terminal.

So Sunniva removes the root causes where they live. Production secrets leave the laptops: they sit in a vault that only the deployment pipeline can read, and engineers work with staging credentials. And main is protected on the git host, which requires a reviewed pull request for every change, whoever wrote it. Claude Code's rules stay as defence in depth, but the requirement now holds even if a rule is worded wrongly.

7.1.5 Access, models and spend

Finance's request leads to a decision that comes before any settings file: how developers sign in, because the access route decides billing and which controls exist.

Memorise the requirement that decides each row; the feature lists change often.

The spend and model controls follow from the route. On Teams and Enterprise, the admin console's spend report shows usage-credit spend per user and per model, and spend limits cap it for the organisation, a group or one member. Its analytics dashboard tracks adoption rather than spend. On the Console, workspace spend limits cap Claude Code's total. On a cloud provider, the cloud's budget controls cap spend, and a gateway in front of it can attribute and cap spend per user.

OpenTelemetry, the open standard for exporting metrics, works on every route and streams each user's tokens and cost into the organisation's own monitoring. Its exporter settings go in managed settings or a developer's user settings, because Claude Code ignores them in a repository's settings files. For models, a managed availableModels list limits which models anyone can choose, and Enterprise admins can also switch individual models off in the admin console.

Gloamhart picks Claude for Enterprise, because its admin console answers finance without new infrastructure. Seats are a known cost, the spend report shows each user's spend beyond them, and group spend limits give each team a ceiling. Sunniva sets no model restriction, since the requirement was visibility and cutting models would trade away quality nobody has measured. Managed OpenTelemetry export feeds the same figures, grouped by team, into the dashboard Gloamhart already runs.

7.1.6 Onboarding and change control for the shared setup

A configuration that 150 people depend on is a production system, and it changes like one. Teams add skills and servers weekly, so someone must approve each change, and every new engineer must get the current version.

Changes run in two lanes. A change to .claude/, .mcp.json or CLAUDE.md needs a pull request approved by the owning team and by Sunniva's developer-tools team, enforced by a code-owners rule on the git host. The second reviewer asks one question: does this widen what Claude may do? Organisation policy lives in its own repository and reaches a pilot group of laptops a week before the fleet. Shared plugins work the same way, with a stable and an early-access marketplace, each delivered to its own group.

Onboarding becomes a check rather than a copy. A new engineer signs in to Gloamhart's organisation, which the policy pins with forceLoginOrgUUID, clones the team repository and accepts the trust dialog. Three commands prove the setup: /status shows the managed source in force, /permissions lists every rule with the file it comes from, and /mcp shows the connected servers. A managed requiredMinimumVersion stops an outdated Claude Code from starting. When one workstation misbehaves, comparing those commands on two machines is the quickest way to find the drift.

7.1.7 The exam traps

Almost every trap here puts a rule in the wrong layer, or trusts a layer with a job it cannot do.

• ✗ Writing a must-hold rule in CLAUDE.md ("never read .env"). ✓ Use a permission rule in managed settings. CLAUDE.md shapes what Claude tries; permission rules decide what Claude Code allows.
• ✗ Putting organisation policy in each repository's settings, or in an onboarding checklist for personal settings. ✓ Deploy it as managed settings. Any committer can edit a project file, and personal files belong to the developer.
• ✗ Treating a Claude Code deny rule as the security boundary. ✓ Remove the root cause: keep production secrets off developer machines and protect the branch on the git host. Claude Code's rules add depth.
• ✗ Letting each developer set up commands and MCP servers by hand, or committing tokens to save setup time. ✓ Commit skills and .mcp.json with credentials referenced by environment variable; ship cross-repository tools as plugins.
• ✗ Locking everything centrally by default. ✓ Centralise only what must hold for everyone. Team tooling in managed policy makes the central team a bottleneck, and engineers start working around it.
• ✗ An after-the-fact alert as the main control. ✓ Prefer a preventive control where one exists: a deny rule or a missing credential stops the action, while a log only reports it.

7.1.8 Put it together: layer a team's configuration and break it

You now have every piece of the design. To make the layering stick, watch one rule survive in one layer and die in another.

The rest of the domain builds on this setup. Workflow improvement (7.2) turns it into the team's daily routines, such as test-first sessions and automated pull-request review. Debugging and operations support (7.3) uses the same layers to give Claude the logs and traces an incident needs, without write access to production.

Key takeaways

• ✓ Claude Code reads layered settings, managed then command line then project local then shared project then user, and merges list keys across layers.
• ✓ Permission rules are checked deny, ask, allow; a deny in any layer beats every allow, so must-hold rules go where nobody below can edit them.
• ✓ The team's setup (CLAUDE.md, settings, skills, subagents, hooks, .mcp.json) is committed and reviewed like code, with credentials referenced by environment variable and shared tools shipped as plugins.
• ✓ Managed settings, delivered from the admin console, MDM or a system file, carry organisation policy and the locks only they can set.
• ✓ Claude Code's controls are defence in depth, not the boundary: keep production secrets off laptops and protect main on the git host.
• ✓ The access route (Teams or Enterprise, Console, or a cloud provider) decides billing and which spend and model controls exist.
• ✓ Changes go through reviewed pull requests and pilot groups, and every new engineer verifies the setup with /status, /permissions and /mcp.

Check your understanding

4 questions written for this lesson, then one from the CCAR-P question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Settings files and precedence
• Configure permissions
• Set up Claude Code for your organization
• Deploy managed settings
• Connect Claude Code to tools via MCP
• Manage costs effectively
• The CCAR-P exam guide, summarised