CCDV-F - Applications and Integration (33.1% of the exam) - Section 2.5
Apply design considerations specific to building Claude applications.
Published skill weight 8.6 percent, the largest single skill on the exam. Covers how Claude interprets instructions differently across Claude Code, Desktop, claude.ai, the API and the SDKs, plus content boundaries, schema design, session hygiene and plugin management.
instruction interpretation across interfacescontent boundariesschema designsession hygieneplugin management
Practice question for this objective
lock_openFree sampleApplications and Integrationmedium
A banking assistant keeps one conversation per customer that never ends, so a session started in January still carries every turn since. Support has measured that answers about the customer's current account selection are wrong in a rising share of long sessions, because a selection made months earlier still sits in the history. The bank requires that each advisory enquiry be answered against the customer's present account state. How should the application handle session boundaries?
AScope a session to one enquiry, start it with the customer's current account state fetched at that moment, and carry only a durable summary of past enquiries forward.check_circle Correct
BKeep the single unbounded conversation and add a system-prompt line telling the assistant to prefer the most recent account mentioned in the history.
CKeep the unbounded conversation and raise the number of turns retained before trimming, so no part of the customer's history is ever dropped.
DKeep the unbounded conversation and rewrite each old turn in place whenever the customer changes account, so the stored history reads consistently.
Bound a session to the unit of work whose state must be fresh, and carry only a controlled summary across the boundary. Stale state persists because the conversation, not the enquiry, is the unit of state. Scoping the session to one enquiry and seeding it with freshly fetched account data means the contradictory older turn is structurally absent rather than merely deprioritised by an instruction, which is what turns a reduced failure rate into a removed one.
Why A is correct: Correct because a bounded session cannot contain a stale selection at all: the state is read at session start and the only thing crossing the boundary is a summary the application controls.
Why B is wrong: Tempting because it is a one-line change that names the failure, but instructions do not remove the stale turns, so the model still sees two conflicting selections and the failure rate only drops rather than going to zero.
Why C is wrong: Tempting because losing history looks like the cause, but retaining more turns preserves more contradictory state and worsens the measured failure while raising cost per turn.
Why D is wrong: Tempting because it directly removes the contradiction, but editing a stored transcript destroys the record of what was actually said and advised, which a bank cannot do.
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.
Raise the sampling temperature before launch so that the summariser's answers vary enough to surface edge cases during the first week of use.
errorWhy it is wrong: Tempting because varied output looks like broader coverage, but temperature is a generation setting rather than a test method, and it makes regressions harder to reproduce.
Add a sentence to the system prompt asking the model to send a well-formed date on every booking call, and restate the expected format in the tool's text description.
errorWhy it is wrong: Wording the request more clearly does shift the rate somewhat, which is what makes it tempting, but an instruction is advice rather than a constraint and leaves the schema itself permitting the malformed arguments.
Release to all 4,000 staff on the first day, so that the latency measurement covers the full load pattern rather than an unrepresentative sample of it.
errorWhy it is wrong: Tempting because full load is the truest test, but it exposes every user to an unmeasured build and leaves nothing to reverse to within the stated window.