CCAR-P - Developer Productivity & Operational Enablement (7% of the exam) - Section 7.1

Configure Claude tools and environments for teams (e.g., Claude Code).

Setting up Claude tooling for a team rather than one person: shared project configuration and instructions committed with the repository, consistent permissions, and shared tool integrations. Candidates should distinguish team-wide configuration from personal settings.

Claude Codeshared project configurationteam versus personal settingspermissions

Practice question for this objective

Free sampleDeveloper Productivity & Operational Enablementmedium

A software company keeps 11 services in one monorepository worked on by six teams. A single root instruction file for Claude Code holds every team's rules. In one month, sessions in the mobile team's display code twice applied the payments team's rule that currency values be stored in minor units, and the payments team reports that other teams' edits keep rewording its section. The company requires that each team's rules apply when Claude Code works in that team's code, and that each team approve every change to its own rules. What should the architect recommend?

ASplit the root instructions into one headed section per team and add a line telling Claude Code to apply only the section for the code it is in
BKeep shared conventions in the root instructions and move each team's rules into an instruction file in its own directory, with that team as required reviewer Correct
CHave each team's engineers keep their team's rules in personal user-level memory, so that only members of that team ever load those rules
DSplit the monorepository into one repository per team, so that each new repository carries its own root instruction file and its own reviewers

In a shared monorepository, scope team-specific instructions to that team's directory and enforce ownership through code review, rather than relying on one global file. Claude Code combines the repository's root instructions with instruction files found in subdirectories, loading a subdirectory's file when it works on files beneath it. Placing repository-wide conventions at the root and each team's rules in that team's directory means the context matches the code being changed, so a payments rule no longer influences mobile display work. Because the files are committed, the repository's existing review ownership can require the owning team to approve every change to its own rules.

Why A is wrong: This is tempting because it tidies the file and states the intent clearly. It is wrong because every team's rules still load into every session, so applying the right section depends on the model obeying an instruction, and the single shared file still lets any team reword another team's section without that team's approval.

Why B is correct: This is correct because Claude Code loads a subdirectory's instruction file when it works on files in that part of the tree, so the payments rules reach payments code and not mobile display code. Making the owning team the required reviewer for its own file meets the approval requirement through the repository's normal code review.

Why C is wrong: This is tempting because it stops the rules leaking between teams. It is wrong because personal memory follows the person rather than the code: an engineer helping in another team's service gets none of its rules, headless runs get none at all, and nobody reviews changes to rules held on individual machines.

Why D is wrong: This is tempting because it gives each team a clean, owned instruction file. It is wrong because it is a large structural migration, affecting builds, dependencies and history, to solve a configuration-scoping problem that directory-level instructions in the existing repository already solve.

See more CCAR-P practice questions, answers explained.

Exam traps in Developer Productivity & Operational Enablement

Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-P bank for this domain.

Rewrite the formatting instruction in capitals at the top of the shared project instructions and repeat it at the end of the file
Why it is wrong: This is tempting because emphasis and repetition can raise how often a model follows an instruction. It is wrong because an instruction remains a request the model may skip, and the 31 percent failure rate shows the current instruction is already unreliable, so the requirement for every edited file is still not met.
Pin every engineer to the smallest, fastest tier through an organisation-managed policy so no session can select a more expensive model
Why it is wrong: This is tempting because it cuts spend fastest and cannot be bypassed. It is wrong because it removes the most capable tier entirely, which breaks the principal engineers' requirement that it stay available for design work and hard debugging.
Run sessions on engineers' laptops with prompts off, and commit project instructions forbidding reads of credential files and external calls
Why it is wrong: This is tempting because the instructions are committed, reviewed and identical for every engineer, so it looks like a shared team control. It is wrong because an instruction shapes what the model is asked to do but does not remove its ability to read the laptop's credentials or open a connection, and with prompts off nothing stops a session that misreads or ignores the rule.

Examworthy is not affiliated with or endorsed by Anthropic. Original, blueprint-aligned practice material only.