Trusted Advisor shows that an insurance company's root user still has an access key, and that key is not part of any approved workload. What should the team do?
Select an answer to reveal the explanation.
Short Explanation
The master key to the building does not get safer because you cut a fresh copy of it. You still have a root access key, and Trusted Advisor is right to flag it, so delete the key rather than rotate it and keep working as root. Daily work belongs on IAM roles.
Full Explanation
The root user is the account owner, and an access key for that user is a long-lived credential outside the IAM roles you can scope. The response to a root access key is to delete it, not to keep a root principal in the request path. IAM roles hand a workload temporary credentials, which replaces a long-lived root key rather than parking a second root secret in a vault. Rotation issues a new root key and leaves the same risk for whatever automation still signs as root. Suppressing the Trusted Advisor finding hides the row and does not remove the key from the account. A permissions policy or a source-network condition wrapped around that key still means the root user is in daily use, which is the condition the check is warning about. Caveat: find any remaining process that signs with the root key before you delete it, or those calls fail as soon as the key is gone. Operational check: after deletion, confirm the root credential page shows no access key, and confirm workloads assume IAM roles instead.