Which solution will meet these requirements with the LEAST operational overhead?
Create an RDS database secret in AWS Secrets Manager. Set the user name, password, database, host, and port. Turn on secret rotation. Create encrypted Lambda environment variables for the DynamoDB table, S3 bucket, and SNS topic.
Create an RDS database secret in AWS Secrets Manager. Set the user name, password, database, host, and port. Turn on secret rotation. Create SecureString parameters in AWS Systems Manager Parameter Store for the DynamoDB table, S3 bucket, and SNS topic.
Create RDS database parameters in AWS Systems Manager Parameter Store for the user name, password, database, host, and port. Create encrypted Lambda environment variables for the DynamoDB table, S3 bucket, and SNS topic. Create a Lambda function and set the logic for the credentials rotation task. Schedule the credentials rotation task in Amazon EventBridge.
Create RDS database parameters in AWS Systems Manager Parameter Store for the user name, password, database, host, and port. Store the DynamoDB table, S3 bucket, and SNS topic in Amazon S3. Create a Lambda function and set the logic for the credentials rotation. Invoke the Lambda function on a schedule.
Explanations:
While AWS Secrets Manager is suitable for securely storing and rotating RDS credentials, using encrypted Lambda environment variables for other services like DynamoDB, S3, and SNS does not provide centralized management or easy updates. This option does not utilize a solution for securely storing and managing the parameters for the non-RDS resources effectively.
This option correctly uses AWS Secrets Manager to store the RDS database credentials, allowing for rotation and secure access. It also utilizes AWS Systems Manager Parameter Store with SecureString parameters for storing the DynamoDB, S3, and SNS configurations. This approach centralizes configuration management, supports encryption, and simplifies updates without code changes, meeting all the developer’s requirements with minimal overhead.
This option incorrectly proposes using AWS Systems Manager Parameter Store to store RDS credentials without leveraging Secrets Manager’s built-in rotation capabilities. Additionally, implementing custom logic for credential rotation in a Lambda function introduces unnecessary complexity and operational overhead compared to using AWS Secrets Manager directly.
Similar to option C, this option incorrectly uses AWS Systems Manager Parameter Store for RDS credentials without rotation features. It also suggests storing DynamoDB, S3, and SNS values in S3, which is not secure or suitable for managing configurations. The custom rotation logic would add complexity and overhead, deviating from the requirement for minimal operational overhead.
I believe the answer is:
Create an RDS database secret in AWS Secrets Manager. Set the user name, password, database, host, and port. Turn on secret rotation. Create SecureString parameters in AWS Systems Manager Parameter Store for the DynamoDB table, S3 bucket, and SNS topic.