CCDV-F Practice Questions: Prompt and Context Engineering Domain

Correct answer (B): The failure is caused by context drift: stale or contradicted information remains in the context window and continues to influence the response. The best first fix is to remove or compact the old history so the current state is explicit and obsolete assumptions are not competing with it.

Why the other options are wrong:
- Option A: Increasing response length may produce a longer answer, but it does not remove the stale assumption that is steering the model.
- Option C: A reminder may help slightly, but it leaves the contradictory context in place and is less direct than resetting or compacting the task state.
- Option D: Appending more raw transcript increases context bloat and may bury the correction rather than eliminating the stale information.

Correct answer (A): Prompt instructions should explicitly state required fields, types, and allowed values, but production code should still validate Claude's output before using it. Defensive parsing is needed because prompt wording alone cannot guarantee exact schema compliance.

Why the other options are wrong:
- Option B: A general reminder is weaker than specifying the exact schema and does not add the required application-level validation.
- Option C: Silent coercion may hide invalid model output and can create incorrect downstream behavior when the allowed enum and types are strict.
- Option D: Reducing fields may lower complexity, but it changes the required contract rather than solving the schema-compliance and validation issue.

Correct answer (A): For a critical downstream action, prompt wording alone is not enough. The application should remain skeptical of confident outputs and validate extracted values against the source context before using them to create payment requests, with safe handling for mismatches.

Why the other options are wrong:
- Option B: Stronger wording can reduce errors but cannot guarantee correctness, especially when money movement depends on the output.
- Option C: Plausibility is not the same as source correctness and is unsafe for a payment-triggering workflow.
- Option D: More examples or receipts may add noise and does not directly verify the current extracted amount.

Correct answer (A): Prompt refinement should target the observed failure mode. Since the issue is invalid labels, the prompt should provide explicit allowed values and require an exact selection, ideally paired with downstream validation in the application.

Why the other options are wrong:
- Option B: General guidance adds context but does not directly constrain the invalid-label failure mode.
- Option C: Allowing any descriptive label makes the exact problem worse by encouraging unconstrained outputs.
- Option D: Post-processing may catch some variants, but removing label constraints reduces reliability at the generation step.

Correct answer (A): This is context drift: stale prior context is influencing the current answer. The best primary mitigation is to reset, prune, or compact the context so only the current jurisdiction and relevant facts remain salient.

Why the other options are wrong:
- Option B: Repeated reminders add more tokens and may not overcome stale, conflicting context that remains in the window.
- Option C: Keeping the full transcript preserves the outdated California context that is already causing incorrect answers.
- Option D: More examples add bloat and do not directly remove the stale jurisdiction that is contaminating the answer.

Correct answer (B): Structured output should be explicitly constrained and validated by application code. When validation fails, a targeted repair or retry that includes the specific validation errors is safer than accepting malformed JSON, silently coercing fields, or pushing ambiguity downstream.

Why the other options are wrong:
- Option A: Loosening the parser may reduce failures but can hide malformed or semantically invalid outputs, such as unsupported enum values.
- Option C: A general request to be careful is weaker than explicit schema constraints and does not provide a robust recovery path for parse failures.
- Option D: Passing raw model text downstream spreads the parsing problem and makes downstream behavior less predictable.

Correct answer (A): When answers must be grounded in provided context, the prompt should explicitly constrain the source of truth and define how to handle uncertainty or missing evidence. Requiring a specific fallback such as "not found" reduces unsupported confident output.

Why the other options are wrong:
- Option B: Using general knowledge may fill gaps, but it conflicts with the requirement to avoid unsupported answers from outside the provided excerpt.
- Option C: A confidence score can appear useful, but it does not prevent unsupported answers if evidence is still not required.
- Option D: Longer explanations may make unsupported reasoning more persuasive without improving grounding.

Correct answer (C): For document-grounded tasks, the prompt should define how Claude uses source material and what to do when support is insufficient. The retrieved clauses support customer convenience termination, not vendor convenience termination, so the desired behavior is to avoid unsupported confident claims.

Why the other options are wrong:
- Option A: Less certainty changes tone but does not enforce source-grounded reasoning or insufficient-evidence behavior.
- Option B: More unrelated context can bloat the prompt and does not address the unsupported claim pattern.
- Option D: Rewriting clauses may preserve the same misunderstanding and adds an unnecessary transformation step.

Correct answer (B): Tool results should be pruned before being added to the model context. Because the decision requires specific eligibility fields, the best approach is to pass only those fields and concise supporting evidence. This reduces context bloat while preserving the information Claude needs for the current task.

Why the other options are wrong:
- Option A: The full response contains large irrelevant sections, which increases context bloat and can distract from the decision fields.
- Option C: A summary can be useful, but omitting the specific dates and eligibility fields removes facts needed for the decision.
- Option D: Old chats and complete raw output add irrelevant context, increasing the chance of drift or distraction.

Correct answer (A): Durable application behavior should be expressed in developer-controlled instructions rather than relying on users or retrieved content to repeat critical constraints. This makes the desired behavior consistently present for each request and separates application policy from user-provided task data.

Why the other options are wrong:
- Option B: User text should be treated as task data or intent, not as the reliable place for application-wide behavioral constraints.
- Option C: Retrieved documents may or may not be present and are source context, not the right location for durable response rules.
- Option D: Examples can reinforce a pattern, but relying only on examples is weaker than explicitly stating durable constraints.