CCDV-F - Prompt and Context Engineering (11% of the exam) - Section 6.3
Produce, validate, and consume Claude output using established patterns.
Published skill weight 2.6 percent. Covers structured output patterns, response validation, defensive parsing, and maintaining scepticism toward confident output, which is the disposition this skill is really testing: a confident answer is not a validated one.
lock_openFree samplePrompt and Context Engineeringmedium
A claims service asks Claude to return a claim record through a tool whose input schema declares an amount as a number and a claim type as a string. Every returned object parses cleanly and matches the declared types, yet finance has recorded eleven payments last quarter whose amount exceeded the policy cap of 5,000 pounds for the stated claim type. The requirement is that no claim breaching the cap reaches the ledger. Which change to the integration layer meets it?
ATighten the tool's input schema so that the amount field carries the policy cap for each claim type in its field description, and leave the parsing path unchanged.
BWiden the exception handling around the parse call so that a record carrying an out-of-policy amount is caught there and re-requested from the model with reworded instructions.
CConfigure the parser in strict mode so that it rejects any object whose fields do not match their declared types, which will also stop amounts that sit above the policy cap.
DAdd a validation step after parsing that checks the parsed record against the policy rules for its claim type, and reject any claim above the cap before the ledger write happens.check_circle Correct
Structured output and defensive parsing cannot enforce business rules; validating the parsed record against policy is a separate required step. A tool input schema constrains the shape of the returned object and a parser confirms that shape survived transport, but neither can decide whether a well-typed value is permitted by policy. Only a validation pass over the parsed record, run before the side effect, can reject an amount that is structurally perfect and commercially wrong.
Why A is wrong: Tempting because the schema is where the field is defined, so it looks like the natural home for the rule. A description is guidance to the model rather than an enforced constraint, so an over-cap amount can still be produced and still parses cleanly.
Why B is wrong: Tempting because defensive parsing is a real step and does belong at this boundary. A parse succeeds on an over-cap amount, so no exception is raised and the handler never runs.
Why C is wrong: Tempting because strict parsing genuinely removes a class of defect. Type checking answers whether the amount is a number, not whether the number is allowed, so every over-cap payment still passes.
Why D is correct: Correct: schema conformance and business validity are separate questions, and only an explicit validation step run on the parsed object can decide whether a well-formed amount is permitted.
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.
Parse the response, and where parsing fails inspect the text for a partial object, treating a truncated body and an out-of-policy amount as two symptoms of the same malformed-response condition.
errorWhy it is wrong: Tempting because both conditions do end in a rejected record and one code path looks simpler to operate. Merging them destroys the attribution the operator requires and hides that truncation needs a different remedy.
Write the record to the ledger with the failing field left null, and raise a background job that asks a reviewer to complete it later that day.
errorWhy it is wrong: Tempting because it keeps throughput high and looks like graceful degradation, but it puts an unchecked record into the ledger, which is exactly what the stated rule forbids.
Keep the repair retries but raise the number of attempts, because a fragment this close to complete usually parses correctly on a fourth or fifth pass through the repair prompt.
errorWhy it is wrong: Tempting because the fragment looks nearly complete and repair sometimes rescues malformed output. Each further attempt regenerates against the same low ceiling and truncates again, so it adds spend without changing the outcome.