Domain 2 at a glance
- Weight
- 20%
- Questions
- ~12 of 60
- Pass line
- 720/1000
- Study time
- ~35 min
Claude Code Configuration & Workflows is the second largest domain on the exam. Scenario questions about which file, scope or exit code produces the behavior a team wants.
- CLAUDE.md memory hierarchy (user, project, directory) and imports
- settings.json, permission modes, and allow/ask/deny rules
- Hooks: events, matchers, exit codes, and blocking behavior
- Built-in and custom slash commands
- Subagents in .claude/agents with YAML frontmatter
- MCP server config and scopes (local, project, user)
- Headless mode and GitHub Actions / CI/CD integration
CLAUDE.md memory hierarchy
Claude Code loads memory files at startup, from the broadest scope to the narrowest. More specific files are read later and win when instructions conflict. Files in subdirectories load on demand when Claude reads files there.
| Scope | Location | Shared with | Notes |
|---|---|---|---|
| Managed policy | OS-level managed path (set by IT) | Everyone on the machine | Cannot be excluded by users |
| Project | ./CLAUDE.md or ./.claude/CLAUDE.md | The team, via git | Build commands, conventions, architecture |
| User | ~/.claude/CLAUDE.md | Just you, all projects | Personal preferences |
| Project local | ./CLAUDE.local.md | Just you, this project | Gitignored; personal project notes |
| Subdirectory | ./some/dir/CLAUDE.md | The team | Loaded when Claude works in that directory |
- Import other files with
@path/to/fileinside CLAUDE.md. Imports can nest up to five hops deep. /memoryopens the loaded memory files in your editor;/initdrafts a project CLAUDE.md from the codebase.- CLAUDE.md is guidance the model reads. It does not enforce anything; settings and hooks do.
settings.json, permission modes and rules
| Rank | File | Committed? |
|---|---|---|
| 1 | Managed settings (managed-settings.json, set by IT) | No, deployed by policy |
| 2 | Command line arguments | No |
| 3 | .claude/settings.local.json | No, gitignored |
| 4 | .claude/settings.json | Yes, shared with the team |
| 5 | ~/.claude/settings.json | No, personal |
| Mode | Behavior |
|---|---|
default | Prompts the first time each tool is used |
acceptEdits | Auto-accepts file edits for the session; other tools still prompt |
plan | Read-only analysis; no edits or commands until you approve a plan |
bypassPermissions | Skips prompts. Only for isolated containers or VMs; admins can disable it |
| Rule | Matches |
|---|---|
Bash(npm run test:*) | Any command starting with npm run test: |
Bash(git push) | Exactly git push |
Read(./.env) | Reading .env in the project root |
Edit(src/**) | Edits anywhere under src/ |
WebFetch(domain:docs.example.com) | Fetches from that domain |
mcp__github__create_issue | One tool from one MCP server |
- Rules live in
permissions.allow,permissions.askandpermissions.deny. Deny beats ask, and ask beats allow, across every scope. - Read-only tools (Read, Grep, Glob) do not prompt by default; Bash and file edits do.
Hooks: events, matchers and exit codes
Hooks are shell commands Claude Code runs at fixed points. They are configured under hooks in any settings file, keyed by event, with an optional matcher that filters by tool name (a regex such as Edit|Write, or mcp__github__.*). This is the most-tested table in the domain.
| Event | Fires | Matcher | Can it block? |
|---|---|---|---|
| PreToolUse | Before a tool runs | Tool name | Yes: the tool call is prevented |
| PostToolUse | After a tool succeeds | Tool name | The tool already ran; exit 2 feeds stderr back to Claude |
| UserPromptSubmit | When you submit a prompt | None | Yes: the prompt is erased; stdout on exit 0 is added as context |
| Stop | When the main agent finishes | None | Yes: forces Claude to keep working |
| SubagentStop | When a subagent finishes | None | Yes: forces the subagent to continue |
| SessionStart | On startup, resume or clear | Source | No; stdout on exit 0 is added as context |
| PreCompact | Before compaction | manual / auto | No |
| Notification | When Claude Code sends a notification | None | No |
| Exit code | Meaning |
|---|---|
| 0 | Success. JSON on stdout is parsed for decisions (for example permissionDecision) |
| 2 | Blocking error. stderr goes to Claude; stdout is ignored |
| Anything else | Non-blocking error. stderr is shown to the user and execution continues |
On the exam, watch for exit 1 offered as "block the call". Only exit 2 blocks.
Slash commands, built-in and custom
A custom command is a Markdown file in .claude/commands/ (project, shared) or ~/.claude/commands/ (personal). The filename is the command name and subfolders namespace it. $ARGUMENTS receives everything after the command, $1 and $2 pick positional arguments, and frontmatter sets description, allowed-tools, argument-hint and model.
| Command | What it does |
|---|---|
/init | Draft a project CLAUDE.md from the codebase |
/memory | Open memory files in your editor |
/compact [instructions] | Summarize the conversation to free context |
/clear | Start a fresh context in the same session |
/permissions | View and edit allow, ask and deny rules |
/agents | Create and manage subagents |
/mcp | Manage MCP servers and authenticate |
/hooks | Review and edit hook configuration |
---
description: Fix a GitHub issue by number
allowed-tools: Bash(gh issue view:*), Edit, Read
argument-hint: <issue-number>
---
Read issue #$ARGUMENTS with gh, find the cause, fix it, and add a test.Subagents
Subagents are Markdown files with YAML frontmatter in .claude/agents/ (project) or ~/.claude/agents/ (user). When names collide, the project file wins. Only name and description are required. Claude delegates automatically when a task matches the description, or you can ask for one by name.
- Omit
toolsand the subagent inherits every tool from the main thread; list them to apply least privilege. - Each subagent has its own context window, so it returns a summary rather than its full transcript.
---
name: code-reviewer
description: Reviews diffs for bugs and security issues. Use after any code change.
tools: Read, Grep, Glob
model: sonnet
---
You are a senior reviewer. Report findings by severity with file and line.MCP server scopes
| Scope | Stored in | Visible to | Add with |
|---|---|---|---|
| Local (default) | ~/.claude.json, under this project | You, in this project | claude mcp add name ... |
| Project | .mcp.json in the repo | Everyone who clones it, after approval | claude mcp add --scope project ... |
| User | ~/.claude.json | You, in every project | claude mcp add --scope user ... |
- Precedence when names collide: local, then project, then user.
- Project-scope servers ask each user for approval before first use;
claude mcp reset-project-choicesclears those answers. - Separate Claude Code flags from the server command with
--:claude mcp add github -- npx -y @modelcontextprotocol/server-github. .mcp.jsonsupports environment variable expansion such as${GITHUB_TOKEN}so secrets stay out of git.
Headless mode and CI
| Flag | Purpose |
|---|---|
-p "prompt" | Run once non-interactively and print the result |
--output-format text|json|stream-json | Machine-readable output for scripts |
--allowedTools "Read,Edit,Bash(npm test)" | Pre-approve tools, since nobody is there to click |
--permission-mode plan | Set the mode for this run |
--max-turns 5 | Cap agentic turns; the run ends with an error result at the cap |
--resume <id> / --continue | Continue a specific or the most recent session |
on:
issue_comment:
types: [created]
jobs:
claude:
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: "--max-turns 10 --allowedTools Read,Edit,Bash(npm test)"Common exam traps
Exit 1 does not block
Wrong: Exit 1 from PreToolUse stops the tool
Right: Only exit 2 blocks; other non-zero codes are non-blocking errors
The exam loves offering exit 1 as the blocking answer.
Deny always wins
Wrong: A specific allow overrides a broad deny
Right: Deny beats allow at every scope
Specificity does not matter between allow and deny.
CLAUDE.local.md is personal
Wrong: Put team policy in CLAUDE.local.md
Right: Team guidance goes in the committed CLAUDE.md or settings.json
The local file is gitignored.
CLAUDE.md is not enforcement
Wrong: "Never edit migrations" in CLAUDE.md is enough
Right: Use a deny rule or a PreToolUse hook
Memory is guidance; settings and hooks are controls.
Local beats shared settings
Wrong: The committed settings.json always wins
Right: settings.local.json outranks settings.json; managed settings outrank both
Precedence runs managed, CLI, local, project, user.
PostToolUse cannot undo
Wrong: PostToolUse exit 2 reverts the edit
Right: The tool already ran; exit 2 only feeds stderr back to Claude
Use PreToolUse to prevent an action.
Default MCP scope is local
Wrong: claude mcp add writes .mcp.json
Right: It writes local scope; use --scope project to share
Sharing is opt-in.
Headless needs pre-approved tools
Wrong: CI will prompt for permissions
Right: Pass --allowedTools or a permission mode
There is no human to approve a prompt in CI.
Flashcards
15 cards from the tables above. Flip each one and mark the ones you know; your progress is saved in this browser.
Exit code 2. stderr is fed back to Claude and stdout is ignored.
A non-blocking error: stderr is shown to the user and execution continues.
Managed, command line, .claude/settings.local.json, .claude/settings.json, ~/.claude/settings.json.
Deny wins, at every scope.
CLAUDE.local.md, which is gitignored.
@path/to/file, nested up to five hops.
plan
.claude/commands/*.md in the repo.
$ARGUMENTS for everything, $1, $2 for positional.
name and description.
Local: private to you, in this project, stored in ~/.claude.json.
.mcp.json at the project root (project scope).
-p (print mode), usually with --output-format json.
UserPromptSubmit: stdout on exit 0 is added as context.
PreCompact (matcher manual or auto).
0/15 known. Keep going with spaced repetition and hundreds more cards in Claude Prep.
Get Claude PrepOne-page cheat sheet
Get these as flashcards with spaced repetition in Claude Prep.
Practice quiz: 12 Claude Code Configuration & Workflows questions
Original, exam-style questions, one per task statement. Pick an answer to see the explanation. Finish all 12 for your score and your weakest topics. No signup.
- Q1CLAUDE.md vs settingsfoundation
Which of the following belongs in a settings file rather than in CLAUDE.md?
Answer: C. A permission rule that denies Claude the ability to run a specific shell command
Permission rules like permissions.deny are technical enforcement applied by the Claude Code client regardless of what the model decides, so they belong in settings files. CLAUDE.md content is context that guides behavior but is not guaranteed to be obeyed. Build commands, naming conventions, and architecture overviews are exactly the kind of natural-language guidance CLAUDE.md is designed to carry.
- Q2/memory commandfoundation
What does the /memory slash command do in an interactive Claude Code session?
Answer: A. Lists all CLAUDE.md, CLAUDE.local.md, and rules files loaded in the session and lets you open them in your editor, plus toggle auto memory
The /memory command is the inspection and editing entry point for memory: it shows every memory file loaded in the current session, opens any of them in your editor, and includes the auto memory toggle. Clearing context is handled by /clear or /compact, not /memory. It does not produce token usage reports, and it never writes the conversation itself into CLAUDE.md.
- Q3CLAUDE.local.mdfoundation
What is the intended purpose of a CLAUDE.local.md file at the root of a project?
Answer: C. Holding personal, project-specific instructions (like sandbox URLs or preferred test data) that are added to .gitignore rather than committed
CLAUDE.local.md is for individual, per-project preferences: it loads alongside the project CLAUDE.md and should be gitignored so it stays private to you. It does not override or disable the shared CLAUDE.md; both files are combined into context. There is no --local launch flag gating it, and organization-wide policy belongs in the managed policy CLAUDE.md location, not in a per-developer local file.
- Q4Subagent frontmatterfoundation
Which YAML frontmatter fields must be present in a Claude Code subagent definition file?
Answer: B. name and description
Only name and description are required in subagent frontmatter; the Markdown body then becomes the subagent's system prompt. Fields like tools, model, and permissionMode are optional: omitting tools inherits all tools from the main conversation, and omitting model falls back to the session's model. The description is required because Claude uses it to decide when to delegate.
- Q5/init commandfoundation
A developer joins a project that has no CLAUDE.md and runs the /init command in Claude Code. What does /init do?
Answer: A. Analyzes the codebase and generates a starting CLAUDE.md with discovered build commands, test instructions, and conventions; if one already exists it suggests improvements instead of overwriting it
/init bootstraps project memory by exploring the codebase and writing a CLAUDE.md that captures build commands, test instructions, and project conventions, and when a CLAUDE.md already exists it proposes improvements rather than overwriting. It is a memory-generation command, not a settings or permissions generator. It never destroys an existing file, and it has nothing to do with Console registration.
- Q6Memory importsfoundation
Which syntax does a CLAUDE.md file use to import the contents of another file into Claude Code's context at launch?
Answer: D. An @ prefix followed by the path, for example @docs/git-instructions.md
CLAUDE.md supports @path/to/import syntax, so writing @docs/git-instructions.md anywhere in the file expands that file into context at launch. Both relative and absolute paths are allowed. The templating, #include, and markdown-link forms are plausible-looking inventions that Claude Code does not recognize as imports.
- Q7Tool permission promptsfoundation
In Claude Code's default permission mode, which category of tool actions runs without ever triggering an approval prompt?
Answer: B. Read-only operations such as file reads and Grep searches
Claude Code uses a tiered permission system in which read-only tools like file reads and Grep never require approval. Bash commands and file modifications both require approval in default mode: Bash approvals persist per project directory and command only when you choose the don't-ask-again option, and file edit approvals last until the session ends. There is no automatic session-wide trust for previously used commands or domains.
- Q8CLAUDE.md best practicesfoundation
According to Anthropic's guidance, which situation is the strongest signal that an instruction should be added to a project's CLAUDE.md?
Answer: C. The developer notices they are typing the same correction into chat that they typed in a previous session
The docs frame CLAUDE.md as the place to write down what you would otherwise re-explain: repeated corrections, repeated mistakes, and context a new teammate would need. Long multi-step procedures or narrowly scoped guidance belong in skills or path-scoped rules instead, keeping CLAUDE.md concise. Secrets should never go in a memory file, and anything requiring guaranteed enforcement belongs in settings (permissions or hooks), not in context.
- Q9Hook exit codesintermediate
What happens when a PostToolUse hook exits with code 2 after Claude runs a Bash command?
Answer: A. The stderr output is shown to Claude as feedback, but the command has already executed and cannot be blocked
PostToolUse fires after a tool call completes, so exit code 2 cannot prevent something that already happened; it only surfaces stderr to Claude so the model can react, for example by fixing a failing check. Claude Code does not roll back tool effects, retry the call, or preemptively block future tool calls based on the exit code.
- Q10Permission rulesintermediate
A CI configuration contains the permission rules allow: ["Bash(aws s3 ls *)"] and deny: ["Bash(aws *)"]. When Claude Code attempts to run aws s3 ls s3://build-artifacts, what happens?
Answer: D. The command is blocked, because deny rules are evaluated before allow rules and rule specificity does not change that order
Rules are evaluated in the fixed order deny, then ask, then allow, and the first match wins regardless of how specific each rule is. A broad deny like Bash(aws *) therefore blocks every matching call, including ones that also match a narrower allow rule, so a deny rule cannot carry allowlist exceptions. There is no prompt or warning-and-run behavior for this situation.
- Q11MCP scopesintermediate
An engineer runs claude mcp add --transport http linear https://mcp.linear.app/mcp inside a project without specifying a --scope flag. Where will this server be available?
Answer: C. Only to that engineer, and only in the current project, because the default is local scope stored under the project's entry in ~/.claude.json
Local scope is the default for claude mcp add: the server is recorded under the current project's path inside the user's ~/.claude.json, so it is private to that engineer and loads only in that project. Writing to the shareable .mcp.json requires --scope project, and machine-wide personal availability requires --scope user. Organization-wide deployment is done through managed configuration, not the default add command.
- Q12Headless permissionsintermediate
A nightly job runs claude -p "Run the test suite and fix any failures" on a build server, but the job errors out as soon as Claude attempts its first file edit. What is the cause and the recommended fix?
Answer: C. Headless runs cannot display permission prompts, so pre-approve the needed tools, for example --allowedTools "Bash,Read,Edit"
Non-interactive mode has no way to show a permission prompt, so a tool that has not been pre-approved causes the run to fail instead of pausing; --allowedTools (or a permission mode such as acceptEdits) grants the required tools up front. --verbose only changes logging and cannot capture approvals. Plan mode is read-only exploration, which would still block edits, and --max-turns has no default limit and is unrelated to permissions.
Answer all 12 to see your score
You will get a score and your weakest topics. No signup.
Official sources
Every table on this page was checked against these Anthropic pages in October 2026. When a number here and the docs disagree, trust the docs.