A municipal utility team wants every build of its meter-reading API to run the same way on a laptop, in a registry, and later on a managed cluster. Which packaging choice best expresses that cloud-native unit of delivery?

The cloud-native unit of delivery for the meter-reading API is a portable, isolated container image that packages the process with its dependencies. That single artifact is what moves unchanged from a developer laptop through a registry onto a managed cluster, so runtime libraries and OS-level assumptions travel with the workload instead of being recreated by hand in every environment. Isolation keeps one service’s libraries from colliding with another’s on the same node, which is essential once many municipal services share cluster capacity.

Installing the runtime and libraries directly on each host and documenting steps in a wiki recreates snowflake machines and environment drift—the “same build” no longer means the same executable environment. Shipping a shared middleware appliance that hosts several unrelated city applications couples unrelated release trains and failure domains into one image. Committing compiled binaries into Git and copying them with SCP at release time bypasses a standard registry-backed artifact flow and leaves provenance, promotion, and rollback as ad-hoc file copies.

Exam caveat: the exam emphasizes the container (or equivalent process image) as the shippable unit; it is not asking you to memorize a particular registry product SKU or cluster control-plane brand.

Operational check: build once, push the image digest to the registry, pull that same digest in test and production, and verify the process starts without host-local wiki install steps or SCP of loose binaries.