Practice — CCDV-F Domain 3: Claude Code (3.1%)

8 scenario-based MCQs. Answer key + explanations at the bottom.

---

Q1

You're onboarding onto a monorepo where the team commits a shared CLAUDE.md. Your local checkout differs from everyone else's: your Postgres test database runs on a nonstandard port and you build through a personal wrapper script. Where should these facts live so Claude picks them up in this repo without affecting teammates or your other projects?

A. <repo>/CLAUDE.md, committed alongside the team's shared conventions B. ~/.claude/CLAUDE.md, since the details are personal to you C. <repo>/.claude/CLAUDE.local.md, which stays gitignored D. A subdirectory CLAUDE.md scoped to the packages you work on

Q2

A team wants a nightly job that runs Claude Code non-interactively to summarize the day's test failures, and a downstream script must consume the result programmatically. Which invocation best fits?

A. claude -p "summarize the failing tests" --output-format json with a narrow allow list in settings B. An interactive claude session kept alive on the runner, continued nightly with /resume C. claude -p "summarize the failing tests" with the downstream script regex-parsing the plain text D. claude --permission-mode plan so the pipeline can review the plan before any output

Q3

A CI pipeline invokes claude -p "triage the failing build" --output-format json. The committed .claude/settings.json allows Read(./**) and Bash(npm test:*) and denies Bash(rm:*). During the run, Claude attempts Bash(git log --oneline -20). What happens?

A. The call proceeds — it matches no deny rule, and deny rules are the only thing the permission system enforces B. The call is blocked, and the deny reason is returned to Claude as a message C. Claude Code prompts for confirmation, which the unattended run cannot answer, so the run stalls D. The call is transparently rewritten to the nearest allowed read-only tool

Q4

Your team repeats one review workflow many times a day: an engineer supplies a ticket ID, and Claude pulls the diff for that ticket and checks it against the team's review checklist. Engineers want to trigger it explicitly and pass the ticket ID as an argument; it needs no bundled scripts or resources. Which primitive fits best?

A. A skill, so the model auto-invokes it whenever it detects review work B. A project slash command in .claude/commands/ using $ARGUMENTS for the ticket ID C. A subagent in .claude/agents/ carrying the checklist as its system prompt D. A UserPromptSubmit hook that rewrites any prompt mentioning a ticket

Q5

The repo's CLAUDE.md says "never commit directly to main," yet in long sessions Claude occasionally does it anyway. The team wants a guarantee that cannot be missed while still allowing normal commits on feature branches. Which approach best meets this?

A. Move the rule to the first line of CLAUDE.md and mirror it in ~/.claude/CLAUDE.md B. Add "deny": ["Bash(git commit:*)"] to the repo's .claude/settings.json C. Add a PostToolUse hook on Bash that reverts any commit landing on main D. Add a PreToolUse hook on Bash that checks the current branch and exits 2 to block

Q6

You define a code-search subagent in .claude/agents/explore.md with tools Read, Grep, Glob. Mid-session, after a long discussion of an auth bug, you delegate: "Investigate the files we discussed above." The subagent returns irrelevant results. What is the most likely cause?

A. The tool whitelist omits Bash, so the subagent has no way to run search commands over the repository B. The subagent starts with an empty context, so "discussed above" points at history it never saw C. The description frontmatter never mentions auth, so the wrong subagent type was chosen D. The model override in the frontmatter is too small for multi-file reasoning

Q7

An engineer's terminal crashed halfway through a Claude Code refactor. After recovering and finishing the refactor, they want to start an unrelated bug hunt in the same repo without the refactor's context bleeding in. Which command sequence handles both needs?

A. /resume to continue the interrupted session, then /clear before the unrelated task B. /clear to recover the interrupted session, then /resume before the unrelated task C. Run both tasks in plan mode, since plan mode isolates each task's context automatically D. /resume for both tasks — CLAUDE.md is re-read each session, which prevents context bleed

Q8

During review you find a teammate pasted a live third-party API key into the committed <repo>/CLAUDE.md so Claude can run integration tests. Beyond rotating the key, what is the right configuration fix?

A. Move the key into <repo>/.claude/CLAUDE.local.md, which is gitignored B. Move the key into a PreToolUse hook that echoes it whenever the tests run C. Keep it in CLAUDE.md but wrap it in a comment Claude is instructed to ignore D. Reference it from the env block in settings as "${env:SERVICE_API_KEY}"

Answers

Q1: C. CLAUDE.local.md is exactly the per-user, per-project slot: gitignored, so teammates never see it, but scoped to this repo. The runner-up, ~/.claude/CLAUDE.md (B), is also personal but global — your nonstandard Postgres port would leak into every other project you open. (A) imposes machine-specific facts on the whole team, and (D) scopes by subtree, not by user.

Q2: A. Headless use is -p for one-shot non-interactive runs, and --output-format json returns a stable envelope a script can parse; a narrow allow list keeps the run from blocking on confirmations. (C) is the tempting runner-up — it uses headless mode correctly but loses on parseability, since regexing a free-text transcript is brittle. (B) misuses /resume, which continues a conversation rather than providing scripted output, and (D) plan mode exists for human approval, the opposite of unattended CI.

Q3: C. Permission resolution has three outcomes: deny is evaluated first and blocks, allow skips the confirmation prompt, and anything matching neither triggers a user prompt. git log matches neither list, so the run blocks on a confirmation no one is there to answer — which is why CI guidance pairs -p with an allow list that covers every tool the task needs. (A) is the documented misconception that only denies are enforced; (B) describes what happens to denied calls (or a blocking hook), not unmatched ones; (D) is invented behavior.

Q4: B. A user-invoked, parameterized, stateless prompt template is the definition of a slash command; $ARGUMENTS interpolates the ticket ID. The runner-up, a skill (A), loses on the invocation axis: skills are model-invoked based on their description, while the team explicitly wants engineers to trigger the workflow with an argument — and there are no bundled files to justify a skill. (C) buys context isolation nobody asked for, and (D) hooks are deterministic lifecycle commands, not workflow templates.

Q5: D. CLAUDE.md rules are read by the model and can be missed under long-session dilution, so a guarantee needs the harness: a PreToolUse hook can inspect the actual command and current branch, and exit code 2 blocks the call with stdout sent back to Claude as the reason. This is the documented split — permissions for blanket policies, hooks for context-dependent checks like "which branch am I on." (B) is the runner-up but is a blanket deny that also blocks legitimate feature-branch commits; (C) fires after the commit already happened; (A) is still just a prompt the model can miss.

Q6: B. Subagents run in their own context window and receive only the prompt the parent passes — none of the conversation history — so "the files we discussed above" is meaningless to it. The brief must be self-contained: file paths, symptoms, constraints. (A) fails because Grep/Glob are search tools; (C) and (D) are real frontmatter fields (description, model) but neither explains a subagent that runs yet lacks the referenced context.

Q7: A. /resume continues the prior session — the recovery move after a crash — and /clear resets the session so unrelated work starts with clean context. (B) reverses the two commands' semantics. (C) misstates plan mode, which gates execution behind approval but does not isolate context between tasks. (D) encodes the misconception that CLAUDE.md is session state; it is durable memory re-read at session start, and it does nothing to remove the refactor's turns from a continued session.

Q8: D. Settings' env block with "${env:SERVICE_API_KEY}" resolves the value from the environment at runtime, so the secret never sits in version control or in the context window. The runner-up (A) fixes the git exposure but not the deeper rule — CLAUDE.local.md is still memory loaded into every session's context, and secrets belong in neither prompts nor any CLAUDE.md. (B) hard-codes the secret in config and prints it into the transcript; (C) still commits and loads the key, and "instructed to ignore" is not a control.