A company is testing its incident response plan for compromised credentials. A database runs on an Amazon EC2 instance, and the sensitive database credentials are stored as a secret in AWS Secrets Manager with rotation enabled via an AWS Lambda function based on the generic rotation template. The EC2 instance and the Lambda function are in the same private subnet. The VPC has a Secrets Manager VPC endpoint. Rotation is failing, and CloudWatch Logs shows: “setSecret: Unable to log into database.” The VPC endpoint is functioning as expected. Which solution resolves the error?

The Lambda function, acting as the Secrets Manager rotator, needs network connectivity to the database running on the EC2 instance to perform credential updates. The error "Unable to log into database" indicates a network or authentication issue when the Lambda function tries to connect to the database. Since the EC2 instance and Lambda function are in the same private subnet, security groups are the primary mechanism controlling internal VPC traffic. The Lambda function's security group must permit outbound connections to the EC2 instance, and the EC2 instance's security group must permit inbound connections from the Lambda function's security group. Editing the JSON structure of the secret is incorrect because the issue is connectivity, not the secret's format. Using list-secrets and rotate-secret via the CLI would not resolve the underlying connectivity problem preventing the Lambda function from logging into the database. Adding an internet gateway and NAT gateway is unnecessary and incorrect because the problem states the VPC endpoint is functioning and the resources are in a private subnet; the rotation should occur within the VPC without needing public internet access.