CCDV-F - Applications and Integration (33.1% of the exam) - Section 2.6
Manage configuration across Claude system components.
Published skill weight 4.1 percent. Covers CLAUDE.md files, settings.json, model version pinning, prompt versioning and plugin dependencies, treating the prompt and the model choice as versioned configuration rather than as incidental detail.
CLAUDE.mdsettings.jsonmodel version pinningprompt versioningplugin dependencies
Practice question for this objective
lock_openFree sampleApplications and Integrationmedium
A returns service exposes one tool that looks up an order in a warehouse system. Every incoming request is known to be an order enquiry, and an audit of live traffic shows that in 9 per cent of requests the model answers from the conversation text without calling the tool, producing an unverified status. The team requires that every reply be backed by a lookup. Which change enforces that?
AAdd a firmly worded system-prompt instruction stating that the lookup tool must be called before any order status is given to the customer.
BEnrich the tool description with a longer account of when the tool applies, so the model recognises more of the enquiries that require a lookup.
CSet tool_choice so that the first turn is required to use the lookup tool, and continue the loop with the tool result before returning any reply.check_circle Correct
DRetry any request whose reply contains no order status, since a second attempt gives the model another opportunity to invoke the lookup tool.
Use tool_choice to force a required call when the application already knows a tool must run, rather than relying on prompt instructions. When the calling code has already established that a tool must run, the decision belongs in the request rather than in the model's discretion. Constraining tool selection makes the lookup a precondition of the turn, which removes the measured failure class instead of reducing its frequency.
Why A is wrong: Prompt wording does raise compliance and is often the first thing tried, but it remains advisory, so a measured residual failure rate persists rather than going to zero.
Why B is wrong: Better descriptions genuinely improve selection when several tools compete, but here there is one tool and the problem is skipping it entirely, not choosing between alternatives.
Why C is correct: Correct: the application already knows a lookup is needed on every request, and constraining tool selection makes that a property of the call rather than a hope about the model's judgement.
Why D is wrong: Retrying is a reasonable reliability habit, but the failing replies do contain a status, just an unverified one, so the check would not fire on the cases that matter.
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.
Move the model identifier into an environment variable set by hand on each host at deployment time, and record the value in the deployment ticket for later reference.
errorWhy it is wrong: Tempting because it removes the identifier from the code, but a value set by hand on a host is not reviewed before it changes and the ticket is a description of intent rather than the value the service actually used.
Raise max_tokens on the request, so the model has room to emit the full tool invocation instead of stopping in prose part way through its response.
errorWhy it is wrong: Tempting because a truncated response can look like a skipped step, but the observed failure is a complete prose answer rather than a cut-off one, so a larger output allowance changes nothing about whether the tool is chosen.
The system prompt must instruct the model to state the policy revision it used, and reviewers must sample answers each month to confirm that the instruction is being followed.
errorWhy it is wrong: Tempting because the answers would usually carry a revision label, but an instruction is guidance the model can omit under pressure, so the audit trail would depend on generated text rather than on a recorded fact.