Cascade's crew-records team stores scanned licensing and medical documents in a container named crew-doc-scans, separate from the flight-ops-logs container in the same storage account. A payroll auditor needs temporary read access to crew-doc-scans only, and must never be able to touch flight-ops-logs. Which SAS type satisfies this?
Select an answer to reveal the explanation.
Short Explanation
A service SAS is like a key cut for one specific door in the building, not a master key for the whole floor. It's scoped to a single container (or even one blob), so the auditor can open crew-doc-scans and nothing else. That's exactly the narrow access this job calls for.
Full Explanation
A service SAS is generated against one specific resource within one service — here, the crew-doc-scans container — and its permissions apply only to that scope, satisfying the requirement to keep flight-ops-logs untouched. An account SAS operates at the account level and can span multiple services and every container inside them, so even with read-only permissions it would still expose flight-ops-logs, violating the isolation requirement. Targeting the queue service is a mismatch of layers entirely — queues hold messages, not the document blobs the auditor needs, so no SAS against that service grants access to crew-doc-scans. The account key has no concept of 'read-only by convention'; it is a symmetric secret that grants full permissions across the whole account regardless of intent, and there's no way to restrict it to one container. As a caveat, a service SAS still needs an expiry and either the account key or a stored access policy to sign it, so pair it with a short validity window. To confirm the boundary holds, try the SAS against flight-ops-logs and verify the request is rejected.