A marsh-bird census API already knows a sighting’s item id and its species partition key and must load that one document as cheaply as possible. Which SDK operation should it use?
Select an answer to reveal the explanation.
Short Explanation
You already have the id and the partition key—that’s a point read, the express lane. Don’t drag a SELECT * fishing net across the whole marsh for one bird.
Full Explanation
When a marsh-bird census API already knows a sighting’s item id and its species partition key, the cheapest Cosmos SDK operation is a point read that supplies both values. Point reads retrieve a single item with predictable, typically lower request-unit cost than queries, which is the efficiency skill AZ-204 emphasizes when keys are known.
A cross-partition SELECT * with no filters scans broadly, consumes far more RUs, and returns far more data than one sighting. A full container export through the data migration tool on every request is an administrative bulk path, not an API read pattern. A change-feed processor that replays the entire container history per API call is for incremental processing pipelines, not low-latency single-document loads.
Exam caveat: point reads still fail if the partition key value is wrong even when the id is correct—id uniqueness is scoped per logical partition. Consistency level can affect read behavior/cost in nuanced ways, but preferring point read over fan-out query remains the primary optimization. Operational check: compare RU charge headers (or diagnostics) for a point read versus an equivalent query filter on the same item; keep the point-read path in the API when both keys are available.