QQuibank
中ENES
← Back

16 Claude Code Configuration & Workflows Practice Questions & Answers

Every Claude Code Configuration & Workflows practice question from the Claude Certified Architect – Foundations Practice Test, with the correct answer and a short explanation.

Start practice test →

  1. 1. A team notices Claude Code behaves inconsistently across developers: some members get the right build and test commands suggested, others do not, because each person keeps those conventions in their own ~/.claude/CLAUDE.md. What is the recommended fix for this configuration drift?

    • A.Ask every developer to manually copy the same text into their personal ~/.claude/CLAUDE.md
    • B.Point everyone's editor at a shared network drive that hosts a single CLAUDE.md
    • C.Move the shared conventions into a CLAUDE.md at the project root and commit it to version control✓ Answer
    • D.Store the conventions in each developer's .claude/settings.local.json

    Project-level CLAUDE.md lives in the repository, so it is versioned with the code and loaded automatically for every teammate who works in that repo, eliminating drift. User-level ~/.claude/CLAUDE.md is per-machine personal memory, which is exactly why copies of it fall out of sync; settings.local.json holds local harness settings, not instructions/memory.

    Source: Claude Code docs — Manage Claude's memory: project memory (./CLAUDE.md, checked into source control, shared with team) vs user memory (~/.claude/CLAUDE.md, personal); CCA-F Exam Guide Domain 3Report a problem with this question

  2. 2. Inside a project's CLAUDE.md, a line reads: @docs/conventions.md. According to the CLAUDE.md import syntax, what does this line do?

    • A.It tells Claude to treat docs/conventions.md as the first file to edit in every session
    • B.It imports the contents of docs/conventions.md into Claude's context as part of the memory, with imports resolving recursively up to a maximum depth of 5 hops✓ Answer
    • C.Nothing — lines starting with @ are treated as comments in CLAUDE.md
    • D.It creates a clickable reference that Claude will only open if the user explicitly asks about that file

    CLAUDE.md supports an @path/to/file import syntax that pulls the referenced file's contents into context as if it were part of the memory file itself; imported files can import others, up to a maximum depth of 5 hops. Note that @ references are not evaluated inside code spans or code blocks, which is why they are not mere comments or lazy links.

    Source: Claude Code docs — Manage Claude's memory: CLAUDE.md imports (@path syntax, recursive imports, max depth 5 hops, not evaluated inside code spans/blocks)Report a problem with this question

  3. 3. A monorepo has a CLAUDE.md at the repository root and another CLAUDE.md inside packages/api/. When does the content of packages/api/CLAUDE.md get included in Claude's context?

    • A.Never — only the repository root CLAUDE.md is ever read
    • B.On demand, when Claude works with files inside that subdirectory✓ Answer
    • C.Always at session launch, at the same time as the root CLAUDE.md
    • D.Only if the root CLAUDE.md explicitly imports it with @packages/api/CLAUDE.md

    CLAUDE.md files in subdirectories are loaded on demand — Claude pulls them in when it reads or edits files under that subtree — rather than all being loaded up front at launch. This keeps context focused: directory-specific guidance only costs tokens when it is actually relevant, while the root CLAUDE.md provides the always-loaded project-wide baseline.

    Source: Claude Code docs — Manage Claude's memory: subdirectory CLAUDE.md files are loaded on demand when Claude works with files in those directoriesReport a problem with this question

  4. 4. A project contains .claude/rules/api-style.md whose YAML frontmatter includes: paths: ["src/api/**/*.ts"]. When does this rule apply?

    • A.When Claude is working with files that match the src/api/**/*.ts glob✓ Answer
    • B.Only when the user runs the slash command /api-style
    • C.Only in headless (-p) runs, since rules are a CI-only feature
    • D.In every conversation, because all files under .claude/rules/ are unconditional

    The paths field in a rule file's YAML frontmatter scopes the rule with glob patterns, so it is applied only when Claude is working with matching files — here, TypeScript files under src/api/. A rule file without a paths field applies unconditionally, which is why option A describes the default for path-less rules, not for this one.

    Source: Claude Code docs — Rules (.claude/rules/): paths glob frontmatter scopes a rule to matching files; rules without paths apply alwaysReport a problem with this question

  5. 5. In the YAML frontmatter of a custom slash command file such as .claude/commands/deploy.md, what does the argument-hint field do?

    • A.It shows the user the expected arguments in autocomplete when they type the command✓ Answer
    • B.It sets a default value that replaces $ARGUMENTS when the user passes nothing
    • C.It restricts which tools the command may call while it runs
    • D.It validates the arguments and rejects the command if they do not match the hint

    argument-hint is purely a usability aid: the hint text (for example "[environment] [version]") is displayed in the slash-command autocomplete so the user knows what to type after the command name. It performs no validation and sets no defaults — the actual values still arrive through $ARGUMENTS — and restricting tools is the job of the separate allowed-tools field.

    Source: Claude Code docs — Slash commands: argument-hint frontmatter field (hint shown in autocomplete; $ARGUMENTS carries the actual values)Report a problem with this question

  6. 6. A team's custom skill performs a long, verbose multi-step analysis, and all of its intermediate output is filling up the main conversation's context window. Which SKILL.md frontmatter setting is designed to solve this?

    • A.paths: ["**/*"] — scoping the skill to all files compresses its output automatically
    • B.allowed-tools: [] — with no tools available, the skill cannot generate intermediate output
    • C.argument-hint — hinting the arguments makes the skill produce shorter responses
    • D.context: fork — the skill executes in a forked context, so only its final result returns to the main conversation✓ Answer

    Setting context: fork in SKILL.md runs the skill in a forked, subagent-style context: all the intermediate tool calls and verbose reasoning happen in that separate context, and only the skill's result is passed back to the main conversation. This isolates the noise and protects the main context window; the other options either cripple the skill (no tools), belong to rules (paths), or are UI hints with no effect on output volume.

    Source: Claude Code docs — Agent Skills: SKILL.md frontmatter context: fork (skill runs in a forked context; only the result returns to the main conversation)Report a problem with this question

  7. 7. What is the purpose of the allowed-tools field in the frontmatter of a custom slash command or skill?

    • A.It is documentation only, telling readers which tools the author expects to be used
    • B.It lists MCP servers that should be installed before the command can run
    • C.It scopes which tools (and tool patterns, such as specific Bash commands) the command or skill may use during its execution✓ Answer
    • D.It permanently grants those tools for the remainder of the session after the command finishes

    allowed-tools is an enforced permission scope, not documentation: it declares the tools — including fine-grained patterns like Bash(git add:*) — that the command or skill is permitted to use while it executes, so those calls can run without extra prompting. The grant is bounded to that execution; it neither installs MCP servers nor extends permissions to the rest of the session.

    Source: Claude Code docs — Slash commands / Agent Skills: allowed-tools frontmatter (scopes permitted tools, incl. Bash command patterns, to the command's execution)Report a problem with this question

  8. 8. Which of these tasks most clearly justifies using plan mode instead of letting Claude Code execute changes directly?

    • A.Refactoring the authentication flow across many files in a codebase you barely know✓ Answer
    • B.Asking Claude to explain what an existing regular expression does
    • C.Renaming a local variable inside one small function
    • D.Fixing a single typo in the README

    Plan mode keeps Claude read-only while it researches the codebase and produces a plan you approve before any edits happen, which pays off precisely when a change is broad, risky, and spans files you do not fully understand — like a cross-cutting auth refactor. For a typo, a local rename, or a pure explanation question, the review overhead buys nothing because the change is trivial or there is no change at all.

    Source: Claude Code docs — Plan mode (read-only research, plan approval before edits; suited to complex multi-file changes); CCA-F Exam Guide Domain 3Report a problem with this question

  9. 9. You are midway through a long refactoring session and the context window is nearly full, but you need to keep working on the same task without losing the key decisions made so far. Which command is the best fit?

    • A./compact, optionally with instructions about what to focus on when summarizing✓ Answer
    • B./memory, which converts the whole conversation into a permanent memory file
    • C./clear, which wipes the conversation so you can start over
    • D.Quitting and restarting the Claude Code process

    /compact replaces the conversation history with a summary, freeing context space while preserving the important state of the ongoing task, and you can steer the summary (for example, /compact focus on the API changes). /clear and restarting both discard the working context entirely, and /memory opens the memory files (CLAUDE.md) for editing — it does not summarize or shrink the current conversation.

    Source: Claude Code docs — Built-in commands: /compact (summarize conversation to free context, accepts focus instructions) vs /clear and /memoryReport a problem with this question

  10. 10. A headless CI job runs claude -p to review pull requests, but it ignores coding conventions that Claude follows perfectly on your laptop. The conventions are written in ~/.claude/CLAUDE.md. What is the most likely cause and fix?

    • A.The -p flag disables all CLAUDE.md loading; add a flag to re-enable memory in headless mode
    • B.~/.claude/CLAUDE.md is user-level, per-machine memory that does not exist on the CI runner; move the shared conventions into the project's CLAUDE.md so they travel with the repository✓ Answer
    • C.CLAUDE.md files are only honored when plan mode is active, which CI cannot use
    • D.CI runners require an --interactive flag before any memory files can be read

    User-level memory lives in the home directory of a specific machine, so a CI runner that merely checks out the repository never sees your laptop's ~/.claude/CLAUDE.md. Project-level CLAUDE.md is committed with the code, which is exactly why team- and pipeline-relevant instructions belong there; headless -p mode still loads project memory normally, so the other options invent restrictions that do not exist.

    Source: Claude Code docs — Memory hierarchy (user memory is per-machine; project memory ships with the repo) + Headless mode (claude -p); CCA-F Exam Guide Domain 3Report a problem with this question

  11. 11. A CI pipeline must call Claude Code non-interactively and receive an answer that downstream scripts can parse and that always matches a fixed structure your team defined. Which invocation is correct?

    • A.claude --interactive --json "..." so the session stays open for follow-up parsing
    • B.claude -p "..." with no extra flags, then grep the plain-text output for the fields you need
    • C.claude -p "..." --output-format json together with --json-schema pointing at your schema, so the result is machine-readable and conforms to the defined structure✓ Answer
    • D.Just add the sentence "respond only in JSON" to the prompt; no flags are needed for reliable parsing

    -p runs Claude Code headlessly (print the result and exit), --output-format json wraps the run in a structured JSON envelope that scripts can parse deterministically, and --json-schema constrains the output to your declared schema so its shape is guaranteed rather than hoped for. Prompt-only instructions like "respond in JSON" are not enforced and can drift, and grepping free text is exactly the fragility these flags exist to remove.

    Source: Claude Code docs — Headless mode / CLI reference: -p (print mode), --output-format json, --json-schema for schema-constrained structured output in automationReport a problem with this question

  12. 12. A stakeholder asks for "some kind of admin dashboard" but cannot articulate concrete requirements. According to iterative-refinement practice with Claude Code, which technique fits best as the first step?

    • A.Run /compact so the reduced context forces Claude to focus on the essentials
    • B.The interview pattern: ask Claude to interview you with clarifying questions and draft a spec before writing any code✓ Answer
    • C.Test-driven iteration: have Claude write failing tests immediately and then implement until they pass
    • D.Few-shot examples: paste several code snippets in your preferred style so the output matches your formatting

    When requirements are vague, the bottleneck is missing information, and the interview pattern attacks exactly that: Claude asks you targeted clarifying questions and turns the answers into a concrete spec you can validate before implementation begins. Few-shot examples shape style and format rather than requirements, test-driven iteration presupposes you already know the expected behavior well enough to encode it in tests, and /compact manages context size, not ambiguity.

    Source: Claude Code docs — Common workflows: iterative refinement techniques (interview/spec-first pattern vs few-shot examples vs test-driven iteration); CCA-F Exam Guide Domain 3Report a problem with this question

  13. 13. A staff engineer maintains a 700-line project CLAUDE.md that mixes testing, security, and API conventions. She splits it into topic files under .claude/rules/ (testing.md, security.md, api-design.md), none of which have YAML frontmatter, commits them, and deletes the corresponding CLAUDE.md sections. What is the resulting load behavior?

    • A.The rules files load only after she adds @.claude/rules/... import lines to CLAUDE.md, because rules are not discovered automatically
    • B.Each rules file loads on demand only when Claude reads a file in the matching directory, so startup context shrinks immediately
    • C.All .md files under .claude/rules/ (including subdirectories) load at session launch with the same priority as .claude/CLAUDE.md, so the split improves modularity but does not by itself reduce startup context✓ Answer
    • D.Rules files override CLAUDE.md and are read only by the /memory command, without being injected into context

    Claude Code discovers all .md files under .claude/rules/ recursively, and rules without paths frontmatter are loaded unconditionally at launch with the same priority as .claude/CLAUDE.md. The split therefore improves maintainability and team review, but the same content still enters context at startup; only adding paths frontmatter makes a rule load conditionally when matching files are touched, and /memory will confirm which rules files were loaded in the session.

    Source: Claude Code docs — Memory: "Organize rules with .claude/rules/" (all .md files discovered recursively; rules without paths frontmatter load at launch with the same priority as .claude/CLAUDE.md)Report a problem with this question

  14. 14. An architect built a /release-notes command she uses in every repository she works on, but her team does not want it committed to any project. Teammates must still get the team's shared /deploy command automatically when they clone the repo. Which layout satisfies both requirements?

    • A.Define release-notes as a rule in ~/.claude/CLAUDE.md, since memory files automatically generate slash commands
    • B.Put release-notes.md in ~/.claude/commands/ (user scope: available in all her projects, visible only to her) and keep deploy.md in the repo's .claude/commands/, which is shared with the team through version control✓ Answer
    • C.Put both files in the repo's .claude/commands/ and add release-notes.md to .gitignore in every repository she works on
    • D.Put both files in ~/.claude/commands/, since user-level commands are synchronized to teammates through project settings

    Command scope is determined by location: files in ~/.claude/commands/ are user-scoped, so they follow her across every project on her machine without ever being committed, while files in the repo's .claude/commands/ are project-scoped and reach teammates through version control. The same personal-versus-project split applies to skills (~/.claude/skills vs .claude/skills), where a personal variant even overrides a same-named project skill; gitignoring per repo would force her to copy the file into every repository, and neither CLAUDE.md rules nor settings create or sync slash commands.

    Source: Claude Code docs — Skills/Slash commands: scope table (Personal ~/.claude → all your projects; Project .claude → this project only, shared via source control; personal overrides project on name conflicts)Report a problem with this question

  15. 15. Before refactoring event handling across a large monorepo, an architect needs Claude to trace one feature through dozens of packages — a discovery pass that will generate long grep and file-read output he will never reference again. He wants the findings without flooding the main conversation's context window. Which approach uses the documented mechanism for this?

    • A.Enable plan mode, which prevents search and file-read results from being added to the conversation context
    • B.Delegate the investigation to the built-in Explore subagent, which runs read-only tools in its own context window and returns only a summary to the main conversation✓ Answer
    • C.Create a custom subagent with full Write and Edit access so it can explore the packages and apply the refactor in a single pass
    • D.Run all the searches in the main conversation, then run /compact afterwards to reclaim the tokens the search output consumed

    Explore is a built-in subagent designed exactly for verbose discovery: it is a fast, read-only agent (Write and Edit are denied) that performs file discovery and code search in its own separate context window and returns only a summary, so the raw grep and file contents never enter the main conversation. Running /compact only reclaims context after it has already been consumed and summarizes lossily, plan mode restricts editing rather than stopping context accumulation, and granting a subagent write access contradicts the read-only investigation intent.

    Source: Claude Code docs — Subagents: built-in Explore agent ("A fast, read-only agent optimized for searching and analyzing codebases... keeps exploration results out of your main conversation context"; Write/Edit denied)Report a problem with this question

  16. 16. A platform team runs claude -p in CI to review every pull-request push. When authors push follow-up commits, the workflow re-reviews the PR and re-posts comments about issues that earlier runs already flagged. What is the recommended fix?

    • A.Have the workflow fetch the PR's existing review comments and include them in the review prompt, so Claude can deduplicate and report only issues not already flagged✓ Answer
    • B.Append each run's findings to the project CLAUDE.md so subsequent runs load them automatically as memory
    • C.Lower the model temperature so repeated reviews deterministically skip issues that were reported before
    • D.Pass --resume with the previous run's session ID, since CI runs share session state through the repository

    Each headless invocation starts stateless: session history is stored locally on the machine that ran it, so ephemeral CI runners have no memory of earlier reviews, and --resume cannot retrieve a session that lives on a different runner. The documented pattern is to make prior context explicit — fetch the PR's existing review comments and pass them into the prompt so Claude knows what was already reported and posts only new findings; writing run output into the team-shared CLAUDE.md pollutes project instructions, and temperature controls sampling randomness, not knowledge of previous comments.

    Source: CCAR-F Exam Guide Domain 3; Claude Code docs — Headless mode / CI automation best practices (headless runs are stateless and session state is machine-local; supply prior review findings in the prompt to avoid duplicate comments)Report a problem with this question

Practice questions based on the official Claude Certified Architect – Foundations (CCAR-F) exam guide and Anthropic's public documentation. This is an independent study tool, not affiliated with or endorsed by Anthropic, and does not grant certification. The real exam is 60 questions, 120 minutes, passing at a scaled 720/1000, delivered via Pearson VUE ($125). Official certification page →