A cobble-street market stall app should ensure container stall-photos exists on first boot without failing when the container is already present. Which Blob SDK approach should the developer take?

Idempotent container provisioning on startup is exactly what CreateIfNotExists (or the REST equivalent that creates only when missing) provides on BlobContainerClient. The cobble-street market stall app must ensure stall-photos exists without treating “already present” as a failure. CreateIfNotExists creates the container when the first boot races ahead of provisioning, and returns success without error when another instance or a prior boot already created it. That is the safe pattern for first-boot ensure-exists semantics.

Always deleting then creating on every boot fails because it is destructive and racy: concurrent boots or in-flight uploads can lose data, and delete-plus-create is not an ensure operation. It also incurs unnecessary failures and permission requirements for delete.

Uploading blobs while relying on implicit container creation fails because the Blob service does not auto-create containers on upload the way some file systems create parent folders. A missing container yields an error; uploads assume the container already exists.

Creating a Cosmos DB container named stall-photos fails because Cosmos containers are not Blob containers. Sharing a name does not provision Blob Storage capacity or paths for stall photos.

Exam caveat: CreateIfNotExists still requires permission to create containers; a credential that can only write blobs inside an existing container cannot fix a missing container at runtime. Operational check: on a clean account, call CreateIfNotExists twice in a row for stall-photos and confirm both calls succeed, then upload a probe blob to prove the container is usable.