A snowpack-sensor uploader constructs one Azure Blob SDK object and expects that same object to list every container in the account and also upload a file into one container. Which v12 client choice matches those two scopes?
Select an answer to reveal the explanation.
Short Explanation
Picture three nested keys: the account keyring, the locker key, and the file key. BlobServiceClient owns the account (list containers). BlobContainerClient owns one container. BlobClient owns one blob for upload. One flat object cannot honestly do every scope.
Full Explanation
In the Azure Storage Blob SDK v12 object model, scope is layered: BlobServiceClient represents the storage account, BlobContainerClient represents one container, and BlobClient represents one blob. The snowpack-sensor uploader needs one construction path that can list every container in the account and also upload into a specific container. BlobServiceClient is the client that enumerates containers. From that service client you obtain a BlobContainerClient for the target container, then a BlobClient (or upload helpers on the container client) to write the file. That nested construction matches both required scopes with the modern SDK.
Using only CloudBlobClient from the legacy v11 SDK fails the requirement conceptually for an AZ-204 style answer that targets the current client hierarchy. Legacy types may still appear in older samples, but they are not the v12 choice that cleanly separates account listing from blob upload, and exams expect the v12 pattern.
BlobClient alone fails because a blob client is scoped to a single blob path. It cannot perform account-wide container listing; asking it to both enumerate containers and upload misstates the client boundaries.
QueueClient fails because it belongs to Queue Storage. Listing containers is a Blob service operation. Even chaining a BlobContainerClient afterward does not make QueueClient the correct starting point for container enumeration.
Exam caveat: listing containers requires account-level data-plane permission (for example a role or SAS that includes container list), which is broader than a single-blob SAS—least privilege still applies. Operational check: construct BlobServiceClient with the intended credential, call GetBlobContainers (or equivalent), then derive a container client and upload a small test blob to prove both scopes work with the same credential chain.