It covers six sub-objectives, and they are less related to each other than the domain name suggests:
- Understanding Requirements — separating functional from non-functional, and deriving infrastructure needs from business constraints.
- Systems Life Cycle — knowing which phase a piece of work belongs to.
- Claude API Mechanics — SDK versus REST, synchronous versus streaming, batch processing, multimodal input.
- Software Engineering Foundations — testing levels, tracing, and changing code safely.
- Claude Application Design — component boundaries, trust boundaries, deployment targets.
- Configuration Management — versioning, pinning, and what belongs in configuration rather than code.
Requirements questions are classification questions
The exam repeatedly hands you a stated need and asks what kind of requirement it is, or what follows from it. The distinction that carries the most weight is functional versus non-functional, and the trap is attributing the category to whoever said it rather than to what it constrains.
From the free practice form
A product owner specifies that a new assistant must respond within 2 seconds and support 500 concurrent users. How should a developer classify these requirements?
Infrastructure follows the binding constraint
A harder version of the same shape gives you a scenario with several plausible technical needs and asks which one follows from the business requirement. The discipline is to find the constraint that actually binds, usually a deadline over a known volume, and ignore the options that assume a different usage pattern entirely.
From the free practice form
Larkspur Logistics wants Claude to summarize roughly 40,000 shipping-exception reports that accumulate overnight, with every summary visible in an internal dashboard by 6 a.m. No employee interacts with the system while it runs, and the solution architecture specifies a scheduled pipeline. Which infrastructure requirement follows most directly from these business requirements?
API mechanics: streaming is the reliable question
Of the API material, streaming produces the most questions, because it is where a working mental model and a vague one diverge. A streamed response is the sum of its deltas. The client accumulates incremental content events in order and stops when the stream signals completion. There is no fetch-by-id replay of a finished generation, and no flag that appends a full body at the end. If your code needs the whole message, your code assembles it.
Batch processing is the other reliable source. The trigger phrase is work that is high volume and not needed immediately, which is precisely the condition batch exists for and precisely the condition where reaching for real-time infrastructure is the wrong call.
Changing code you do not understand
Software Engineering Foundations shows up as questions about safety when modifying unfamiliar code. The credited order is always the same: pin down current behavior first, then change it. Characterization tests come before refactoring, not after, because a refactor without tests can silently alter behavior nobody is positioned to notice. Rewriting from scratch ranks worst, since it bets that a fresh implementation reproduces years of undocumented edge cases.
Where to spend your time
Within this domain, the sub-objectives are not equally hard. Requirements classification and life cycle placement are learnable in an afternoon. API mechanics rewards actually reading the Messages API reference rather than recalling a summary of it. Trust boundaries and configuration management are where careful candidates separate from confident ones, because both reward naming the seam that nobody marked.