DVA-C02 Security 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.

• ✗

  Create a VPC endpoint for DynamoDB and attach a security group to allow access.

  Why it's wrong here

  Creating a VPC endpoint for DynamoDB provides private network connectivity from your VPC to DynamoDB, bypassing the public internet. While a security group attached to the EC2 instance and the endpoint policy would control network reachability, VPC endpoints do not, by themselves, grant API-level permissions. An EC2 instance still requires explicit IAM authorization to perform actions on DynamoDB tables, making this option insufficient for granting access.

• ✗

  Store IAM user access keys in the application configuration file.

  Why it's wrong here

  Storing static IAM user access keys (Access Key ID and Secret Access Key) directly in application configuration files is a severe security anti-pattern. These credentials are long-lived and, if compromised through source code repositories, misconfigured storage, or instance compromise, grant persistent access to the associated IAM user's permissions. This approach violates the principle of least privilege and significantly increases the attack surface, making it highly insecure.

• ✓

  Create an IAM role with DynamoDB access and attach it to the EC2 instance profile.

  Why this is correct

  Attaching an IAM role with DynamoDB access to an EC2 instance profile is the AWS best practice for granting permissions to applications running on EC2 instances. This mechanism allows the EC2 instance to obtain temporary, frequently rotated credentials from the instance metadata service (IMDS). The application can then use these temporary credentials to make authorized API calls to AWS services like DynamoDB, eliminating the need to store static, long-lived credentials on the instance and enhancing security.

• ✗

  Use a security group to allow the EC2 instance to communicate with DynamoDB.

  Why it's wrong here

  Security groups operate at the network layer, functioning as virtual firewalls to control inbound and outbound traffic to and from an EC2 instance. While a security group is necessary to permit outbound network connectivity to DynamoDB's service endpoints, it does not provide the necessary API-level authorization. An EC2 instance still requires explicit IAM permissions to perform actions like `dynamodb:PutItem` or `dynamodb:GetItem` on DynamoDB tables, regardless of network reachability.