Claude Certified Developer - Foundations (CCDV-F) practice questions

Four product teams each maintain their own Claude-powered application, and all four need read access to the same internal inventory service. The platform team owns that service and must be able to change its query surface without each product team editing prompts or redeploying. Which approach best satisfies that ownership boundary?

• AHave the platform team publish an MCP server exposing the inventory service, and have each application connect to it as a client.check_circle Correct
• BWrite the inventory query rules into each application's system prompt and circulate an updated prompt whenever the platform team changes the service.
• CGive each product team a copy of a client library and let each one implement its own custom tool against the inventory service inside its own application.
• DHave the platform team export inventory snapshots on a schedule and have each application paste the current snapshot into the context window on every request.

Why A is correct: Correct because the Model Context Protocol exists to make one integration reusable across applications, and the server is versioned and operated by the team that owns the underlying service.

Why B is wrong: Tempting because a system prompt is the fastest place to add behaviour and needs no new infrastructure, but it puts the platform team's logic inside four codebases they do not own, so every change becomes four coordinated edits.

Why C is wrong: Tempting because a single custom tool really is the right unit when only one application needs an integration, but here it duplicates the same integration four times and leaves the platform team unable to change the surface centrally.

Why D is wrong: Tempting because it removes any live dependency and looks cheap to build, but it burns context on every call, serves stale data between exports, and still leaves four teams parsing the export format.

A finance team processes invoices through five fixed steps that run in the same order for every invoice: extract fields, validate totals, classify the cost centre, check the amount against an approval threshold, and write a record to the ledger. The steps never vary, the team must be able to point at which step failed for any given invoice, and an audit requirement says the sequence of steps must be reproducible six months later. Which architecture fits these constraints best?

• AAn agent given the five steps in its system prompt and a set of tools, left to decide the order of tool calls for each invoice as it reasons through the document.
• BA deterministic workflow that calls Claude at the individual steps that need language understanding, with the ordering, branching and error handling expressed in application code.check_circle Correct
• CA manager agent that delegates each of the five steps to a dedicated subagent and merges their results once every subagent has reported back on the invoice.
• DA single model call that receives the whole invoice and the five step descriptions and returns the ledger record, with a validation pass over the returned structure.

Why A is wrong: Tempting because a model that can call the same five tools looks equivalent and needs less orchestration code, but the order becomes a model decision that can differ per invoice, which defeats both the per-step failure attribution and the reproducibility requirement.

Why B is correct: Correct: the path is fixed and known in advance, so the control flow belongs in code, and each model call sits at a named step whose input, output and failure are individually observable and repeatable.

Why C is wrong: Tempting because one subagent per step maps neatly onto the five steps, but delegation buys context isolation for open-ended exploration, and here it adds a coordination layer and a nondeterministic ordering decision that the fixed sequence does not earn.

Why D is wrong: Tempting because it is the cheapest thing to build and structured output does catch malformed results, but collapsing five steps into one call leaves nothing to attribute a failure to, and validating the final shape says nothing about which step went wrong.

A logistics assistant answers delivery questions by calling one internal tracking tool. Support has measured that 6 per cent of conversations end with a confident delivery date that the carrier system never supplied. A stored trace for one such conversation is reproduced below. The team must attribute the failure to a specific layer before proposing a fix. What does the trace establish?

turn 2  assistant  tool_use  track_shipment {"ref": "SH-40182"}
turn 3  user       tool_result is_error=true
                   content: "upstream timeout after 30000 ms"
turn 4  assistant  text  "Your parcel is due on Thursday."
turn 4  stop_reason: end_turn

• AThe model ignored the tool it was given, so the tool description should be rewritten to state more firmly that the tracking tool must be called before any delivery date is given.
• BThe generation was cut short by the output limit, so the integration should raise the token ceiling on the request and replay the conversation to obtain the full answer.
• CThe tracking dependency timed out and the integration passed that failure back as an ordinary tool result, so the recovery path for a failed tool call is the layer at fault rather than the model's reasoning.check_circle Correct
• DThe model invented a delivery date without provocation, so the sampling temperature on the request should be lowered until the fabricated dates stop appearing in production traffic.

Why A is wrong: Tempting because tool descriptions do influence tool selection, but the trace shows the tool WAS called at turn 2, so a description rewrite treats a fault the trace has already ruled out.

Why B is wrong: Tempting because truncation is a common cause of odd endings, but the recorded stop reason is a normal end of turn rather than a limit, so no truncation occurred.

Why C is correct: Correct: the trace records an errored tool result carrying a timeout, and the application had no rule for what to do when a tool fails, so the model was left to answer from conversation text.

Why D is wrong: Tempting because the answer is indeed unsupported, but sampling settings do not decide what happens when a dependency fails, and the invented date has a recorded upstream cause.