CCDV-F - Applications and Integration (33.1% of the exam) - Section 2.4
Apply core software engineering principles and practices when building Claude applications.
Published skill weight 7.4 percent, the second largest single skill on the exam. Covers REST APIs, JSON, asynchronous programming, version control, integration into the software development life cycle, code review, and refactoring at both small and large scale.
REST APIsJSONasynchronous programmingversion controlSDLC integrationcode review and refactoring
Practice question for this objective
lock_openFree sampleApplications and Integrationmedium
A team edits the system prompt of a customer-facing Claude assistant by pasting new text into a hosted configuration console, which applies the change immediately. After a quality regression, the team could not establish which wording had been live the previous week or who had changed it, and the rollback took most of a day. The team must be able to attribute and reverse any future prompt change with the same speed as a code rollback. What should it change?
AKeep editing in the console but require that each change be announced in the team channel beforehand, with the previous wording pasted in so it can be restored later.
BKeep editing in the console and have a scheduled job snapshot the live prompt into object storage each night, so a previous day's wording can always be retrieved.
CMove the prompt into a database row the application reads at startup, and record the edit timestamp on the row so the team can see when the wording last moved.
DStore the prompt as a file in the application repository so that every change arrives as a reviewed, attributed commit, and let the deployment pipeline read the prompt from the released build.check_circle Correct
Keep prompts under version control alongside application code so review, attribution and rollback use the existing release process. A prompt determines application behaviour as directly as code does, so it needs the same guarantees. Holding it in the repository gives an immutable history, an author on every change, a review point before release and a rollback that is a redeploy of a known commit rather than a reconstruction from memory.
Why A is wrong: It creates a record, which is why it feels sufficient, but the record lives outside the release and depends on someone remembering, so the live text and the note can drift apart without anything detecting it.
Why B is wrong: Nightly snapshots do give a recoverable copy and are better than nothing, but a change made and reverted within a day leaves no trace, and the snapshot names no author and carries no review.
Why C is wrong: Reading from a row does centralise the value and the timestamp answers when, but a single mutable row keeps no prior versions, so the team still cannot see what the wording was or who replaced it.
Why D is correct: Correct, because it makes the prompt an ordinary versioned artefact, so history, authorship, review and rollback are the mechanisms the team already has for code rather than a second process built for prompts.
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 whole MCP server declaration out of the committed configuration and into each engineer's uncommitted local settings, so no part of the integration is visible in the repository.
errorWhy it is wrong: This does hide the credential, but it also removes the server declaration from review and lets each machine define a different tool surface, reintroducing the drift the shared configuration prevents.
Describe the pagination behaviour of the endpoint in the tool description so that the model requests each subsequent page itself until it sees no further token.
errorWhy it is wrong: Pushing paging into the model is workable in principle and looks like good tool design, but it spends a model turn per page, and a paging loop driven by generated arguments can stop early, which leaves the same class of incomplete answer the audit already recorded.
Switch production to the newer version straight away, because a newer version is the safer default and any regression can simply be rolled back afterwards.
errorWhy it is wrong: Tempting because rollback exists, but it moves the accuracy test onto live users and gives no evidence the floor still holds before the change lands.