Rubric
Contents — domains, guide and mocks

Debugging and operational support

CCAR-P 7.313 min read · checked 21 September 2026

Task statementSupport debugging and operational issue resolution

A debugging loop Claude can drive

  1. Gather evidenceerror, stack trace, logs, screenshot
  2. Reproducea failing test or command
  3. Find root causeone hypothesis at a time
  4. Fix + verifytest passes; nothing suppressed

test still fails → next hypothesis

The loop ends on evidence, not on a plausible explanation. A failing test written before the fix is what turns “I think this is it” into “this was it”.

Using Claude on a live problem

Anthropic’s account of its own teams gives two operational examples. The data infrastructure team feeds Claude Code dashboard screenshots and system documentation during incidents; the write-up describes it diagnosing a Kubernetes pod-scheduling problem, and spotting IP address exhaustion during an outage. The security engineering team feeds it stack traces and documentation, and reports diagnosing production issues about three times faster. The pattern is the same in both: Claude gets the evidence a human engineer would look at, not a one-line summary of the symptom.

Claude Code’s best-practices guide turns that into prompting rules. Describe the symptom, the likely location and what “fixed” looks like. Ask for a failing test that reproduces the issue before the fix. And, in its own words, address the root cause, don’t suppress the error. Evidence can come in several ways: pipe a log with cat error.log | claude, paste a screenshot, point Claude at the file, or let it pull context itself through a CLI such as sentry-cli or an MCP server connected to your monitoring tools.

An incident request, weak and strong

Symptom only

checkout is broken, fix it asap

Evidence, scope, proof

since the 01:40 deploy, ~8% of
checkout calls return 500.
stack trace and 200 filtered log
lines attached. read-only: do not
change config or data. find the
root cause in payments-service,
write a failing test that
reproduces it, then propose the
fix. don't suppress the error.
The strong version bounds the blast radius (read-only), points at where to look, and demands a reproduction before any fix.

Keep the evidence from drowning the context

Logs are the classic way to wreck a debugging session. Claude Code’s cost guide gives the fix directly: rather than have Claude read a 10,000-line log, a hook can grep for ERROR and return only matching lines, cutting tens of thousands of tokens to hundreds. It also suggests delegating verbose work, such as running tests or processing log files, to a subagent, so only a summary reaches the main conversation. The troubleshooting page describes the failure when this goes wrong: an “autocompact is thrashing” error, where a file or tool output refills the context immediately after every compaction. Its recovery steps are to read the file in chunks, compact with a focus, move the work to a subagent, or clear.

When Claude Code itself misbehaves

The second half of this objective is supporting a team whose tooling isn’t behaving. Claude Code’s “Debug your configuration” page puts the usual cause plainly: the file didn’t load, it loaded from a different location than expected, or another file overrode it. So the first move is always to look at what actually loaded, not to edit more files.

SymptomLook first withCommon cause
Claude ignores a CLAUDE.md rule/context, then /memoryFile not loaded (subdirectory files load on demand), or the rule is vague, conflicting or buried in a long file
A setting doesn’t take effect/status (setting sources)Overridden by a higher scope or an environment variable; managed settings win
An MCP tool is missing/mcp, then claude --debug=mcpProject server never approved; relative path in command; .mcp.json inside .claude/
A hook never fires/hooks, then claude --debugMatcher is an array, lowercase or misspelled; hooks in a standalone file
Something’s wrong, unsure what/doctor, claude --safe-modeA plugin, MCP server or hook; safe mode disables customisations to isolate it

Isolating a misbehaving setup

Does the problem persist in claude --safe-mode?
  • No — it disappears
    A customisationcheck /context, /mcp, /hooks
  • Yes, and /status shows managed
    Organisation policytalk to the admin
  • Yes, with a clean config dir
    Install, auth or networkclaude doctor, login docs
  • Can’t tell from outside
    Turn on logging/debug or claude --debug

Operating Claude Code across a fleet

For a whole organisation, you need telemetry, not anecdotes. Claude Code exports OpenTelemetry metrics and events once CLAUDE_CODE_ENABLE_TELEMETRY is set with exporters and an endpoint, and administrators can push that configuration to every machine through the env block of managed settings. Metrics include claude_code.session.count, claude_code.token.usage, claude_code.cost.usage and claude_code.active_time.total. Events include claude_code.api_request, claude_code.api_error, claude_code.tool_result and claude_code.tool_decision, tied together by a prompt.id. A beta tracing mode adds spans for each interaction, model request and tool call, and passes a TRACEPARENT to Bash subprocesses.

Managed settings: send every session’s telemetry to the company collectorjson
{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://otel-collector.internal:4317"
  }
}

Cost spikes are the operational issue admins see most. The cost guide says unexpectedly high API spend usually traces back to long sessions that were never cleared, or to the most expensive model left as the default. It also lists quieter causes in long sessions: cache misses after breaks, scheduled tasks firing while idle, and compaction of a very large context. Individual developers can see attribution by skill, subagent, plugin and MCP server in /usage (/cost is an alias), and /insights reports friction patterns across recent sessions. Observability of Claude-powered products you build, as opposed to the developer tooling, is 3.4 and 4.6.

Traps the wrong answers are built from

Tempting but wrongDo this instead
Asking Claude to “fix it” with only a one-line symptomGive the error, stack trace, recent change and what “fixed” means, and ask for a failing test first.
Letting Claude silence an error to make the build passAsk for the root cause explicitly and verify with a reproduction test.
Granting Claude write access to production during an incidentInvestigate read-only in plan mode; a human approves and runs remediation.
Pasting entire logs into the conversationFilter with a hook or CLI, or delegate log processing to a subagent that returns a summary.
Editing more config files when a rule or tool “doesn’t work”Check what loaded with /context, /status, /mcp or /hooks, and isolate with --safe-mode.
Turning on full prompt and tool-content logging fleet-wide by defaultCollect usage and cost metrics broadly; enable content logging only with a clear data-handling reason.

You should now be able to

  • Structure a debugging request around evidence, scope and a reproducible check.
  • Keep large logs and test output out of the main context with hooks, CLIs or subagents.
  • Bound Claude’s access during incidents with read-only tools, plan mode and human approval.
  • Diagnose configuration problems with /context, /status, /mcp, /hooks, /doctor, --debug and --safe-mode.
  • Deploy OpenTelemetry through managed settings and use its metrics and events to explain usage and cost.
  • Trace a spend spike to a cause such as long sessions, model choice or a verbose tool.

Practice questions

Original questions written for this lesson, in the exam’s style. Answer first, then open the reasoning — every option is explained, including why the wrong ones are tempting.

  1. Question 1

    A developer says Claude Code keeps ignoring the rule “use pnpm, never npm”, which is in a CLAUDE.md inside the web/ subdirectory. They started the session from the repository root and asked Claude to add a dependency.

    What should they check first?

    1. AReinstall Claude Code in case the memory loader is corrupted.
    2. BMove the rule into managed settings so it cannot be overridden.
    3. CRun /context to see whether that CLAUDE.md has loaded yet.
    4. DRepeat the rule in capital letters three times in the root CLAUDE.md.
    Show answer and reasoning
    1. AIncorrect. Nothing points to a broken install; reinstalling changes nothing if the file simply hasn’t loaded yet.
    2. BIncorrect. Managed settings don’t hold prose instructions like this, and the likely issue is loading, not precedence.
    3. CCorrect. Subdirectory CLAUDE.md files load on demand when Claude reads a file there. /context shows whether it is in the window at all.
    4. DIncorrect. Emphasis doesn’t help a file that hasn’t loaded, and heavy emphasis everywhere dilutes it.

  2. Question 2

    During an incident, an SRE wants Claude Code to investigate elevated error rates using the company’s observability MCP server and the production Kubernetes cluster.

    Which setup best balances speed and safety?

    1. AStart with bypassPermissions so Claude isn’t slowed down by prompts.
    2. BRead-only credentials and tools, plan mode, and a human approving any remediation.
    3. CGive Claude cluster-admin so it can restart pods as soon as it finds the cause.
    4. DKeep Claude out of incidents entirely and use it only for the post-mortem.
    Show answer and reasoning
    1. AIncorrect. Removing permission checks in production is how a debugging session becomes a second incident.
    2. BCorrect. Claude can gather and correlate evidence quickly, while anything that changes production stays a deliberate human decision.
    3. CIncorrect. Broad write access speeds one step and removes the human judgement the incident process relies on.
    4. DIncorrect. That forgoes documented value in diagnosis; the risk can be managed by scoping access.

  3. Question 3

    A team’s internal MCP server shows as connected in /mcp but lists zero tools. Which two steps does Claude Code’s guidance suggest? (Select 2.)

    1. ASelect Reconnect for the server from /mcp.
    2. BIf still zero, run claude --debug=mcp and read the server’s stderr in the debug log.
    3. CMove the server definition into .claude/settings.json under mcpServers.
    4. DRaise MAX_MCP_OUTPUT_TOKENS so the tool list fits.
    5. EAdd mcp__* to the allow list in permissions.
    Show answer and reasoning
    1. ACorrect. A connected server returning no tool list may recover on reconnect; it’s the first documented step.
    2. BCorrect. The debug log captures what the server printed, which usually explains why no tools were returned.
    3. CIncorrect. settings.json doesn’t read an mcpServers key; project servers belong in .mcp.json at the repository root.
    4. DIncorrect. That limit governs tool output size, not whether a server advertises tools.
    5. EIncorrect. An unanchored mcp__* allow glob is skipped, and permissions don’t create missing tools anyway.

  4. Question 4

    A security team asks the platform team to “turn on full logging” of every Claude Code prompt and tool output across the company, to support future investigations.

    What is the most appropriate response?

    1. AEnable all content-logging variables fleet-wide; more data is always safer.
    2. BDecline any telemetry, because OpenTelemetry cannot be centrally configured.
    3. CRely on each developer’s /usage screen instead of central telemetry.
    4. DDeploy metrics and events centrally, and enable content logging only for a defined, approved purpose.
    Show answer and reasoning
    1. AIncorrect. Prompts and tool output can contain source code, secrets and personal data; collecting all of it creates a new sensitive data store.
    2. BIncorrect. It can: managed settings can set the telemetry environment variables on every machine.
    3. CIncorrect. /usage is local to one machine and doesn’t give an organisation-wide view.
    4. DCorrect. Content is redacted by default for good reason. Usage and event data cover most operational needs; content logging is a deliberate data-handling decision.

Practise every question in Domain 7 →

Sources

Drafted with AI assistance and checked against the sources above; expert review is in progress. Spotted an error? Tell us and it gets fixed, dated and listed on how this is written.