A compost-lab service principal still has a password credential created three years ago, and nobody can determine who generated it. What should the security engineer do?
Select an answer to reveal the explanation.
Short Explanation
A three-year-old password that nobody owns is a rusty spare key. Cut it off the principal, hang a certificate—or better, a managed identity—and write up the unrotated secret as a finding.
Full Explanation
Service-principal credential hygiene includes removing unknown or long-lived password credentials and preferring certificate credentials or managed identities. For a compost-lab service principal that still has a password credential created three years ago with no attributable owner, the security engineer should remove the aged password credential, add a certificate credential or move the workload to a managed identity, and treat the unrotated secret as a security finding until its history is understood.
Leaving the password in place because service-principal secrets “never expire once created” is false and leaves a standing compromise risk. Documenting the unknown password as accepted risk while rotating only Key Vault encryption keys fails to remediate the service-principal secret itself. Pasting the existing password into source control with a calendar reminder for the next three-year renewal spreads the secret and institutionalizes bad practice.
Exam caveat: unknown aged application passwords should be handled like potentially compromised credentials—rotate/replace, then remove. Operational check: inventory credentials on the service principal, deploy certificate or managed-identity authentication, remove the three-year-old password after cutover, verify the compost workload authenticates, and configure alerts for credentials older than policy.