AWS DVA-C02 Drill: DynamoDB IAM Policies - Troubleshooting Access Denied

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.

For DVA-C02 candidates, the confusion often lies in proper IAM role trust relationships versus policy permissions. In production, this is about knowing exactly how IAM roles attached to EC2 instances must be configured to allow API calls to DynamoDB without Access Denied errors. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

Onyx Innovations is building an internal vehicle inventory application deployed on an Amazon EC2 instance in the us-east-1 region. The application requires read-only access to the DynamoDB table named VehicleInventory. The EC2 instance is assigned an IAM role that contains a policy granting it permissions for the following DynamoDB actions: GetItem, BatchGetItem, Scan, Query, and ConditionCheckItem on the VehicleInventory table.

Despite this setup, the application receives an Access Denied error when attempting to read data from the DynamoDB table.

The Requirement:

#

Identify how the development team should modify the IAM role or policies to resolve the Access Denied error and allow the application to read from the target DynamoDB table securely.

The Options

#

• A) Modify the IAM policy resource specification to "arn:aws:dynamodb:us-east-1:account-id:table/*" to broaden resource scope.
• B) Update the IAM policy to include "dynamodb:*" actions, granting full DynamoDB permissions.
• C) Create or update the IAM role trust policy to specify the EC2 service principal (ec2.amazonaws.com), then associate this policy with the role.
• D) Modify the IAM role trust relationship to include dynamodb.amazonaws.com as a trusted entity.

Google adsense

#

leave a comment:

Correct Answer

#

C

Quick Insight: The Developer IAM Role Trust Imperative

#

For Developer-focused troubleshooting, understanding the difference between IAM policy permissions and role trust relationships is critical. The role must trust the service using it (here, EC2), otherwise API calls will fail with Access Denied—even if the permissions policy looks correct.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option C

The Winning Logic

#

The most common cause of Access Denied errors when an application running on EC2 is invoking AWS API calls using an attached IAM role is a missing or incorrect trust relationship in the role. The trust policy dictates which entities (principals) are allowed to assume the role. For EC2 instance profiles, the trust policy must allow the EC2 service principal (ec2.amazonaws.com) to assume the role. Without this trust established, IAM denies access even if the permission policy is technically correct.

• The IAM policy attached to the role already correctly specifies exact DynamoDB read-only permissions scoped to the specific table resource — this is good principle of least privilege.
• Granting "dynamodb:*" (Option B) is over-permissive and unnecessary.
• Broadening resource access to all tables with wildcard (Option A) is not needed and reduces security.
• Trusting dynamodb.amazonaws.com (Option D) would be incorrect since DynamoDB service does not assume EC2 roles — EC2 instances do.

The Trap (Distractor Analysis):

#

• Option A: Expands permissions scope unnecessarily; does not fix permission denied if trust policy is missing.
• Option B: Overly broad permission; violates least privilege principle and is bad security practice.
• Option D: Misunderstands trust relationships—DynamoDB service does not call EC2 roles; role must trust EC2 service.

The Technical Blueprint

#

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

This is an example IAM role trust policy snippet that must be configured to allow an EC2 instance to assume the role.

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always check role trust policies when API access fails despite seemingly correct permissions.

Real World

#

In production environments, locking down both the trust policy and permissions policy is the standard for security. It is often overlooked that roles must trust the right AWS service principal, otherwise IAM denies the API call outright.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.