What should a solutions architect recommend to meet these requirements in the MOST secure manner?
Store the password in AWS CloudHSM. Associate the Lambda function with a role that can use the key ID to retrieve the password from CloudHSM. Use CloudHSM to automatically rotate the password.
Store the password in AWS Secrets Manager. Associate the Lambda function with a role that can use the secret ID to retrieve the password from Secrets Manager. Use Secrets Manager to automatically rotate the password.
Store the password in AWS Key Management Service (AWS KMS). Associate the Lambda function with a role that can use the key ID to retrieve the password from AWS KMS. Use AWS KMS to automatically rotate the uploaded password.
Move the database password to an environment variable that is associated with the Lambda function. Retrieve the password from the environment variable by invoking the function. Create a deployment script to automatically rotate the password.
Explanations:
AWS CloudHSM is designed for cryptographic key storage and management. It does not provide an automatic password rotation feature for sensitive information like database credentials. This makes it less suitable for the given scenario.
AWS Secrets Manager is designed to securely store and manage sensitive information such as database credentials. It supports automatic rotation of secrets, meeting the security policy requirements for storing and rotating credentials.
AWS Key Management Service (KMS) is used for managing encryption keys, not for securely storing and rotating sensitive information like passwords. KMS does not have the capability to automatically rotate stored secrets such as database credentials.
Storing passwords in environment variables is not a secure practice, as environment variables are accessible in logs and can be exposed in certain circumstances. Additionally, manual rotation of the password using a deployment script is less secure and lacks automation compared to Secrets Manager.