Estate policy requires every RSA key in Key Vault to be scheduled to rotate within 730 days. Which governance approach should the security engineer use?
Select an answer to reveal the explanation.
Short Explanation
Want every RSA key on a 730-day rotation diet? Assign the built-in Policy that audits keys missing a timely rotation policy—it flags gaps; it doesn’t quietly rotate them for you.
Full Explanation
Estate policy that every RSA key must be scheduled to rotate within 730 days is enforced through Azure Policy governance. Built-in definitions audit Key Vault keys that lack an appropriate rotation policy within the required interval. With a typical Audit effect, Policy surfaces non-compliant keys for remediation; it does not silently rotate existing keys. Assign that built-in policy across the lock-authority subscriptions and remediate flagged keys by attaching rotation policies.
Relying on operators to remember which keys lack rotation policies without Policy assignments fails scalable governance. Enabling Microsoft Sentinel UEBA only fails by concept: UEBA detects anomalous behavior; it does not replace configuration compliance for rotation policies. Deleting every RSA key older than 30 days regardless of application dependencies fails availability and is not rotation—it is destructive key removal.
Exam caveat: Audit versus DeployIfNotExists/Modify—know that the common rotation-policy built-in is an audit/visibility control, not automatic key rewrite. Operational check: assign the built-in policy at management group or subscription, review compliance for RSA keys missing rotation within 730 days, attach rotation policies to Non-compliant keys, and re-evaluate until the canal estate reports Compliant.