DOP-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use AWS KMS to encrypt the credentials and pass them as parameters.

  Why it's wrong here

  AWS KMS is a key management service used to create and control encryption keys, not a secret store itself. Encrypting credentials with KMS and passing them as parameters still requires the plaintext secret to be placed somewhere accessible to the caller or the function code, and KMS alone provides no built-in secret rotation or cross-account sharing policies. Moreover, granting the Lambda role permission to decrypt the KMS key gives broad encryption/decryption authority, whereas a dedicated secret management service offers fine-grained, resource-level IAM policies and automated rotation.

• ✓

  Attach an IAM role to the Lambda function with permissions to read the secret and retrieve it at runtime.

  Why this is correct

  Attaching an IAM role to the Lambda function and granting it permissions to read the secret from AWS Secrets Manager (or Systems Manager Parameter Store) at runtime ensures that the plaintext credential never exists in the code, deployment package, or configuration. The Lambda service uses the execution role to obtain temporary credentials, and the secret is retrieved over a secure AWS API call, enabling least-privilege access, automatic rotation, and CloudTrail auditing. This is the AWS recommended pattern because the secret remains under the management of a purpose-built service, and the function only receives it during the invocation.

• ✗

  Store the credentials directly in the Lambda function's environment variables.

  Why it's wrong here

  Storing credentials directly in Lambda environment variables places the plaintext secret in the function's configuration, which is accessible to any IAM principal with lambda:GetFunction or GetFunctionConfiguration permissions. The value is also displayed in the AWS Management Console and returned by APIs like aws lambda get-function, and it persists in deployment artifacts, CloudFormation templates, and CI/CD logs—all common sources of accidental exposure. Environment variables have no independent access controls, so any user who can read the function definition can extract the secret, regardless of the function's invocation permissions.

• ✗

  Use Lambda environment variables with encryption enabled.

  Why it's wrong here

  Enabling encryption on Lambda environment variables does encrypt the values at rest with a KMS key, but Lambda automatically decrypts them at invocation time, so the plaintext is exposed inside the runtime environment and can appear in logs, stack traces, or function output. Furthermore, the configuration remains readable by anyone with GetFunctionConfiguration permissions, because the Lambda service decrypts the variable for display in the console and CLI. This approach also does not provide secret rotation, versioning, or per-secret authorization, and it forces you to manage additional KMS keys—all while the secret is still coupled to the function definition.

Go deeper

Related to this question