A lock-scheduling daemon authenticates as a service principal yet still stores a storage account key on disk. What should the security engineer do?
Select an answer to reveal the explanation.
Short Explanation
A key on disk is a spare house key taped to the door. Give the service principal the right Azure RBAC role on the storage scope and throw the account key away.
Full Explanation
Service principals are first-class Azure RBAC security principals. Assigning a built-in Azure data-plane or control-plane role to the service principal at the appropriate scope allows the lock-scheduling daemon to access Storage (or other resources) using Microsoft Entra tokens instead of a storage account key left on disk. That is the preferred municipal pattern: identity plus RBAC, not shared keys in files.
Leaving the key on disk and adding a longer client secret on the same service principal fails as “defense in depth”—it increases secret sprawl without removing the key risk. Moving the storage account key into an unsigned text file beside the daemon binary fails hygiene and still leaves a recoverable secret for anyone with filesystem access. Replacing the service principal with a shared mailbox password so Azure RBAC is unnecessary fails by concept and destroys individual workload identity accountability.
Exam caveat: once Entra-based access works, consider disabling shared key access on the storage account so old keys cannot be reused. Operational check: assign the least-privilege role to the service principal, update the daemon to acquire Entra tokens, remove the key from disk, validate schedule sync against storage, and optionally disable shared key authorization after monitoring.