Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, the confusion often lies in understanding how granular IAM permissions differentiate read vs. write operations on DynamoDB. In production, this is about knowing exactly which API actions grant read capabilities without unintentionally permitting writes. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
The engineering team at BrightWave Tech is building a serverless analytics pipeline that uses AWS Lambda functions to process incoming customer order data stored in a DynamoDB table named CustomerOrders. The team must ensure that the Lambda function responsible for data reporting can only read data from CustomerOrders for analysis. It must not have permissions to modify or create items in this table.
The Requirement: #
You need to define an IAM policy statement attached to the Lambda execution role that allows only read operations on the CustomerOrders DynamoDB table, explicitly preventing any write or update access.
The Options #
- A)
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":[
"dynamodb:BatchGetItem",
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchWriteItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem"
],
"Resource":"arn:aws:dynamodb:us-west-2:987654321098:table/CustomerOrders"
}]
}
- B)
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"dynamodb:PutItem",
"dynamodb:Query",
"dynamodb:GetItem",
"dynamodb:Scan"
],
"Resource":"arn:aws:dynamodb:us-west-2:987654321098:table/CustomerOrders"
}
]
}
- C)
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Deny",
"Action":[
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:PutItem",
"dynamodb:UpdateItem"
],
"Resource":"arn:aws:dynamodb:us-west-2:987654321098:table/CustomerOrders"
}]
}
- D)
{
"Version":"2012-10-17",
"Statement":[ {
"Effect":"Allow",
"Action":[
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchGetItem"
],
"Resource":"arn:aws:dynamodb:us-west-2:987654321098:table/CustomerOrders"
} ]
}
Google adsense #
leave a comment:
Correct Answer #
D
Quick Insight: The Developer Imperative #
A well-scoped IAM policy explicitly grants only read actions—such as
GetItem,Query,Scan, andBatchGetItem—to ensure the Lambda can fetch data without any risk of modifying the table. Avoid including any write-related actions likePutItemorUpdateItemwhich would inadvertently allow data changes.
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 D
The Winning Logic #
- The policy in Option D grants only the necessary DynamoDB read actions:
GetItem— retrieves a single item by primary key.Query— retrieves items based on primary key or indexes.Scan— reads the entire table or index.BatchGetItem— reads multiple items in a single request.
- It strictly excludes any write or update operations (
PutItem,UpdateItem,BatchWriteItem), following the principle of least privilege. - Lambda execution role with this policy can securely access data without risk of accidental mutation.
The Trap (Distractor Analysis): #
- Why not Option A?
Includes write actions likePutItem,UpdateItem, andBatchWriteItem—violates requirement that no writes be allowed. - Why not Option B?
Includes thePutItemaction which grants write permissions, not strictly read-only. - Why not Option C?
Uses an explicit Deny on some actions but also denies read actions (Query,Scan), which breaks the ability to read; moreover, explicit Deny statements should be used cautiously and separately, not as a replacement for Allow.
The Technical Blueprint #
# Example JSON IAM policy snippet for read-only DynamoDB access via CLI
aws iam create-policy --policy-name ReadOnlyCustomerOrdersPolicy --policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchGetItem"
],
"Resource": "arn:aws:dynamodb:us-west-2:987654321098:table/CustomerOrders"
}]
}'
The Comparative Analysis (Developer Perspective) #
| Option | API Complexity | Performance Impact | Use Case |
|---|---|---|---|
| A | High; allows read + write APIs | Risk of unintended writes; security risk | Invalid; does not meet least privilege |
| B | Medium; includes some write | Potential write operations allowed | Invalid; violates read-only requirement |
| C | Confusing; explicit Deny includes read ops | Blocks required reads; breaks functionality | Incorrect; denies key read permissions |
| D | Precise read-only APIs | Safe, clear least privilege | Correct; strictly read-only access granted |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick least privilege IAM policies that include only the needed service actions.”
Real World #
“In production, developers often inadvertently grant excessive permissions, leading to accidental data mutations or security issues. Always audit read vs. write IAM actions carefully when assigning Lambda roles.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.