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 understanding when to use execution roles versus resource-based policies for Lambda. In production, this is about knowing exactly which IAM mechanism grants outbound permissions versus inbound invocation rights. Let’s drill down.”
The Certification Drill (Simulated Question) #
Scenario #
Your team at FinStream Analytics is building a real-time transaction processing system. You’ve deployed a Lambda function that analyzes payment transactions and needs to publish custom events to an EventBridge event bus for downstream microservices to consume. The function code uses the AWS SDK for JavaScript v3 with the PutEventsCommand to send events, and following AWS best practices, you haven’t hard-coded any credentials in the application code.
After deployment, the Lambda function is consistently failing. CloudWatch Logs show repeated AccessDeniedException errors when attempting to call the EventBridge PutEvents API.
The Requirement #
Resolve the permission issue so the Lambda function can successfully publish events to EventBridge without modifying the application code or introducing security vulnerabilities.
The Options #
- A) Configure a VPC peering connection between the Lambda function and EventBridge.
- B) Modify their AWS credentials to include permissions for the PutEvents EventBridge action.
- C) Modify the Lambda function execution role to include permissions for the PutEvents EventBridge action.
- D) Add a resource-based policy to the Lambda function to include permissions for the PutEvents EventBridge action.
Correct Answer #
Option C.
Quick Insight: The Developer’s Permissions Imperative #
For DVA-C02, understanding the Lambda permission model is non-negotiable. When Lambda needs to call other AWS services (outbound), use the execution role. When other services need to invoke Lambda (inbound), use resource-based policies. The SDK automatically uses the execution role credentials via the instance metadata service—no explicit credentials needed in code.
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: Modify the Lambda function execution role to include permissions for the PutEvents EventBridge action.
The Winning Logic #
When Lambda makes outbound API calls to other AWS services, it uses the execution role attached to the function. The AWS SDK automatically retrieves temporary credentials from the execution role without requiring explicit credentials in code.
Why this works:
- Execution Role Mechanism: The Lambda service assumes the execution role and provides temporary credentials to the function runtime via environment variables (
AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,AWS_SESSION_TOKEN). - SDK Default Credential Chain: The AWS SDK automatically uses these environment variables—developers don’t need to specify credentials explicitly.
- Principle of Least Privilege: You grant only the
events:PutEventspermission to the specific EventBridge bus, following security best practices.
The Required IAM Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "events:PutEvents",
"Resource": "arn:aws:events:us-east-1:123456789012:event-bus/custom-bus"
}
]
}
Developer Implementation Detail: The error AccessDeniedException specifically indicates that the SDK successfully retrieved credentials (otherwise you’d see CredentialsError), but those credentials lack the necessary IAM permissions—pointing directly to a missing execution role policy.
The Trap (Distractor Analysis) #
-
Why not Option A (VPC peering)? EventBridge is an AWS-managed public service accessible via AWS’s internal network. Lambda functions can reach EventBridge without VPC configuration. VPC peering is for connecting your own VPCs, not for accessing AWS services. This is a network-layer distractor for a permissions problem.
-
Why not Option B (Modify AWS credentials)? This violates multiple best practices:
- Hard-coding credentials in code or environment variables exposes secrets in logs, version control, and memory dumps.
- Long-term credentials defeat the purpose of Lambda’s built-in temporary credential rotation.
- The question explicitly states “specifies no credentials in the code”—modifying personal IAM user credentials wouldn’t help the Lambda function’s runtime context.
-
Why not Option D (Resource-based policy on Lambda)? Resource-based policies control who can invoke your Lambda function (inbound permissions). They’re used when EventBridge, API Gateway, or S3 needs to trigger Lambda. They do not grant Lambda permissions to call other services (outbound). This is the classic DVA-C02 trap: confusing the direction of permissions.
The Technical Blueprint #
# Python SDK example showing automatic credential usage
import boto3
import json
# SDK automatically uses execution role credentials
# No explicit credential configuration needed
eventbridge_client = boto3.client('events')
def lambda_handler(event, context):
try:
# PutEvents call using implicit execution role credentials
response = eventbridge_client.put_events(
Entries=[
{
'Source': 'finstream.transactions',
'DetailType': 'Payment Processed',
'Detail': json.dumps({
'transactionId': event['id'],
'amount': event['amount']
}),
'EventBusName': 'custom-bus'
}
]
)
# Check for failed entries
if response['FailedEntryCount'] > 0:
print(f"Failed entries: {response['Entries']}")
return {
'statusCode': 200,
'body': 'Event published successfully'
}
except eventbridge_client.exceptions.ClientError as e:
# AccessDeniedException caught here if execution role lacks permissions
print(f"Error code: {e.response['Error']['Code']}")
print(f"Error message: {e.response['Error']['Message']}")
raise
AWS CLI Command to Attach Policy:
# Create the IAM policy
aws iam create-policy \
--policy-name LambdaEventBridgePutEvents \
--policy-document file://eventbridge-policy.json
# Attach to Lambda execution role
aws iam attach-role-policy \
--role-name FinStreamLambdaExecutionRole \
--policy-arn arn:aws:iam::123456789012:policy/LambdaEventBridgePutEvents
The Comparative Analysis #
| Option | IAM Mechanism | Permission Direction | API Complexity | Use Case | DVA-C02 Trap Factor |
|---|---|---|---|---|---|
| A (VPC Peering) | Network layer | N/A | High (unnecessary) | Connecting two VPCs | ⚠️ High - Confuses network with permissions |
| B (User Credentials) | Long-term IAM user | Outbound | Medium | Legacy applications | ⚠️ Very High - Violates security best practices |
| C (Execution Role) ✅ | Temporary role credentials | Outbound (Lambda → Service) | Low (automatic) | Lambda calling AWS APIs | ✅ Correct pattern |
| D (Resource Policy) | Trust relationship | Inbound (Service → Lambda) | Medium | Services invoking Lambda | ⚠️ Very High - Reverse direction confusion |
Developer Insight: The execution role uses AWS STS AssumeRole behind the scenes, rotating credentials every function invocation. Resource-based policies use AWS IAM resource policies and never grant outbound permissions.
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the DVA-C02 exam, when Lambda needs to call/write/publish to another AWS service (S3, DynamoDB, EventBridge, SNS), always modify the execution role. When a service needs to invoke/trigger Lambda, use a resource-based policy.”
Real World #
“In production, we often create custom managed policies grouped by function purpose (e.g., EventProcessorPolicy, DataIngestionPolicy) and attach them to multiple Lambda execution roles via Terraform modules. This ensures consistency across teams and simplifies auditing via AWS Config rules. We also use IAM Access Analyzer to identify overly permissive policies and refine them to specific EventBridge bus ARNs rather than using wildcards.”
Additional Real-World Consideration:
When troubleshooting AccessDeniedException, always check:
- CloudTrail logs for the exact API call and IAM principal used
- IAM Policy Simulator to test permission evaluation before deployment
- Resource-based policies on the target service (EventBridge buses can have their own policies)
- Service Control Policies (SCPs) in AWS Organizations that might deny actions at the account level
Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.