A juniper-smoke house tool needs blob and queue data-plane operations authorized with a single shared access signature. Which SAS type fits?
Select an answer to reveal the explanation.
Short Explanation
Need blob and queue in one token? Account SAS can span services. Remember messaging design for queues still lives in Domain 5—this item is about the signature type.
Full Explanation
Account SAS signed with the account key is the SAS type that can authorize multiple services—such as blob and queue data-plane operations—in one signature. The juniper-smoke house tool that needs both services in a single SAS should use account SAS with signedservices covering blob and queue, then still apply least-privilege permissions and expiry.
A service SAS that can only target Blob Storage fails the multi-service requirement. Service SAS is scoped to one service’s resources and cannot simultaneously authorize Queue Storage operations in that same service-SAS model.
A user-delegation SAS that never includes Queue Storage fails because user-delegation SAS is for Blob Storage (blob/container/directory) scenarios tied to Entra delegation keys, not a multi-service blob+queue account signature.
A Cosmos DB resource token presented as a blob SAS fails because Cosmos tokens do not authorize Azure Storage queues or blobs. Different data services use different authorization artifacts.
Exam caveat: needing blob and queue in one SAS is often a design smell; prefer separate least-privilege credentials or Entra/RBAC where possible. For the exam item, recognize account SAS as the multi-service SAS type while remembering queue messaging patterns themselves belong to messaging domains.
Operational check: mint an account SAS with signedservices=bq (or the needed combination), verify a blob read and a queue receive/send succeed as intended, then confirm a service SAS minted for blob alone cannot perform the queue operation.