A municipal soil-lab webhook Function accepts a soil-sample JSON body and must persist one Cosmos DB document per call. The team wants to avoid constructing a Cosmos SDK client inside the function. What should they add?

A municipal soil-lab webhook Function that must persist one Cosmos DB document per HTTP call can do so with a Cosmos DB output binding. The runtime takes the document returned from the function or assigned to an output parameter and writes it to the configured database and container. That pattern avoids constructing and managing a CosmosClient solely for a straightforward insert, which matches the AZ-204 goal of using bindings when they fit the write path.

A Cosmos DB input binding that only reads existing documents for validation fails the write requirement: input direction retrieves data into the function; it does not insert the new soil-sample document. A timer that batch-imports CSV files from a local disk share each night replaces the webhook’s per-call persistence model with an unrelated batch schedule and storage location the webhook never uses. An Azure Cache for Redis binding stores cache entries, not durable Cosmos documents, so it cannot satisfy “persist one Cosmos DB document per call” even if Redis appears convenient for transient state.

Exam caveat: output bindings still need valid connection and database/container settings; misconfigured connection strings produce runtime binding failures that look like application bugs. Also note that complex multi-document transactions or advanced SDK-only APIs may still require an explicit client—bindings cover the common write path, not every Cosmos feature. Operational check: invoke the webhook with a unique sample id, then verify in Data Explorer or via a point read that exactly one document with that id exists in the target container after a successful 2xx response.