CCDV-F - Claude Code (3.1% of the exam) - Section 3.1
Operate Claude Code across its core components, features, and configuration.
Published skill weight 3.1 percent, and this skill is the whole domain. Covers Rules, Skills, Commands, Agents and Agent Memory as core components; session management, built-in and custom slash commands, headless mode, streaming mode and auto-mode as features; and the CLAUDE.md hierarchy, repository initialisation and settings.json configuration.
A platform team wants Claude Code to draft a short explanation of every failing nightly build. The step runs inside the continuous integration pipeline with no engineer at the terminal, finance has set a fixed spend ceiling per pipeline run, and the pipeline must fail cleanly rather than wait forever if the step stalls. Which way of invoking Claude Code fits those constraints?
ARun Claude Code interactively on a shared build machine and have the pipeline job attach to that terminal session, so an engineer can approve each step when one happens to be online.
BInvoke Claude Code headlessly but leave permissions and run length unset, relying on a clearly worded instruction in the repository's CLAUDE.md telling the agent to stop early and stay within the budget.
CInvoke Claude Code in its non-interactive headless mode from the pipeline script, with an explicit ceiling on turns or spend for the run and tool permissions defined in the repository's checked-in settings.json.check_circle Correct
DHave the pipeline post the failing build log to a hosted chat assistant through an ad hoc script, then poll that conversation until a reply arrives and paste the reply into the build comment.
Scripted Claude Code steps need headless invocation, an explicit run ceiling and committed settings.json permissions rather than written instructions. A pipeline step has no human to answer prompts, so the invocation must be non-interactive and must carry its own bound on how long or how much it may run. Permissions committed in settings.json make that behaviour reproducible across build agents and reviewable before it changes, which an instruction in a context file cannot guarantee.
Why A is wrong: Attaching to an interactive session is tempting because approvals feel safer, but the stem states nobody is at the terminal, so the job would block on prompts and the pipeline could never fail cleanly.
Why B is wrong: This looks right because headless invocation is correct, but a written instruction is advice the agent may not follow, so neither the spend ceiling nor the clean failure is actually enforced by anything.
Why C is correct: Headless invocation needs no terminal, the explicit run ceiling gives the pipeline a bounded failure instead of an open-ended wait, and committed settings.json makes the permission surface identical on every build agent and reviewable in a pull request.
Why D is wrong: Polling a chat surface seems to avoid the terminal problem, but it discards the repository context that makes the explanation useful and reintroduces the unbounded wait the team must avoid.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCDV-F bank for this domain.
Run Claude Code interactively on the build agent under a service account, and have an engineer approve tool use for the first run of each day so later runs inherit that decision.
errorWhy it is wrong: Tempting because a single daily approval sounds like a small burden, but an interactive run still blocks whenever a new tool is requested, which is the stall the operations rule forbids.
In a per-session opening message that each engineer keeps in a shared snippet file and pastes at the start of every Claude Code session on the repository.
errorWhy it is wrong: Tempting because a shared snippet does make the wording consistent between engineers, but it still depends on a person remembering to paste it, which is precisely the omission the review measured.
Keep the single long session running and re-state the agreed conventions in the chat at the start of each working day, so the most recent turns always carry the decisions the refactor depends on.
errorWhy it is wrong: Re-stating the conventions does put them back into recent history, but it leaves the decisions living only in a transcript that keeps growing, so the same drift returns as later work pushes them back again.