Practice — CCAR-P Domain 7: Developer Productivity & Operational Enablement (7%)
8 scenario-based MCQs. Answer key + explanations at the bottom.
Q1
You are leading the Claude Code rollout for a 40-engineer platform organization. Build commands, naming conventions, and a "never edit files under generated/" rule must load automatically in every engineer's session and stay versioned alongside the code they govern. Where should these rules live?
A. In ~/.claude/CLAUDE.md on each engineer's machine, synchronized through a shared dotfiles repository
B. In <repo>/.claude/CLAUDE.local.md, written by an onboarding script when each engineer first clones
C. In <repo>/.claude/CLAUDE.md, committed to the repository
D. In a skill whose description instructs Claude to load the team conventions whenever it writes code
Q2
A team added "always run pnpm lint --fix after modifying any file" to the project CLAUDE.md, yet unformatted code keeps landing — engineers observe Claude following the rule early in a session and skipping it later. Which change makes the behavior non-negotiable?
A. A PostToolUse hook matched to Edit|Write that runs pnpm lint --fix after every file change
B. Moving the rule to the top of CLAUDE.md and labeling it critical and non-negotiable
C. A committed slash command, /lint, that engineers are trained to invoke before every commit
D. An allow entry for Bash(pnpm lint:*) so the lint command runs without a confirmation prompt
Q3
A platform team commits .claude/settings.json with Bash(git push --force:*) in the deny list. A developer, blocked mid-rebase, adds the same pattern to the allow list of their personal .claude/settings.local.json — a file that sits higher in the settings precedence order than the shared file. What happens the next time Claude Code attempts a force push in that repo?
A. The call proceeds without a prompt, because local settings take precedence over project-shared settings
B. The call is blocked, because deny rules are evaluated first and always win over any allow
C. The user is prompted to confirm, because the conflicting allow and deny rules cancel each other out
D. The call proceeds only in non-interactive --print runs, where confirmation prompts are unavailable
Q4
You are designing a nightly CI job in which Claude Code triages the day's test failures and writes a Markdown report; no human is present during the run. In the pilot, the job hung for hours waiting on tool confirmations. Which configuration best fixes the run?
A. Start the job with --permission-mode plan so the agent must propose its analysis before executing anything
B. Configure a blanket allow for every tool so no confirmation prompt can fire during the run
C. Keep the session interactive and have the on-call engineer batch-approve the pending prompts each morning
D. Run claude --print with allows scoped to read-only tools plus the report path, and denies on destructive commands
Q5
An architect wants to give every engineer a repeatable "generate release notes" workflow: the engineer supplies a version tag, and Claude drafts notes from the commit log between that tag and HEAD using an approved template. The workflow must cost nothing in context until someone uses it. Which mechanism fits best?
A. A subagent in .claude/agents/ with git tools, delegated to whenever a release is mentioned
B. A committed slash command in .claude/commands/ using $ARGUMENTS for the tag and backtick shell interpolation for the commit log
C. A skill whose SKILL.md contains the template so Claude auto-invokes it when releases come up
D. A CLAUDE.md section documenting the release-notes procedure for Claude to follow on request
Q6
Six months after adoption, engineers on a monorepo team report that Claude Code has become unreliable at following house rules — it recently edited files under generated/ despite an explicit prohibition, and several other conventions are intermittently ignored. You find the project CLAUDE.md has grown to 3,000 lines, including a pasted-in architecture overview and per-service runbooks. What is the most likely root cause and fix?
A. Missing permission entries — add Edit denies covering generated/ so that rule is enforced mechanically
B. The model tier is too small for a monorepo — move the team's sessions onto a larger model
C. Rule dilution — Claude weights the file's contents roughly equally, so buried rules get missed; trim CLAUDE.md to stable conventions and link out to the docs
D. Cache invalidation — the oversized file churns the prompt cache, so rules fall out of context between sessions
Q7
Security policy requires that no git commit containing credentials may ever be created on a developer machine, including commits Claude Code automates — and when an operation is stopped, Claude should be told why so it can self-correct. Which enforcement design meets both requirements?
A. A PreToolUse hook matching Bash that scans staged changes for secrets and exits with code 2 to block, printing the reason to stdout
B. A PostToolUse hook matching Bash that scans each new commit after creation and reverts it whenever a secret is found
C. A deny rule on Bash(git commit:*) so that all commits must be performed manually by the engineer outside Claude Code
D. A CLAUDE.md rule instructing Claude to run the team's secret scanner before every commit it makes in any repository
Q8
You are the architect for an internal-tools group serving eight product teams. You have built document-generation capabilities — helper scripts, brand templates, and usage instructions — that every team should have available in Claude Code, invoked by the model when relevant, without bloating each session's context. Which distribution approach is best?
A. Add the instructions and script paths to each repo's CLAUDE.md so they load at every session start B. Publish one shared slash command per capability so engineers can invoke each workflow manually C. Define each capability as a subagent so it runs in an isolated context when a team delegates to it D. Package each capability as a skill — SKILL.md plus bundled scripts and templates — distributed via a plugin
Answers
Q1: C. The committed project CLAUDE.md is read automatically at every session start for anyone working in the repo, and it versions with the code it governs. Dotfiles-synced personal memory (A) applies globally to every repo the engineer touches and drifts independently of the codebase. CLAUDE.local.md (B) is gitignored and per-user, so it silently diverges the day after onboarding. A skill (D) is lazy-loaded only when the model judges it relevant — there is no guarantee the conventions load in every session.
Q2: A. Hooks are executed by the harness, not the model, making them deterministic guardrails Claude cannot skip — the operative rule is "hooks > prompt rules for non-negotiable behavior." Repositioning the CLAUDE.md rule (B) keeps enforcement probabilistic; long sessions still dilute it. A slash command (C) just relocates the failure point to human discipline. An allow entry (D) only removes the confirmation prompt — nothing ever causes lint to run.
Q3: B. Deny rules are evaluated first and a denied call never proceeds, regardless of which settings file an allow came from — this is precisely how shared team guardrails survive local overrides. (A) misapplies precedence: file order determines which settings merge in, but deny-first governs evaluation of the merged result. There is no cancel-and-prompt behavior for allow/deny conflicts (C), and non-interactive mode (D) does not bypass denies.
Q4: D. claude --print is the non-interactive mode, and the documented CI pattern pairs it with a narrow allow list (nothing blocks on prompts) plus denies on destructive commands (autonomy stays bounded). A blanket allow (B) also stops the prompts but leaves an unattended agent free to run destructive operations. Plan mode (A) is read-only and waits for a human to approve the plan, so it would stall the job and block writing the report. (C) abandons the automation goal and adds hours of latency.
Q5: B. A user-invoked, parameterized prompt template is exactly what slash commands are for: $ARGUMENTS interpolates the version tag, backticks embed the git log output, and an idle command carries zero context overhead. A skill (C) is invoked by the model rather than deliberately by the engineer, and its description occupies context in every session. A subagent (A) buys context isolation this task doesn't need and offers no parameterized invocation surface. A CLAUDE.md section (D) loads at every session start, paying overhead for an occasionally used workflow.
Q6: C. This is classic rule dilution: Claude weights CLAUDE.md content roughly equally, so a prohibition buried in 3,000 lines gets missed — the fix is trimming to stable conventions and exact commands, linking out to architecture docs instead of pasting them. An Edit deny on generated/ (A) is a sensible mechanical backstop but patches one symptom while every other buried rule stays unreliable. A larger model (B) is a band-aid for an over-stuffed memory file. Cache churn (D) affects cost and latency, not whether rules are followed.
Q7: A. PreToolUse is the only event that fires before the tool call executes, and exit code 2 blocks the action while stdout is sent to Claude as the reason — satisfying both "never created" and "self-correct." A PostToolUse scan (B) runs after the commit exists, so the secret has already been written into history. A static deny (C) kills the automated commit workflow entirely and returns no content-aware reason — permissions are static yes/no checks, hooks are the dynamic ones. A CLAUDE.md instruction (D) is probabilistic and can be skipped.
Q8: D. Skills are the capability-bundle primitive: SKILL.md plus bundled scripts and templates, invoked by the model when the description matches, and lazy — only the description sits in context until invocation — with plugins (or enterprise managed config) as the documented distribution path. CLAUDE.md copies (A) load in full at every session start and drift across eight repos. Slash commands (B) are user-invoked, failing the model-invoked requirement, and cannot bundle files. Subagents (C) provide isolated execution, not a way to package resources and instructions for reuse.