20 Claude Code Configuration & Workflows Practice Questions & Answers

1. 1. A team switches from an inline autocomplete plugin to Claude Code. A developer types "fix the failing integration test in the billing module" and is surprised when the tool opens files, edits three of them, runs the test suite twice, and reports a green run. Which statement most accurately describes what changed?

   • A.An agentic coding harness runs a loop in which it reads and edits real files, executes commands, and iterates against real feedback such as test output and type errors, rather than only proposing text for a human to paste✓ Answer
   • B.A chat window and an agentic harness behave identically; the only difference is that the harness formats its code blocks for the terminal
   • C.The behavior is identical to autocomplete; the harness simply uses a larger model, so no change in workflow or oversight is needed
   • D.Autocomplete produces more reliable fixes because it always has the entire repository in view, while the harness only sees the current prompt

   An agentic coding harness differs from autocomplete or a chat window because it can act on the repository: it reads and writes files, executes build and test commands, observes the results, and loops until the feedback signal is satisfied. That ability to close the loop against real execution output is the defining property, and it is also why agent-authored changes require review and permission boundaries that autocomplete never needed.

   Source: Claude Code docs — Overview: agentic coding in the terminal (reads files, edits code, runs commands, iterates on feedback)Report a problem with this question

2. 2. An engineering manager must pick one of two tasks to hand to a longer-running autonomous Claude Code session while the team is at an offsite. Task A: "Bring p95 checkout latency under 200 ms; the existing load test asserts that threshold and currently fails." Task B: "Make the onboarding copy feel warmer and more on-brand." Which is the better fit for autonomy, and why?

   • A.Task A, but only because latency work touches fewer files than copy changes do
   • B.Task A, because it is grounded in an automatic verifiable check the agent can run itself to know whether it is done; taste-judged work needs a human evaluating each iteration✓ Answer
   • C.Either one, because a sufficiently detailed prompt removes the need for any verification signal
   • D.Task B, because copy edits are low risk and cannot break the build, so autonomy is always safe there

   Autonomy is only as good as the agent's ability to tell whether it has succeeded. A failing load test, a compiler error, or a reproduction gives the loop an objective termination signal, so the agent can iterate unattended and stop when the check passes. Subjective goals like tone have no machine-checkable criterion, so every iteration requires human judgment and the session should stay interactive.

   Source: Claude Code docs — Best practices: give Claude a target it can verify (tests, type checks, reproductions)Report a problem with this question

3. 3. A production bug returns HTTP 500 on roughly 1 in 20 requests. A developer opens Claude Code and says "fix the intermittent 500s in the orders service." The agent edits six files, the existing unit tests stay green, the PR merges, and the error rate in staging is unchanged. What is the most effective change to the workflow?

   • A.Require the agent to first produce a reliable reproduction — a test or script that fails on the current code — and only then attempt a fix, so the change is validated against a real signal✓ Answer
   • B.Approve all tool permissions up front so the agent can iterate faster without interruption
   • C.Ask the agent to re-read the entire service directory before editing so it has more of the codebase in context
   • D.Delegate the same request to three subagents in parallel so that at least one of them finds the real cause

   Without a failing check, neither the agent nor the reviewer can distinguish a real fix from a plausible-looking edit; green pre-existing tests only prove the bug was never covered. Establishing a reproduction converts the task into one with an objective pass/fail signal, so the iteration loop terminates on evidence rather than on the agent's confidence. Extra context, extra subagents, or blanket permissions do not supply that missing signal.

   Source: Claude Code docs — Common workflows: reproduce the failure first, then let Claude iterate against the failing testReport a problem with this question

4. 4. In a 12-person repository, roughly 40% of Claude Code sessions use the wrong test command and the wrong database migration step, and each developer re-explains the same conventions at the start of every session. What is the most effective durable fix?

   • A.Have each developer put the same notes in their personal user-level configuration so their own sessions are correct
   • B.Record the build, test, and migration commands plus the architecture and convention notes in the project-level configuration file committed to the repository, so every session on every clone loads them automatically✓ Answer
   • C.Add a CI lint rule that fails the build when the wrong migration command appears in a commit message
   • D.Paste a standards paragraph at the top of every prompt and rely on developers to remember to include it

   Durable repository context belongs in project-level configuration that is version-controlled, because it is loaded automatically for every session and travels with the clone to new teammates. User-level configuration is personal and is never shared through version control, which is exactly why a teammate who lacks it keeps getting the wrong commands, and per-prompt pasting reintroduces the human step that was failing 40% of the time.

   Source: Claude Code docs — Memory: project memory is checked into the repository; user memory is personal and not sharedReport a problem with this question

5. 5. A release-notes workflow has nine ordered steps (collect merged PRs, group by area, draft entries, check breaking changes, and so on). It is re-explained about three times a week, and reviewers notice that two of the nine steps are frequently skipped. What is the most appropriate fix?

   • A.Package the nine steps as a reusable, version-controlled instruction set the agent can invoke when the task comes up, so the procedure lives in one place instead of being re-explained✓ Answer
   • B.Append all nine steps to the always-loaded project configuration so they are in context for every session
   • C.Write a shell script that pipes a very long prompt into the tool once per release
   • D.Ask the agent to recall how it did the task in a previous session, since it can look up its own history

   Recurring, task-specific procedures belong in packaged reusable instructions that are loaded on demand when the task arises, whereas always-loaded project configuration is for universal standards that apply to every session. Putting a nine-step release procedure in always-loaded context spends tokens on work that is irrelevant most of the time, and re-explaining by hand is what caused steps to be dropped in the first place.

   Source: Claude Code docs — Skills: reusable, on-demand task workflows vs. always-loaded memory for universal standardsReport a problem with this question

6. 6. A platform team has a "prepare release" routine that tags a build and posts a summary. They want it to run only when a human explicitly asks for it, and never to be chosen by the model in the middle of unrelated work. Which approach best meets that requirement?

   • A.Define it as a user-invoked command that a developer triggers explicitly, since model-invoked capabilities are selected by the model whenever it judges them relevant✓ Answer
   • B.Define it as a model-invoked capability but add "do not use unless the user asks" to its description
   • C.Define it as a model-invoked capability with a deliberately obscure name so the model is unlikely to match it
   • D.Describe the routine in always-loaded project configuration with a note that it is manual only

   The distinction is who decides to run the thing: user-invoked commands fire only when a person triggers them, while model-invoked capabilities are surfaced by relevance matching and can be selected autonomously. When the requirement is a hard guarantee about invocation, choose the mechanism whose control is deterministic rather than relying on wording in a description or prompt, which has a non-zero failure rate.

   Source: Claude Code docs — Slash commands (explicitly user-invoked) vs. Skills (model-invoked based on relevance)Report a problem with this question

7. 7. A developer is investigating how four independent services each implement retry logic. Forty minutes in, the main session is full of raw search output and file dumps, and the agent begins describing a retry helper that does not exist in any of the four services. What is the best structural fix?

   • A.Read every file in all four services into the session up front so nothing has to be inferred
   • B.Restart the session from scratch each time the agent makes a mistake
   • C.Delegate each service's exploration to a separate subagent that performs the verbose discovery in its own context and returns a short structured summary of what it actually found✓ Answer
   • D.Instruct the agent to be more careful and to double-check every claim it makes about the code

   Long exploratory sessions degrade because accumulated raw output crowds out the findings, and the model starts filling gaps with typical patterns instead of code it verified. Delegating independent investigations to subagents isolates the verbose discovery in separate contexts and returns only distilled findings to the coordinating session, which is exactly the case where the cost of delegation is justified. Reading everything upfront makes the accumulation problem worse.

   Source: Claude Code docs — Subagents: isolate verbose exploration in a separate context and return summariesReport a problem with this question

8. 8. A team adopts a rule that every task, including one-line fixes, must be delegated to a subagent. Wall-clock time per task rises about 40%, and subagents repeatedly ask about decisions the main session had already made ten minutes earlier. What is the correct diagnosis?

   • A.Subagents need a larger context allocation; increasing it will let them see the main session's history
   • B.A shared memory file should be introduced and written to before every task, however small, so all agents stay synchronized
   • C.The subagents are underperforming and should be given stricter instructions to stop asking questions
   • D.Subagents run in isolated context and do not inherit the main session's conversation history, so every delegation pays a re-discovery and context-passing cost; delegation should be reserved for independent or parallelizable investigation that would otherwise flood the main context✓ Answer

   A subagent starts with a clean context and receives only what its prompt explicitly contains; it cannot see the parent conversation regardless of how much context it is allocated. That makes delegation valuable when the work is genuinely independent and verbose, and wasteful when the main session already holds the relevant state and the task is small.

   Source: Claude Code docs — Subagents: isolated context, no inheritance of parent conversation historyReport a problem with this question

9. 9. Developers on a support-tooling team paste ticket descriptions and error-tracker stack traces into their Claude Code sessions by hand, roughly 15 times a day, and often paste a truncated or stale version. What is the most appropriate way to remove this friction?

   • A.Train developers to paste more completely and add a checklist to the pull-request template
   • B.Have the agent guess the missing details from the code and confirm them with the developer afterward
   • C.Connect the ticket system and the error tracker as MCP servers so the agent can query the live systems from inside the coding session✓ Answer
   • D.Export the ticket system and error tracker to CSV files nightly and commit them into the repository so the agent can read them

   MCP servers extend a coding session with access to external systems, so the agent can pull ticket text and stack traces directly from the source of truth instead of depending on a human copy-paste step that is both frequent and error-prone. Nightly exports reintroduce staleness, and process reminders do not remove the manual step that is failing.

   Source: Claude Code docs — MCP: connect Claude Code to external tools and data sourcesReport a problem with this question

10. 10. A director asks why the tool interrupts an engineer for approval before running a command that rewrites git history, when it already reads source files without asking. What is the best explanation of the permission model?

    • A.Prompts are a temporary limitation that will disappear once the agent's accuracy improves
    • B.The agent cannot determine what any shell command does, so it asks about all commands equally
    • C.Approval prompts exist to meter usage costs, so they appear on the operations that consume the most tokens
    • D.An agent that can edit files and execute commands can take consequential and sometimes irreversible actions, so the permission model gates the high-consequence classes while letting low-risk, reversible operations such as reading proceed without interruption✓ Answer

    The permission model is risk-tiered rather than uniform: reading and searching are reversible and cheap to allow, while writes to shared state, destructive commands, and outbound network actions can cause damage a human would need to undo. Gating by consequence is what makes it possible to grant meaningful autonomy without giving up the ability to stop an irreversible action before it happens.

    Source: Claude Code docs — Security and permissions: tiered approval for file edits and command executionReport a problem with this question

11. 11. An engineer approves about 60 permission prompts a day; roughly 90% are read-only searches and file reads on the repository she is working in. She wants less interruption without weakening safety. Which permission configuration is most appropriate?

    • A.Require approval for every action including reads, to keep the policy simple and consistent
    • B.Remove permission checks in local development and rely on the same relaxed policy in automated pipelines
    • C.Allow read-only inspection such as searching, reading files, and status commands to proceed without prompting, while keeping an approval gate on writes to shared state — pushing branches, deleting files, and network or deployment actions✓ Answer
    • D.Approve every tool for the duration of each session, since she is present and can interrupt if something looks wrong

    Prompt fatigue is itself a safety problem, because an engineer approving 60 dialogs a day stops reading them. The right adjustment is to allowlist the reversible, read-only classes so attention is preserved for the small number of consequential actions, rather than removing the gate entirely or applying uniform friction that trains people to click through.

    Source: Claude Code docs — Permissions: allowlist low-risk read-only tools, keep approval on destructive and external actionsReport a problem with this question

12. 12. To finish a large migration overnight, a developer proposes running Claude Code unattended with all permission checks bypassed, on his laptop, in a shell that has production database and cloud credentials in its environment. What is the best response?

    • A.Keep the setup as proposed but cap the number of iterations so the run cannot go too far off track
    • B.Bypassing permission checks is acceptable because the agent reviews its own diffs before finishing
    • C.Run the unattended session in an isolated environment — a container or dedicated worktree with no production credentials and no write access to shared systems — so broad autonomy is bounded by what the environment itself can reach✓ Answer
    • D.Keep the credentials available but add an instruction to the prompt telling the agent never to touch production systems

    When the interactive approval gate is removed, the environment becomes the only remaining boundary, so autonomy must be paired with isolation: no production credentials, no write access to shared systems, and a disposable workspace. A prompt instruction is probabilistic guidance and cannot provide the hard guarantee that a credential-free sandbox provides, and an iteration cap limits length rather than blast radius.

    Source: Claude Code docs — Security: run unattended/autonomous sessions in isolated environments with restricted credentialsReport a problem with this question

13. 13. A task requires replacing a date-handling library across 45 files, and there are at least three defensible migration strategies. A developer skips planning and starts editing immediately; after 12 files the reviewer points out that the chosen strategy breaks timezone behavior and the work must be redone. What should have happened?

    • A.Split the work across 45 parallel subagents, one per file, so no single wrong strategy can dominate
    • B.Ask the agent to write the migration in one large commit so the strategy is easier to revert
    • C.Begin with direct execution as done, and switch to planning only once problems appear
    • D.Use plan mode first so the agent explores the codebase and proposes an approach that the developer reviews and agrees to before any file is edited✓ Answer

    Planning before editing pays off precisely when the shape of the change is unclear or several valid approaches exist, because the cheapest place to reject a wrong strategy is before any code is written. Starting direct and switching later is not a valid alternative when the complexity is already known at the outset, since by then the rework cost has already been incurred.

    Source: Claude Code docs — Plan mode: explore and agree on an approach before making edits on ambiguous, multi-file workReport a problem with this question

14. 14. After the migration incident, the same team mandates a written plan approved by a second engineer for every change. Throughput drops 30%, and the clearest example is a single-file null-dereference fix with an unambiguous stack trace that waited two days for plan review. What is the correct calibration?

    • A.Keep the mandate but shorten the required plan template so review is faster
    • B.Replace the plan requirement with a rule that every change must first be delegated to a subagent for an independent second opinion
    • C.Reserve planning for changes that are ambiguous, architectural, or span many files, and use direct execution for small, well-scoped changes where the fix and its verification are already clear✓ Answer
    • D.Drop planning entirely and return to direct execution for all work, since the migration failure was a one-off

    Planning and direct execution are matched to task shape, not applied uniformly. A one-file fix with a clear stack trace has a single obvious approach and an immediate verification signal, so planning adds latency without reducing risk; ambiguity, architectural choice, and multi-file scope are the conditions that make an up-front plan worth its cost.

    Source: Claude Code docs — Plan mode vs. direct execution: match the mode to task complexity and scopeReport a problem with this question

15. 15. Three hours into a single Claude Code session on a large legacy codebase, the agent starts referring to a validation helper that does not exist and contradicts a data-model decision that was settled ninety minutes earlier. What is the most effective way to handle this?

    • A.Ask the agent to summarize its own reasoning periodically inside the same conversation and trust that summary going forward
    • B.Continue in the same session and correct each error as it appears, since the agent adapts after being told
    • C.Delegate the remainder of the work to subagents so that no single context has to hold the whole task
    • D.Persist the confirmed findings and decisions to a notes file in the repository, then reduce the accumulated context or start a fresh session seeded with that written summary✓ Answer

    Extended sessions degrade as context accumulates: earlier decisions get crowded out and the model begins substituting typical patterns for code it actually verified. Writing confirmed facts and decisions to a durable file lets them survive across context boundaries, and re-seeding a reduced or fresh context from that file restores accuracy without losing the work already done.

    Source: Claude Code docs — Managing context in long sessions: persist findings externally and compact or restart from a summaryReport a problem with this question

16. 16. A team merges agent-authored pull requests whenever CI is green. Over one month there are three production incidents traced to merged changes: an exception handler that silently swallowed errors, a permission check widened from one role to any authenticated user, and a large block of unused code. What is the most effective fix?

    • A.Ask the session that produced each change to review its own diff before opening the pull request
    • B.Raise the required test coverage threshold to 100% so untested code cannot be merged
    • C.Increase the number of CI retries so intermittent test failures do not mask real problems
    • D.Require a human to read the diff before merging, since a green pipeline shows that the tests pass, not that the change is correct, minimal, or in scope✓ Answer

    Automated checks verify only the properties someone thought to encode; swallowed exceptions, scope creep, and widened authorization all pass a green suite precisely because no test asserts against them. Human review of agent-authored diffs is the control that catches intent and scope problems, which is why agent output should be read rather than accepted on the strength of CI alone.

    Source: Claude Code docs — Review Claude's changes: verify diffs rather than accepting them unreadReport a problem with this question

17. 17. A team asks the same session that just generated a 600-line feature to review its own work. It reports one issue. A separate reviewer running against the same diff with no prior conversation reports seven, including two real bugs. What best explains the gap and the right remedy?

    • A.The reviewing prompt was too short; asking the generating session to be more critical and thorough will close the gap
    • B.A session that produced the code carries its own generation reasoning and is biased toward justifying its choices, so code review should be run by an independent instance that sees only the diff and the standards✓ Answer
    • C.The generating session ran out of context; extending it would have surfaced the same seven issues
    • D.Running the generating session three times and taking findings agreed on by two of the three runs would produce the same result

    Self-review is structurally weak because the reasoning that produced a decision is still present and makes the model less likely to question it. An independent review instance approaches the diff without that commitment, which is why separating generation from review is the effective control; instructions to be more critical do not remove the bias, and consensus voting among correlated runs tends to suppress genuine findings rather than surface them.

    Source: Claude Code docs — Code review: use a separate session/instance from the one that generated the codeReport a problem with this question

18. 18. A developer opens a session with "make the search API faster." Nine turns of clarification and correction follow, and the resulting rewrite is discarded because it changed the response schema that mobile clients depend on. What is the most effective change?

    • A.Let the agent make its best guess and ask clarifying questions after the edits are in place
    • B.Delegate the request to several subagents so each explores a different interpretation and the best result is kept
    • C.Break the request into nine separate one-line prompts, one per turn, so each step stays small
    • D.State the goal, the constraints, the files in scope, and the acceptance check up front — for example, a target latency, an explicit prohibition on changing the response schema, and the benchmark that must pass✓ Answer

    An agent will act on the specification it is given, so unstated constraints such as a frozen public schema are simply invisible to it until a human notices the violation. A single well-specified instruction that names the goal, the boundaries, and the check that decides success outperforms an ambiguous request corrected over many turns, because each correction turn arrives only after work has already been done in the wrong direction.

    Source: Claude Code docs — Best practices: be specific about goals, constraints, scope, and how success is verifiedReport a problem with this question

19. 19. A codebase has 120 lint violations of a single mechanical rule, and `npm run lint` reports pass or fail deterministically. The team is working through them interactively, approving each edit one at a time, and has spent two hours supervising. What is the better approach?

    • A.Keep approving each edit, because every file change deserves individual human sign-off regardless of the change class
    • B.Run the task as an autonomous session in an isolated branch or worktree with the lint command as the completion check, then review the resulting diff as a whole; reserve interactive sessions for ambiguous or design-heavy work✓ Answer
    • C.Disable the lint rule, since 120 violations suggest the rule does not match the team's conventions
    • D.Split the work across ten subagents so each fixes twelve files and the wall-clock time drops

    The choice between an interactive session and an autonomous run depends on whether the agent has a check that tells it when it is done and whether the change class is mechanical. A deterministic lint command supplies exactly that signal, so per-edit approval spends human attention where it adds nothing; review is still required, but it belongs at the end, on the complete diff, rather than 120 times in the middle.

    Source: Claude Code docs — Interactive sessions vs. autonomous/headless runs: automate work with a deterministic completion checkReport a problem with this question

20. 20. A coordinator session delegates a codebase audit: one subagent maps authentication call sites, another maps session-storage usage, and a third writes the final report. The report omits three findings the first subagent clearly identified. Investigation confirms all three exploration subagents completed their assignments correctly. What is the root cause?

    • A.The report-writing subagent did not receive the earlier subagents' findings in its own prompt; subagents run in isolated context and share no conversation history, so the coordinator must pass prior results explicitly✓ Answer
    • B.The report-writing subagent performed poorly and should be replaced with a stricter set of instructions about completeness
    • C.The audit was too large for a single report and should always be split into one report per subagent
    • D.The exploration subagents should have written their findings into the coordinator's conversation directly instead of returning summaries

    Each subagent starts from a clean context and can only use what its prompt contains; it has no access to the coordinator's history or to sibling agents' results. When a synthesis step is missing upstream findings, the defect is in the coordinator's handoff, not in downstream agents that executed their assignments correctly, and the fix is to include the prior findings verbatim in the synthesis prompt.

    Source: Claude Code docs — Subagents: context must be passed explicitly in the subagent prompt; no shared historyReport 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 →