16 Prompt Engineering & Structured Output Practice Questions & Answers
Every Prompt Engineering & Structured Output practice question from the Claude Certified Architect – Foundations Practice Test, with the correct answer and a short explanation.
Start practice test →1. A CI code-review bot is prompted with: "Flag any code that looks problematic or risky." It floods pull requests with false positives. According to prompt-engineering best practice, what is the most effective fix?
- A.Replace the vague instruction with explicit categorical criteria that enumerate exactly which issue types to flag (e.g., SQL built by concatenating user input, hardcoded credentials) and state that anything outside those categories should not be flagged✓ Answer
- B.Increase max_tokens so the model has more room to reason before flagging
- C.Run the same vague prompt twice and flag only issues found both times
- D.Add the sentence "Please be very careful and accurate" to the prompt
Vague criteria like "looks problematic" force the model to guess where the decision boundary is, so it over-triggers. Explicit categorical criteria work because they convert a subjective judgment into a checklist the model can match against, which raises precision and cuts false positives; generic exhortations to "be careful" do not define the boundary, and more tokens or repeated runs do not fix an underspecified instruction.
Source: Anthropic Prompt Engineering docs — "Be clear, direct, and detailed" (docs.claude.com/en/docs/build-with-claude/prompt-engineering/be-clear-and-direct); CCA-F Exam Guide Domain 4Report a problem with this question
2. An invoice-extraction pipeline processes documents from hundreds of vendors with very different layouts, and the model's output format drifts between documents. Which prompting technique most directly improves output-format consistency across varied documents?
- A.Shorten the prompt so the model focuses only on the document
- B.Include few-shot examples in the prompt showing several different-looking input documents each mapped to the same desired output format✓ Answer
- C.Ask the model at the end of the prompt to "always use a consistent format"
- D.Process each vendor with a different model so formats never mix
Few-shot (multishot) examples work because the model imitates demonstrated input-to-output mappings far more reliably than it follows abstract instructions; showing diverse document layouts all converging to one output shape teaches both the format and its invariance across variation. A bare "be consistent" instruction gives no concrete target, and shortening prompts or splitting models does not demonstrate the desired format at all.
Source: Anthropic Prompt Engineering docs — "Use examples (multishot prompting)" (docs.claude.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting)Report a problem with this question
3. A developer needs the model's extraction output to be machine-parseable JSON that always matches a fixed structure, with no risk of malformed JSON. Which approach provides the strongest structural guarantee?
- A.Write "Respond only in JSON" in the system prompt and parse whatever comes back
- B.Give one few-shot example of the JSON and trust the model to copy it
- C.Post-process the free-text response with regular expressions to pull out fields
- D.Define a tool whose input_schema is the desired JSON Schema and force the model to call it, so the returned tool input conforms to the schema✓ Answer
Tool use with a JSON Schema is enforced at the API level: the model's tool input is generated against the declared schema (and with strict/structured-output modes it is validated exactly), so the structure is guaranteed rather than merely requested. Prompt instructions and few-shot examples only make valid JSON likely, and regex post-processing of free text is brittle precisely because the upstream format is not guaranteed.
Source: Anthropic Tool Use docs — tool input_schema and strict tool use / structured outputs (docs.claude.com/en/docs/agents-and-tools/tool-use)Report a problem with this question
4. A medical-records extraction system uses tool use with a strict JSON schema, so every response parses and validates against the schema. Which class of error can this system STILL produce?
- A.String values appearing where the schema requires integers
- B.Semantic errors — fields that are structurally valid but contain wrong or fabricated values, such as a dosage copied from the wrong medication✓ Answer
- C.Malformed JSON with unbalanced braces that fails to parse
- D.Missing required fields that the schema marks as required
Schema enforcement operates on form, not truth: it guarantees the output parses, includes required fields, and uses the declared types, but it cannot verify that the values correctly reflect the source document. Wrong or fabricated content inside a perfectly valid structure is a semantic error, and catching it requires separate verification (grounding checks, human review, or an independent review pass) rather than schema validation.
Source: Anthropic Tool Use / Structured Outputs docs — schema guarantees syntactic validity only (docs.claude.com/en/docs/agents-and-tools/tool-use); CCA-F Exam Guide Domain 4Report a problem with this question
5. A contract-extraction schema requires a "termination_date" string, but many contracts contain no termination date, and the model responds by inventing plausible dates. What is the recommended schema-level fix?
- A.Make the field nullable/optional and instruct the model to return null when the information is not present in the document✓ Answer
- B.Require the model to always fill the field with today's date as a placeholder
- C.Remove the field from the schema entirely so dates are never extracted
- D.Keep the field required but add more retry attempts until a date is produced
A required field forces the model to output something even when the source contains nothing, which structurally incentivizes fabrication; making the field nullable gives the model a legitimate, schema-valid way to say "not present," removing that pressure. More retries repeat the same forced-fabrication dynamic, deleting the field loses real data, and placeholder dates are just institutionalized fabrication.
Source: Anthropic Tool Use / Structured Outputs guidance — optional (nullable) fields prevent hallucinated values when data is absent (docs.claude.com/en/docs/agents-and-tools/tool-use); CCA-F Exam Guide Domain 4Report a problem with this question
6. An expense-classification schema uses an enum of eight fixed categories, but roughly 3% of real invoices genuinely fit none of them, causing forced misclassifications. What is the recommended schema design pattern?
- A.Instruct the model to skip invoices that do not fit any category
- B.Add an "other" value to the enum plus a companion free-text detail field the model fills in when it selects "other"✓ Answer
- C.Duplicate the request across two models and accept whichever category they agree on
- D.Replace the enum with a free-form string field so the model can write any category name
The enum-plus-other pattern preserves the machine-processable guarantee of a closed value set for the common cases while providing a schema-valid escape hatch for genuine outliers; the detail field captures what the outlier actually is so humans can later decide whether a new category is needed. A free-form string destroys the closed vocabulary entirely, skipping documents silently drops data, and dual-model voting still forces both models to choose from an incomplete category list.
Source: Anthropic Tool Use docs — enum constraints in input_schema and best practices for tool definitions (docs.claude.com/en/docs/agents-and-tools/tool-use); CCA-F Exam Guide Domain 4Report a problem with this question
7. An extraction pipeline validates each response against a JSON schema and, on failure, retries with the validation error appended to the prompt (up to 3 attempts). Which failure mode will this retry loop NOT be able to fix?
- A.A response using a string where the schema expects an integer
- B.A required field whose information is genuinely absent from the source document — no number of retries can extract data that is not there✓ Answer
- C.A response where the model wrapped the JSON in markdown code fences
- D.A response missing a closing brace due to output truncation
Validation-retry loops work by feeding the model corrective feedback about formatting mistakes it can act on — code fences, type mismatches, and truncation are all repairable on a second attempt. But when the required information simply does not exist in the source, every retry faces the same impossible demand, and the loop either exhausts its attempts or pressures the model into fabricating a value; the correct remedies are nullable fields or routing to human review.
Source: CCA-F Exam Guide Domain 4 — validation and retry design; Anthropic Structured Outputs guidance on absent data (docs.claude.com/en/docs/agents-and-tools/tool-use)Report a problem with this question
8. Which workload is the best fit for the Message Batches API, and what is the primary economic benefit?
- A.Real-time CI review comments posted while the developer waits, at no discount but higher rate limits
- B.Overnight re-extraction of 50,000 archived invoices, at a 50% discount on standard token prices✓ Answer
- C.Interactive form autofill in a web app, at a 90% discount
- D.A live customer-support chat that must answer within seconds, at a 50% discount
The Batches API processes requests asynchronously — most batches finish within an hour but can take up to 24 hours — in exchange for a 50% discount on token costs, so it only suits workloads where nobody is waiting on the response. Bulk overnight document processing is exactly that profile, whereas live chat, interactive autofill, and blocking CI feedback all require low latency that batch processing cannot promise.
Source: Anthropic Batch Processing docs — 50% discount, asynchronous processing up to 24 hours (docs.claude.com/en/docs/build-with-claude/batch-processing)Report a problem with this question
9. Why must every request in a Message Batch include a custom_id?
- A.Because batch results may be returned in a different order than the requests were submitted, and custom_id is the reliable way to match each result back to its request✓ Answer
- B.Because custom_id lets the API automatically deduplicate identical prompts to save cost
- C.Because custom_id is used to authenticate each individual request within the batch
- D.Because the 50% batch discount is only applied to requests that carry a custom_id
Batch results are not guaranteed to arrive in submission order, so positional matching is unsafe; the documented pattern is to key every result by its custom_id when streaming results back. custom_id has no role in authentication (the API key covers that), pricing eligibility, or deduplication — it exists purely for correlating results with requests.
Source: Anthropic Batch Processing docs — results returned in any order; match by custom_id (docs.claude.com/en/docs/build-with-claude/batch-processing)Report a problem with this question
10. A batch is submitted at the start of a business day. According to the Message Batches API processing window, what happens to requests that are still unfinished when the window ends?
- A.Unfinished requests are automatically converted to standard-priced real-time requests
- B.The entire batch is canceled and no results are returned for any request
- C.Requests not completed within 24 hours are marked as expired in the results, and the caller must resubmit them✓ Answer
- D.The batch keeps running indefinitely until every request completes
The Batches API guarantees a maximum 24-hour processing window: most batches finish much sooner, but any request still unprocessed at the deadline gets result type "expired" rather than blocking the batch forever. Completed requests in the same batch still return their results normally, so expiration is per-request — the caller inspects result types and resubmits only the expired ones.
Source: Anthropic Batch Processing docs — 24-hour maximum processing window; per-request result types including expired (docs.claude.com/en/docs/build-with-claude/batch-processing)Report a problem with this question
11. A developer includes tool definitions in Message Batch requests and the model responds with tool_use blocks. What is the key limitation on tool use inside a batch?
- A.Batches allow tools only if tool_choice forces exactly one specific tool
- B.Each batch request is a single independent call, so you cannot return tool results and continue the same conversation within that batch — the follow-up turn requires a new request✓ Answer
- C.Tool use in batches is allowed but forfeits the 50% discount for that request
- D.Tool definitions are stripped from batch requests, so the model can never emit tool_use blocks
Batch processing is stateless per request: the API executes each request once and stores its single response, with no mechanism to feed a tool_result back and resume that conversation inside the running batch. Tools are fully supported as request parameters (and the discount still applies), but any multi-turn tool-use loop must be driven by the caller across separate requests or follow-up batches.
Source: Anthropic Batch Processing docs — each batch request is processed independently; no in-batch conversation continuation (docs.claude.com/en/docs/build-with-claude/batch-processing)Report a problem with this question
12. A team wants an LLM quality check on its contract-extraction output. Why is sending the output to a separate, fresh model instance for review generally more effective than asking the same conversation that produced it to "double-check your work"?
- A.Independent review is faster because the second instance skips reading the source document
- B.A fresh instance has no attachment to the earlier answer, so it evaluates the output on the evidence alone, whereas the original conversation's context biases the model toward confirming what it already produced✓ Answer
- C.The API charges self-review turns at a higher token rate than new conversations
- D.A model is technically unable to read its own previous messages in the same conversation
When a model reviews output inside the conversation that generated it, the prior reasoning and answer sit in its context and act as an anchor, making agreement with itself the path of least resistance. An independent instance receives only the source document and the candidate output, so its judgment is conditioned on the evidence rather than on a commitment to a previous answer — the same reason human processes separate author and reviewer. Pricing is identical either way, the model can read its own messages, and the reviewer must still read the source to verify.
Source: CCA-F Exam Guide Domain 4 — multi-instance independent review vs self-review; Anthropic guidance on separate verifier passes (docs.claude.com/en/docs/build-with-claude/prompt-engineering)Report a problem with this question
13. An architect deploys an automated code-review system with eight finding categories. After one month, reviewers dismiss over 90% of findings in the 'style' and 'possible performance' categories, and several engineers admit they now skim past ALL findings, including security ones. The prompt criteria for the two noisy categories cannot be properly refined before the next release. What is the most effective immediate action?
- A.Temporarily disable the two high-false-positive categories and keep running the high-precision categories while the noisy criteria are refined offline✓ Answer
- B.Require reviewers to write a justification for every dismissal so they read each finding more carefully
- C.Keep all categories enabled but lower the sampling temperature so the model produces fewer false positives
- D.Add more few-shot examples of security findings so reviewers pay more attention to that category
Alert fatigue generalizes: when most findings in some categories are noise, reviewers learn to distrust the whole system and start ignoring even high-value findings. Because false positives here stem from vague category criteria (a prompt-design problem), not from randomness, lowering temperature does not fix them, and adding examples or dismissal paperwork does not remove the noise that caused the fatigue. Temporarily removing the noisy categories immediately restores the system's signal-to-noise ratio and reviewer trust, and the categories can be re-enabled once their criteria are refined and validated.
Source: CCAR-F Exam Guide, Domain 4: managing precision–recall tradeoffs and reviewer trust; Anthropic prompt engineering guidance on empirically iterating classification criteria (docs.claude.com/en/docs/build-with-claude/prompt-engineering)Report a problem with this question
14. An invoice-extraction schema requires the model to output line_items, a stated_total copied from the document, a calculated_total the model must compute by summing the line items, and a conflict_detected boolean set to true when the two totals differ. What is the primary architectural reason for requiring both totals plus the boolean instead of a single total field?
- A.Forcing the model to produce both values and explicitly compare them surfaces source-document discrepancies as a machine-readable flag for deterministic downstream routing, instead of the model silently choosing one value✓ Answer
- B.The boolean reduces token usage by allowing the model to skip emitting line_items whenever the totals match
- C.Producing two total fields doubles the probability that at least one of them passes JSON schema validation
- D.The calculated_total field lets the API's schema validator verify the arithmetic server-side before returning the response
Schema validation only enforces structure and types — it never checks arithmetic, so option C is false, and a single total field would let the model silently pick either the stated or the computed value when they disagree, hiding the discrepancy. The paired fields act as embedded self-verification: the model performs the sum and the comparison inside its own output, and conflict_detected becomes a deterministic routing signal (for example, send conflicting invoices to human review) that downstream code can branch on without re-parsing the document.
Source: Anthropic structured outputs documentation: schema validation guarantees structure, not semantic correctness; self-verification field pattern (docs.claude.com — prompt engineering & structured output); CCAR-F Exam Guide Domain 4Report a problem with this question
15. A code-review platform contractually promises customers automated feedback on every pull request within 2 hours. To cut inference costs by 50%, an architect proposes routing all review jobs through the Message Batches API, noting that during testing most batches finished in under 1 hour. Why does this design fail the contractual requirement?
- A.Batch results are deleted 2 hours after completion, before the platform could reliably retrieve them
- B.The Batches API only guarantees that a batch finishes processing within 24 hours; sub-hour completion is a typical observation, not a contractual bound, so worst-case latency can violate the 2-hour SLA✓ Answer
- C.Batch jobs are always queued until midnight UTC, so pull requests opened during the day would wait until night to be processed
- D.The 50% batch discount only applies to organizations that submit batches less than once per hour
Batch processing is asynchronous with only one latency guarantee: a batch is processed within 24 hours of creation. 'Most batches complete in under 1 hour' is an empirical typical case, and an architecture must be sized to the guaranteed bound, not the typical case — so a hard 2-hour SLA requires the synchronous Messages API for those jobs. The distractors misstate the mechanics: there is no midnight scheduling, the 50% discount is unconditional on submission frequency, and results remain retrievable for 29 days after batch creation, not 2 hours.
Source: Anthropic Batch Processing documentation (docs.claude.com/en/docs/build-with-claude/batch-processing): 50% discount; most batches complete within 1 hour, guaranteed processing within 24 hours; results available for 29 daysReport a problem with this question
16. A review pipeline must analyze a 40-file pull request. When all 40 files are concatenated into a single request, the model misses defects that the identical prompt reliably catches when the same files are submitted one at a time. Which architecture best fixes the missed defects while still catching bugs that span multiple files?
- A.Submit the full 40-file concatenation twice and merge the two finding lists to compensate for whatever each run misses
- B.Run a per-file local review pass for depth, then a separate cross-file integration pass focused on interfaces and call sites between the changed files✓ Answer
- C.Sort the files so the riskiest ones appear last in the concatenated prompt, where the model's attention is strongest
- D.Increase max_tokens on the single concatenated request so the model has more room to report everything it finds
The symptom — defects caught per-file but missed in the concatenation — indicates attention dilution: as input grows, the model's per-file thoroughness degrades, which is an input-side problem that a larger output budget (max_tokens) cannot fix. Rerunning the same diluted prompt produces correlated misses, and prompt-position tricks do not restore uniform depth across 40 files. The two-pass design keeps each local call small and focused (restoring the per-file recall already demonstrated), and adds a dedicated integration pass over interfaces and call sites, which is the only option that also covers the cross-file defects a per-file-only design would miss.
Source: Anthropic prompt engineering guidance: long-context attention dilution and scoping each request to a focused task (docs.claude.com/en/docs/build-with-claude/prompt-engineering); CCAR-F Exam Guide Domain 4: multi-pass review architectureReport a problem with this question
Practice questions based on the official Claude Certified Architect – Foundations (CCAR-F) exam guide and Anthropic's public documentation. This is an independent study tool, not affiliated with or endorsed by Anthropic, and does not grant certification. The real exam is 60 questions, 120 minutes, passing at a scaled 720/1000, delivered via Pearson VUE ($125). Official certification page →