Skip to main content

AWS DVA-C02 Drill: Lambda IAM Permissions - Execution Role vs. Resource Policy

Jeff Taakey
Author
Jeff Taakey
21+ Year Enterprise Architect | AWS SAA/SAP & Multi-Cloud Expert.

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:PutEvents permission 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:

  1. CloudTrail logs for the exact API call and IAM principal used
  2. IAM Policy Simulator to test permission evaluation before deployment
  3. Resource-based policies on the target service (EventBridge buses can have their own policies)
  4. 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.

The DevPro Network: Mission and Founder

A 21-Year Tech Leadership Journey

Jeff Taakey has driven complex systems for over two decades, serving in pivotal roles as an Architect, Technical Director, and startup Co-founder/CTO.

He holds both an MBA degree and a Computer Science Master's degree from an English-speaking university in Hong Kong. His expertise is further backed by multiple international certifications including TOGAF, PMP, ITIL, and AWS SAA.

His experience spans diverse sectors and includes leading large, multidisciplinary teams (up to 86 people). He has also served as a Development Team Lead while cooperating with global teams spanning North America, Europe, and Asia-Pacific. He has spearheaded the design of an industry cloud platform. This work was often conducted within global Fortune 500 environments like IBM, Citi and Panasonic.

Following a recent Master’s degree from an English-speaking university in Hong Kong, he launched this platform to share advanced, practical technical knowledge with the global developer community.


About This Site: AWS.CertDevPro.com


AWS.CertDevPro.com focuses exclusively on mastering the Amazon Web Services ecosystem. We transform raw practice questions into strategic Decision Matrices. Led by Jeff Taakey (MBA & 21-year veteran of IBM/Citi), we provide the exclusive SAA and SAP Master Packs designed to move your cloud expertise from certification-ready to project-ready.