Auditors ask the grants team to confirm that the production Secrets Manager secret store protecting database credentials uses encryption at rest with an appropriate customer managed key policy. What should they verify?
Select an answer to reveal the explanation.
Short Explanation
Auditors want to see the vault's lock brand and who holds spare keys — Secrets Manager at rest under a CMK with a tight key policy, not plaintext mappings or Git souvenirs.
Full Explanation
Auditors validating production Secrets Manager protection for database credentials should verify that Secrets Manager encrypts the secret at rest with a customer managed key whose key policy allows only intended principals. CMK policy review shows who can decrypt secret material and administer the key, which is the control the grants team is being asked to demonstrate. Municipal audit narratives typically pair "encrypted at rest" with "who holds the keys."
Storing secrets as plaintext CloudFormation Mappings fails because mappings in templates are not Secrets Manager encryption and often land in version control. Replicating the secret into Git tags so CMK policy review is unnecessary fails conceptually—Git copies bypass the secret store and its CMK. Disabling encryption at rest so developers can cat values from local SAM caches fails because it removes the control under audit.
Exam caveat: default AWS managed keys may encrypt secrets, but the scenario asks for an appropriate CMK policy—confirm a customer managed key is actually configured when that is the requirement. Operational check: open the secret's encryption setting, review the CMK key policy and grants, and confirm only application roles and designated admins appear as decrypt principals.