A partner needs time-boxed read access to one lock-photo container, and the team was about to sign an account SAS with the storage account key. What should the security engineer mint instead?
Select an answer to reveal the explanation.
Short Explanation
Don’t ink the partner pass with the master account key. Mint a user-delegation SAS—Entra signs it, you scope the container and the clock, and the account key stays home.
Full Explanation
A partner that needs time-boxed read access to one lock-photo container should receive a user-delegation SAS signed with Microsoft Entra ID credentials, scoped to the needed container permissions and lifetime—not an account SAS signed with the storage account key. User-delegation SAS avoids distributing account-key material, aligns with identity-based control, and still supports narrow scope and expiry for the partner window. The municipal account key stays home while the partner gets a time-boxed pass to one photo drawer.
Issuing an account SAS signed with the account key and valid for all services for one year fails by concept: account-wide scope, multi-service reach, and long lifetime maximize abuse if the URI leaks, and signing with the account key inherits key-compromise risk. Embedding the storage account key in the partner’s desktop client with no expiry fails by handing over standing full data-plane power. Issuing a service SAS that also includes write and delete on every container fails least privilege for a read-only, single-container partner need.
Exam caveat: prefer user-delegation SAS over account-key-signed account or service SAS when Entra can sign; always match container, permissions, and lifetime to the partner window. Operational check: ensure the signing identity has the required data-plane role, mint a user-delegation SAS limited to the lock-photo container with read-only permissions and a short lifetime, deliver it out of band, verify access expires as configured, and never email the raw account key.