What you’ll be able to do
- Turn a business requirement into a named API capability
- Spot the one phrase in a requirement that decides the mechanism
- Separate genuine constraints from stated preferences
- Recognise requirements that rule out an approach entirely
What you need to know
The exam speaks in business sentences
Almost nothing in this domain is phrased technically. You get a line from a product spec or a stakeholder, and you're expected to name the mechanism it implies. The skill is translation, and it's tested constantly because it's what the job actually is.
Train yourself to read for the one phrase that decides it. Most requirements contain exactly one, and everything else is colour.
The translation table worth memorising
- "Users should see the answer appear as it's written" → streaming. The deciding phrase is about perception, not throughput.
- "Process last night's uploads before the 9am report" → Batch API. A deadline in hours with nobody watching.
- "Patients photograph their insurance cards" → vision.
- "Claim data must never leave our network" → client-side tools, executed in your own infrastructure.
- "The same 8,000-word policy prefixes every request" → prompt caching.
- "Get the ambiguous cases right, even if it costs more" → extended thinking, and likely a higher tier.
- "We need to know exactly which version produced this output" → model version pinning.
Constraints versus preferences
Not every requirement is binding, and the exam mixes them deliberately. A constraint eliminates options; a preference ranks them.
"Data cannot leave our network" is a constraint — it removes every server-side option regardless of cost or convenience. "We'd like to keep costs down" is a preference — it ranks the remaining options but eliminates none.
When a scenario contains one hard constraint and three soft preferences, the constraint decides the answer on its own. Candidates lose points by optimizing against the preferences and quietly violating the constraint.
Requirements that rule things out
Read the order of operations. The PHI constraint eliminates any approach that ships data out, so that's settled before you consider anything else. Only then does "12,000 results, done by 7am, nobody waiting" point at batch-style processing, and "as cheap as possible" point at the smallest tier that holds accuracy. Answering the cost question first and the PHI question last is how people get this wrong.
When the requirement is silent
Sometimes the deciding fact is absent, and the correct answer is to establish it rather than assume. "Summarize support tickets" doesn't say whether anyone is waiting — and that one missing fact is the difference between real-time and batch, which is most of the cost difference.
On the exam this appears as an option like "clarify whether the workload is latency-sensitive before choosing." It's right more often than candidates expect, because the other three options all commit to an architecture the scenario never justified.
Key concept
Requirements arrive as business sentences. Find the single deciding phrase, separate hard constraints from soft preferences, and let the constraint settle the architecture before cost or convenience gets a vote.
Practice scenario
Work it through, then open this
Four statements, but only one is a constraint. Data residency eliminates every server-side option, so it settles the architecture first. “Handle scanned forms” names a capability (vision). Fast and cheap only rank what’s left. Optimising for cost and discovering later that you breached residency is the failure this ordering prevents.
Build exercise — Catch a real caching or batching bug
25 min
-
Take a request you send repeatedly with a long stable prefix. Check whether the cache checkpoint sits after the stable content, or whether something volatile (a timestamp, a user id) is sitting in front of it.
- Why: This is the single most common caching mistake, and it fails silently.
- You should see: Either a checkpoint already placed correctly, or a volatile field breaking it on every call.
-
Send that same request twice and check the cache-read token count on the second response.
- Why: Never assume caching engaged just because you set the flag.
- You should see: A nonzero cache-read count on call two — if it’s zero, the checkpoint placement is still wrong.
-
Find one workload you currently run synchronously that nobody is actually waiting on in real time.
- Why: The real-time-vs-batch call is the most repeated pattern on the whole exam.
- You should see: A concrete job — a nightly reconciliation, a bulk export — that has no business being synchronous.
Exam traps
Optimizing for a stated preference while breaking a hard constraint
A cost preference never outranks a data-residency or compliance constraint. Constraints eliminate; preferences only rank.
Assuming latency tolerance when the requirement never states it
It is the deciding fact between real-time and batch. When it is absent, establishing it is usually the correct answer.
Reading “faster” as a throughput problem when it means perceived latency
Streaming fixes how fast it feels. Nothing about total generation time changes.
Treating every mention of documents as a vision requirement
Text extracted upstream is just text. Vision is for when the model itself must read an image or scan.