An ivy-walled archive function still uses the storage account key and must grant access to one blob container only. Which SAS should the developer mint?
Select an answer to reveal the explanation.
Short Explanation
One container, one service, still signing with the account key? That’s a service SAS—not an account SAS that can wander across queues and tables.
Full Explanation
When the ivy-walled archive function still uses the storage account key and must grant access to one blob container only, mint a service SAS for Blob Storage scoped to that container. Service SAS is signed with the account key (or a stored access policy backed by it) and targets a specific service resource—here, a container—without enabling table, queue, and file in the same signature.
An account SAS that also enables table, queue, and file services fails least privilege. Account SAS can span services; enabling extras expands blast radius beyond the single container requirement.
A user-delegation SAS without any Entra authentication available fails because user-delegation SAS requires Entra credentials to obtain the delegation key. If Entra auth is unavailable in this function path, you cannot honestly choose user-delegation.
A multi-service account SAS with write on every endpoint fails for the same overbreadth reasons: convenience signing across every endpoint violates container-only scope and invents write where read or limited write may be enough.
Exam caveat: service SAS can still be overly broad inside Blob Storage if you sign at the account or service level with wide permissions. Prefer container- or blob-scoped signatures and short expiry even when staying on service SAS.
Operational check: generate the service SAS with signed resource constrained to the container, signed services limited to blob, minimal permissions, and a near-term expiry; attempt access to another container and to Queue Storage with the same URI and confirm failure.