DVA-C02 Development with AWS Services 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.

• ✗

  Store the AWS access key and secret key in the Lambda environment variables.

  Why it's wrong here

  Storing static AWS access keys and secret keys directly in Lambda environment variables is a significant security risk. These credentials are not automatically rotated and are visible in plain text to anyone with console access or sufficient IAM permissions to view the Lambda function's configuration. This practice violates the principle of least privilege and exposes long-lived credentials, making the application vulnerable to compromise if the Lambda function or its configuration is ever accessed maliciously.

• ✓

  Create an IAM role with DynamoDB permissions and attach it to the Lambda function.

  Why this is correct

  Creating an IAM role with specific DynamoDB permissions and attaching it to the Lambda function is the AWS-recommended and most secure approach. When the Lambda function executes, it automatically assumes this IAM role, which provides temporary, short-lived credentials to interact with DynamoDB. This method adheres to the principle of least privilege by granting only necessary permissions and eliminates the need to manage static credentials within the function code or configuration, significantly enhancing security.

• ✗

  Create an IAM user with programmatic access and store the credentials in the Lambda code.

  Why it's wrong here

  Creating an IAM user with programmatic access and embedding its static credentials directly within the Lambda function's code is a severe security anti-pattern. Hardcoding credentials makes them difficult to rotate, prone to accidental exposure through version control systems, and provides long-lived access that could be exploited indefinitely if compromised. This approach completely bypasses AWS's secure identity and access management mechanisms designed for compute services.

• ✗

  Use the Lambda function's default full admin access provided by AWS.

  Why it's wrong here

  AWS Lambda functions do not inherently possess any default full administrative access; they operate with an execution role that must be explicitly defined and assigned. Without an attached IAM role, a Lambda function would lack the necessary permissions to interact with other AWS services like DynamoDB, resulting in authorization failures. This option is fundamentally incorrect as it misrepresents how permissions are managed for serverless compute.

Go deeper

Related to this question