Free CCAR-F Claude Code Configuration & Workflows Practice Questions
The Claude Code Configuration & Workflows domain makes up 20% of the Anthropic CCAR-F exam. Practice free questions covering CLAUDE.md configuration, slash commands, hooks, permissions, headless/CI usage, and team-wide settings — each with the correct answer and a detailed explanation.
CCAR-F Claude Code Configuration & Workflows Sample Questions with Answers
Sample Question 1 — Claude Code Configuration & Workflows
A development team needs Claude Code to run `make verify` before proposing changes to a shared repository. Every contributor must receive this instruction after cloning the repository. One developer also wants Claude Code to use concise explanations in all of her projects. Which configuration is MOST appropriate?
- A. Put both instructions in the developer's user-level CLAUDE.md.
- B. Put `make verify` in the project CLAUDE.md and the explanation preference in the user's CLAUDE.md. (Correct answer)
- C. Put both instructions in the project CLAUDE.md and ask other developers to ignore the style preference.
- D. Put `make verify` in a personal slash command and the explanation preference in a directory rule.
Correct answer: B
Explanation: Correct answer (B): The verification command is durable, team-wide repository guidance, so it belongs in the version-controlled project CLAUDE.md. The explanation style is an individual preference spanning projects, so it belongs in the user's CLAUDE.md. Correct configuration scope ensures production workflows are consistently shared without imposing personal preferences on the team.
Why the other options are wrong:
- Option A: A user-level file is appropriate for the explanation preference, but repository verification instructions stored there would not automatically reach every contributor.
- Option C: A project file is appropriate for verification, but committing an individual's presentation preference imposes irrelevant guidance on the entire team.
- Option D: A command could invoke an optional workflow, but mandatory verification guidance and a cross-project personal preference do not fit these scopes.
Sample Question 2 — Claude Code Configuration & Workflows
A team frequently asks Claude Code to prepare database migration checklists for a named service and release identifier. The workflow is optional, should be explicitly invoked with those two arguments, and must be versioned for everyone working in the repository. Which implementation is MOST appropriate?
- A. Create a project slash command under `.claude/commands/` and document the service and release parameters with an argument hint. (Correct answer)
- B. Add the entire checklist workflow to the root CLAUDE.md so it is active during every repository interaction.
- C. Create the command under each developer's `~/.claude/commands/` directory and manually keep the copies synchronized.
- D. Add a path-specific rule matching all source files so the checklist runs whenever application code is examined.
Correct answer: A
Explanation: Correct answer (A): A project slash command is suitable for an optional, explicitly invoked, repository-shared workflow. An argument hint communicates the required service and release inputs. Matching persistence and sharing scope to invocation semantics avoids consuming context on unrelated work and gives the production team one version-controlled workflow.
Why the other options are wrong:
- Option B: CLAUDE.md is suitable for durable instructions, but an optional parameterized workflow should not be loaded into every interaction.
- Option C: Personal commands are useful for individual workflows, but separate user copies are inappropriate when the team needs one shared version.
- Option D: Path rules can conditionally apply file conventions, but examining source code should not automatically trigger an optional release checklist.
Sample Question 3 — Claude Code Configuration & Workflows
A team is creating a reusable Claude Code skill that investigates dependency cycles and returns a report. It needs only repository search and file-reading capabilities. Its extensive exploration should not clutter the main conversation, and it must never edit files or execute shell commands. Which SKILL.md configuration BEST satisfies these requirements?
- A. Run in the main context and use instructions that politely ask the skill not to modify files or run commands.
- B. Run in a forked context and allow every tool so the skill can choose the most efficient investigation method.
- C. Set `context: fork` and configure `allowed-tools` with only the required read and search capabilities. (Correct answer)
- D. Set `context: fork`, allow editing tools, and rely on version control to reverse unintended modifications.
Correct answer: C
Explanation: Correct answer (C): A forked context isolates extensive exploration from the main conversation, while an explicit read-and-search allowlist enforces least-privilege access. This design constrains the skill structurally rather than relying on prompt compliance, reducing accidental production changes and limiting context pollution.
Why the other options are wrong:
- Option A: Prompt instructions may influence behavior, but the main context remains cluttered and tool restrictions are not technically enforced.
- Option B: Forking provides isolation, but unrestricted tools violate the requirement to prevent edits and shell execution.
- Option D: A fork isolates conversation state, but permitting edits and reversing them afterward is weaker than preventing unauthorized modifications.
Sample Question 4 — Claude Code Configuration & Workflows
A monorepo requires React accessibility conventions only for files under `apps/portal/**`. Backend services and Terraform modules use unrelated standards. The team wants Claude Code to load the React guidance only when it works with matching portal files. Which implementation is BEST?
- A. Add the React conventions to the root CLAUDE.md and state that they should be ignored for non-React work.
- B. Create a focused file in `.claude/rules/` with YAML `paths` frontmatter matching `apps/portal/**`. (Correct answer)
- C. Store the React conventions in every frontend developer's user-level CLAUDE.md so backend developers do not receive them.
- D. Create a project slash command that developers must remember to run before opening any portal file.
Correct answer: B
Explanation: Correct answer (B): A focused rule with YAML paths frontmatter conditionally associates the React conventions with the portal subtree. Path-specific loading prevents unrelated backend and infrastructure tasks from receiving the guidance, preserving relevant context and reducing conflicting instructions in a production monorepo.
Why the other options are wrong:
- Option A: Root guidance is shared reliably, but it loads specialized frontend information too broadly and depends on instructions to ignore irrelevant content.
- Option C: User configuration can hold personal preferences, but team coding conventions would become inconsistent and depend on individual setup.
- Option D: An explicit command can support optional workflows, but mandatory file conventions should apply conditionally without relying on developer memory.
Sample Question 5 — Claude Code Configuration & Workflows
A repository requires the same privacy annotation convention for TypeScript files in `services/billing/**` and `packages/customer-records/**`. No other area should receive this guidance. The team wants one maintainable source of truth and conditional loading. Which design is MOST appropriate?
- A. Place the convention in the root CLAUDE.md and identify the two relevant directories in the prose.
- B. Create separate directory CLAUDE.md files containing duplicated copies of the privacy convention.
- C. Put the convention in a user-level file used only by developers assigned to privacy-related work.
- D. Create one focused rule whose `paths` patterns target TypeScript files in both required directory trees. (Correct answer)
Correct answer: D
Explanation: Correct answer (D): A single focused rule can target multiple path patterns, giving the two directory trees one maintainable source of truth while retaining conditional loading. This avoids both repository-wide application and duplicated configuration, reducing the risk that privacy requirements will drift.
Why the other options are wrong:
- Option A: Root instructions can describe scope, but the specialized convention is still loaded more broadly than necessary.
- Option B: Directory-level files could scope the guidance, but duplicated text can diverge and violates the single-source requirement.
- Option C: User-level configuration limits distribution to selected people rather than consistently applying a repository convention to relevant files.
Sample Question 6 — Claude Code Configuration & Workflows
A company must replace its authentication library across 14 services. The change affects token validation, middleware, integration tests, and deployment configuration. Security engineers must review the proposed migration sequence before any files are modified. What should the architect do FIRST in Claude Code?
- A. Use plan mode to explore the impact and produce a migration plan for review before implementation. (Correct answer)
- B. Use direct execution to update one service and infer the remaining migration steps from the resulting diff.
- C. Ask Claude Code to edit all services immediately, then have security engineers review the combined changes.
- D. Create a permanent root instruction requiring the new library and let future sessions migrate files opportunistically.
Correct answer: A
Explanation: Correct answer (A): The migration is cross-cutting, high impact, and subject to approval before modification, making plan mode the appropriate first step. Planning separates discovery and sequencing from execution, enabling security review before production-sensitive changes are introduced.
Why the other options are wrong:
- Option B: A pilot change can sometimes validate an approach, but it modifies files before the required security review and may overlook cross-service dependencies.
- Option C: Reviewing a completed change may work for lower-risk tasks, but it violates the requirement to approve the sequence before modification.
- Option D: Persistent guidance can document a selected standard, but opportunistic migration does not provide an impact analysis or coordinated review.
Sample Question 7 — Claude Code Configuration & Workflows
Developers ask Claude Code to extract invoice calculation logic into a shared module, but nobody knows which jobs call the current implementation or whether downstream code depends on its undocumented rounding behavior. Which approach BEST reduces implementation risk?
- A. Start direct execution in the most recently changed invoice file and fix downstream failures after the refactor.
- B. Add a root instruction saying all invoice calculations must use a shared module, then wait for gradual adoption.
- C. Use plan mode with focused exploration to map callers, tests, and rounding dependencies before proposing the refactor. (Correct answer)
- D. Create the shared module from the ticket description, then ask an independent session to locate incompatible callers.
Correct answer: C
Explanation: Correct answer (C): The affected components and behavioral dependencies are unknown, so focused exploration should precede implementation. Plan mode can map callers, tests, and rounding assumptions before proposing a reviewed refactor. Discovering hidden dependencies early reduces regressions in production financial behavior.
Why the other options are wrong:
- Option A: Test-driven repair after editing can work for localized changes, but beginning before discovering callers risks broad and avoidable regressions.
- Option B: Persistent guidance may express a future standard, but it neither identifies current dependencies nor provides a coordinated migration plan.
- Option D: Independent analysis can be valuable, but implementing from an incomplete ticket before dependency discovery reverses the safer order of work.
Sample Question 8 — Claude Code Configuration & Workflows
Claude Code has produced three different implementations of a shipping-fee function, but each misinterprets edge cases. The product owner can provide exact input/output examples for weight thresholds, remote regions, and free-shipping promotions. The repository has a fast automated test suite. Which workflow BEST supports reliable refinement?
- A. Ask Claude Code repeatedly to make the implementation more robust until the diff appears comprehensive.
- B. Encode the examples as tests, run them, and give Claude Code specific failures for targeted revisions. (Correct answer)
- C. Add a general instruction to CLAUDE.md stating that shipping calculations should handle all edge cases.
- D. Select the shortest implementation and ask reviewers to identify incorrect outputs after deployment.
Correct answer: B
Explanation: Correct answer (B): Concrete examples translated into automated tests create an objective definition of correct behavior. Feeding specific failures back to Claude Code enables targeted iteration instead of subjective improvement requests. This closed feedback loop makes production behavior repeatable and protects edge cases from regression.
Why the other options are wrong:
- Option A: Iterative prompting is plausible, but a vague request such as 'more robust' provides no measurable success criterion.
- Option C: Durable guidance can express broad expectations, but it cannot replace executable examples that verify threshold interactions.
- Option D: Conciseness does not establish correctness, and discovering calculation defects after deployment creates unnecessary production risk.
Keep Practicing
Take the 10-question CCAR-F quick-start test across all 5 domains, or return to the CCAR-F practice test hub for 250+ questions, exam details, and a study plan. Drill the other domains: Agentic Architecture & Orchestration, Claude Code Configuration & Workflows, Prompt Engineering & Structured Output, Tool Design & MCP Integration, and Context Management & Reliability.