Five real, previously unpublished CCA-F practice questions for Prompt Engineering & Structured Output (20% of the exam). Try to answer each one yourself before revealing the explanation — that's how you actually find the gaps in your understanding.
Practice the full domain-filtered set on AICert Study →
Question 1
A code-review category for 'unused variables' has a 70% false positive rate and developers have started ignoring all bot comments, including from accurate categories. What is the most pragmatic short-term action while the prompt is being improved?
- A. Add an extra instruction to 'double-check unused variable findings' and keep the category enabled
- B. Temporarily disable the 'unused variables' category so accurate categories regain developer trust
- C. Increase the model size to a larger Claude model and keep the category enabled
- D. Post all 'unused variable' findings as low-priority labels instead of inline comments
Show answer & explanation
Correct answer: B
High false-positive categories undermine trust in the entire bot, including accurate categories. Temporarily disabling the failing category restores developer confidence while you iterate on the prompt offline, then re-enable it once precision is acceptable.
- Add an extra instruction to 'double-check' is incorrect. Vague self-check instructions rarely fix categorical false positives, and developers continue to see the noise until precision is measurably better.
- Increase the model size is incorrect. The root cause is missing/ambiguous criteria in the prompt; a bigger model still applies the same vague rules and trust does not recover.
- Post findings as low-priority labels is incorrect. The noise still appears in the workflow and developers still tune out the entire bot; trust degradation is not driven by label color but by signal-to-noise.
Share this question on LinkedIn →
Question 2
You are building an invoice extraction system that must return JSON conforming to a fixed schema with fields like invoice_number, total, and currency. Which approach offers the strongest guarantee that the response will be syntactically valid JSON matching your schema?
- A. Ask Claude in plain prose to 'return valid JSON only' and parse the response
- B. Wrap the user's request in XML tags asking for JSON output
- C. Prefill the assistant turn with a partial JSON object
- D. Define a tool whose input_schema is your JSON schema and call it with tool_choice forcing that tool
Show answer & explanation
Correct answer: D
Defining a tool with your JSON schema as its input_schema and forcing the model to call that tool (tool_choice = {type: 'tool', name: ...}) is the most reliable approach for schema-compliant structured output. The model produces tool input that matches the declared schema, eliminating JSON syntax errors and missing-key issues.
- Ask in plain prose is incorrect. Free-form requests for 'valid JSON' frequently produce trailing commentary, code fences, or minor syntax errors that break downstream parsers.
- Prefill the assistant turn is incorrect. Prefilling can nudge format but does not enforce schema, and still produces text the parser must validate (unlike tool use, where the model output is constrained by a schema).
- Wrap the request in XML tags is incorrect. XML tagging improves clarity but provides no enforcement; the response is still ungoverned text.
Share this question on LinkedIn →
Question 3
You need to process 50,000 historical PDFs overnight to extract structured metadata. The job is non-blocking and you want to minimize cost. Which API is the best fit?
- A. The Message Batches API, which charges 50% of standard pricing with a 24-hour processing window
- B. The standard synchronous Messages API with parallel requests
- C. The streaming Messages API to reduce time-to-first-token
- D. The Files API with synchronous extraction calls
Show answer & explanation
Correct answer: A
The Message Batches API is purpose-built for high-volume, latency-tolerant workloads. It charges 50% of standard pricing and processes batches asynchronously within a 24-hour window, which exactly fits an overnight 50,000-document extraction job.
- Standard synchronous Messages API with parallel requests is incorrect. You pay full price and still must manage concurrency, retries, and rate limits yourself.
- Streaming Messages API is incorrect. Streaming reduces perceived latency for interactive UIs but does not lower price or address bulk throughput.
- Files API with synchronous extraction calls is incorrect. The Files API stores documents but does not provide a discounted async processing tier; you would still pay full per-request pricing.
Share this question on LinkedIn →
Question 4
A pre-merge CI check must block the PR until review findings are returned. Why is the Message Batches API a poor fit for this workflow?
- A. Batches do not support JSON output, only plain text
- B. Batches have no guaranteed latency SLA and may take up to 24 hours, which is incompatible with a blocking pre-merge gate
- C. Batches cost more than synchronous calls so a CI check would be expensive
- D. Batches require a paid enterprise tier that most CI providers cannot access
Show answer & explanation
Correct answer: B
The Message Batches API explicitly does not offer a latency guarantee; most batches complete in under an hour but the documented window is up to 24 hours. Blocking workflows like pre-merge checks require predictable, bounded latency and should use the synchronous Messages API.
- Batches do not support JSON output is incorrect. Any request you can send to the Messages API, including tool use for JSON, can be sent as a batch request.
- Batches cost more than synchronous calls is incorrect. Batches are 50% cheaper than synchronous calls; the issue is latency, not cost.
- Batches require a paid enterprise tier is incorrect. The Batches API is generally available on the standard API; access is not the blocker.
Share this question on LinkedIn →
Question 5
You ask a single Claude instance to generate a code review and then ask the same instance to 'review your own findings and remove any that are not solid'. Why does this often fail to catch false positives?
- A. Self-review consumes 2x the tokens and times out in CI
- B. Self-review keeps the model's prior reasoning context, making it less likely to question its own decisions than an independent reviewer would
- C. Claude refuses to critique itself for safety reasons
- D. Self-review only works when extended thinking is disabled
Show answer & explanation
Correct answer: B
When the reviewing instance shares the same conversation history as the generating instance, it inherits the original reasoning and is biased toward confirming its prior conclusions. Independent review instances that receive only the code and findings (without the prior reasoning) catch subtle errors more reliably.
- Consumes 2x the tokens and times out is incorrect. Token usage is a cost concern, not the reason self-review misses false positives.
- Claude refuses to critique itself for safety is incorrect. The model will critique its own output when asked; the issue is bias, not refusal.
- Self-review only works when extended thinking is disabled is incorrect. Extended/adaptive thinking does not change the fundamental bias toward prior reasoning.
Share this question on LinkedIn →
Want more? Our free bank has hundreds of Prompt Engineering & Structured Output questions. Practice them all →
