Store the credentials as SecureString parameters in AWS Systems Manager Parameter Store and grant the function role permission to retrieve them is the correct choice because it lets the Lambda function fetch encrypted username and password at runtime without embedding secrets in the deployment package.

Store the credentials as SecureString parameters in AWS Systems Manager Parameter Store and grant the function role permission to retrieve them stores values as SecureString which are encrypted with AWS KMS and protected by IAM policies. The Lambda function can retrieve the parameters at invocation using the SDK and the function execution role, so secrets are never hardcoded or packaged. This approach provides centralized access control and auditing and it is a purpose built pattern for runtime secret retrieval.

Put the credentials into AWS Key Management Service and reference them via Lambda environment variables is incorrect because AWS KMS is for managing encryption keys not for storing secret text, and using Lambda environment variables as the primary secret store risks exposing credentials in configuration and does not replace a managed secret store.

Save the credentials in an Amazon S3 object encrypted with SSE-KMS and read them at startup using the function execution role is not ideal because S3 is not a purpose built secret store and this pattern adds operational complexity and a larger attack surface even when objects are encrypted.

Enable IAM database authentication with the AWSAuthenticationPlugin and map an IAM user inside MySQL does not meet the requirement because IAM DB authentication issues temporary tokens instead of the static database username and password that the question requires.

Full AWS Practitioner Certification Question