A grouse-moor booking tool needs time-boxed browser access to a blob. Which set names the official Azure Storage shared access signature types the developer should choose among?

Azure Storage documents three official shared access signature types for time-boxed data-plane access: user-delegation SAS, service SAS, and account SAS. The grouse-moor booking tool should choose among that trio based on whether Entra signs the SAS (user-delegation), whether a service-level key signature scoped to one service is enough (service SAS), or whether multi-service account-key signing is required (account SAS).

“Only account SAS and App Service authentication keys” fails because it omits user-delegation and service SAS, and App Service authentication keys are not Storage SAS types. Mixing platform auth secrets into the SAS taxonomy is incorrect.

“Managed identity tokens and Logic App SAS only” fails because managed identity tokens are Entra access tokens for Azure AD–protected resources, not Storage SAS varieties, and “Logic App SAS” is not one of the three official Storage SAS types for general blob browser access design.

“Cosmos DB resource tokens renamed as blob SAS” fails because Cosmos resource tokens authorize Cosmos DB resources. Renaming does not create a blob SAS or grant Blob Storage access.

Exam caveat: user-delegation SAS requires Entra authentication and the Storage Blob Delegator capability (via RBAC), while service and account SAS rely on key material. Knowing which type you can mint from a given host identity matters as much as memorizing the three names.

Operational check: when designing the booking upload/download link, explicitly pick one of the three types, document signing identity (Entra vs account key), and verify the generated URI includes the expected signature fields (for example signedversion, signedresource/signedservices, and expiry).