AWS DVA-C02 Drill: Lambda@Edge IAM Roles - Secure Frontend Credential Management

Jeff’s Note

#

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 the execution context and IAM capabilities of Lambda@Edge versus CloudFront Functions. In production, this is about knowing exactly which edge compute option supports IAM roles and can make AWS SDK calls to external services. Let’s drill down.”

The Certification Drill (Simulated Question)

#

Scenario

#

StreamVibe, a video streaming platform, uses a React-based frontend that directly calls the AWS JavaScript SDK to obtain temporary user credentials from AWS STS. The application’s static assets (HTML, CSS, JS bundles) are hosted in an S3 bucket named streamvibe-frontend-assets. Content delivery is handled through a CloudFront distribution with the S3 bucket configured as the origin.

During a security audit, the DevOps team discovered that the IAM credentials for the role used to assume user permissions are stored in plaintext within a config.json file bundled with the application code. This configuration is publicly accessible to anyone inspecting the browser’s network traffic or downloading the JavaScript bundle.

The Requirement

#

The lead developer must implement a solution that eliminates all hardcoded credentials from the frontend code while still allowing the application to retrieve temporary user credentials from AWS STS. The solution must maintain the current user experience and leverage the existing CloudFront distribution.

The Options

#

• A) Add a Lambda@Edge function to the distribution. Invoke the function on viewer request. Add permissions to the function’s execution role to allow the function to access AWS STS. Move all SDK calls from the frontend into the function.
• B) Add a CloudFront function to the distribution. Invoke the function on viewer request. Add permissions to the function’s execution role to allow the function to access AWS STS. Move all SDK calls from the frontend into the function.
• C) Add a Lambda@Edge function to the distribution. Invoke the function on viewer request. Move the credentials from the JSON file into the function. Move all SDK calls from the frontend into the function.
• D) Add a CloudFront function to the distribution. Invoke the function on viewer request. Move the credentials from the JSON file into the function. Move all SDK calls from the frontend into the function.

Google adsense

#

Correct Answer

#

Option A.

Quick Insight: The IAM Role Execution Imperative

#

• For Developer: Lambda@Edge functions execute with an IAM role that can be granted permissions to AWS services. CloudFront Functions run in a restricted sandbox without IAM role support or network access to AWS APIs. This is a critical architectural distinction that appears frequently in DVA-C02 scenarios involving edge compute security patterns.

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 A: Lambda@Edge with IAM Role-Based AWS STS Integration

The Winning Logic

#

This solution correctly addresses the security vulnerability by leveraging Lambda@Edge’s full IAM integration capabilities:

• IAM Role Assumption: Lambda@Edge functions execute with an IAM execution role. This role can be granted permissions to call sts:AssumeRole or other AWS STS APIs through standard IAM policies. The function code uses the AWS SDK with the execution role’s temporary credentials—no hardcoded secrets required.

• AWS SDK Compatibility: Lambda@Edge supports the full Node.js runtime environment, allowing you to use the AWS SDK for JavaScript v2 or v3 to make authenticated API calls to AWS STS. The SDK automatically uses the function’s execution role credentials via the AWS credentials provider chain.

• Request Interception Pattern: By triggering on viewer request, the Lambda@Edge function intercepts incoming requests before they reach the origin. This allows the function to authenticate the user, obtain temporary credentials from STS, and either inject them into the response headers or return them directly to the client—all without exposing credentials in the frontend bundle.

• Zero Credential Exposure: Moving SDK calls from the frontend to Lambda@Edge means credentials never exist in client-side code. The frontend makes a simple HTTP request to the CloudFront distribution, and Lambda@Edge handles the secure credential retrieval server-side.

Implementation Detail for DVA-C02: The Lambda@Edge execution role policy would include:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole",
        "sts:GetFederationToken"
      ],
      "Resource": "arn:aws:iam::123456789012:role/StreamVibeUserRole"
    }
  ]
}

The Trap (Distractor Analysis)

#

• Why not Option B? CloudFront Functions operate in a lightweight JavaScript runtime that does not support IAM execution roles or network calls to AWS services. CloudFront Functions are designed for simple request/response transformations (header manipulation, URL rewrites) and execute in under 1ms. They cannot make AWS SDK calls to STS or any other AWS service. This is a fundamental architectural limitation.

• Why not Option C? While Lambda@Edge can execute code, moving plaintext credentials from the frontend JSON file into the Lambda function code still violates the principle of least privilege. The credentials would still be hardcoded—just in a different location. The requirement explicitly states “without having any credentials hardcoded in the application code,” which extends to all application components, including Lambda functions. This solution doesn’t leverage IAM roles.

• Why not Option D? This combines two critical failures: (1) CloudFront Functions cannot access AWS STS due to their restricted execution environment, and (2) it still involves hardcoding credentials in the function code. This is the worst option as it both fails to solve the security problem and uses an incompatible service.

The Technical Blueprint

#

// Lambda@Edge Function (Node.js 18.x)
// Triggered on Viewer Request

const AWS = require('aws-sdk');
const sts = new AWS.STS({ region: 'us-east-1' });

exports.handler = async (event) => {
    const request = event.Records[0].cf.request;
    
    // Extract user identifier from request (e.g., JWT token in header)
    const userToken = request.headers['authorization']?.[0]?.value;
    
    try {
        // Assume role to get temporary credentials
        // Lambda execution role must have sts:AssumeRole permission
        const assumeRoleParams = {
            RoleArn: 'arn:aws:iam::123456789012:role/StreamVibeUserRole',
            RoleSessionName: `user-session-${Date.now()}`,
            DurationSeconds: 3600
        };
        
        const credentials = await sts.assumeRole(assumeRoleParams).promise();
        
        // Return credentials to client (or inject into response headers)
        const response = {
            status: '200',
            statusDescription: 'OK',
            headers: {
                'content-type': [{ key: 'Content-Type', value: 'application/json' }],
                'cache-control': [{ key: 'Cache-Control', value: 'no-store' }]
            },
            body: JSON.stringify({
                accessKeyId: credentials.Credentials.AccessKeyId,
                secretAccessKey: credentials.Credentials.SecretAccessKey,
                sessionToken: credentials.Credentials.SessionToken,
                expiration: credentials.Credentials.Expiration
            })
        };
        
        return response;
        
    } catch (error) {
        console.error('STS AssumeRole failed:', error);
        return {
            status: '500',
            statusDescription: 'Internal Server Error',
            body: JSON.stringify({ error: 'Credential retrieval failed' })
        };
    }
};

IAM Trust Policy for StreamVibeUserRole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/LambdaEdgeExecutionRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

The Comparative Analysis

#

Key Performance Note: Lambda@Edge cold starts add latency (50-200ms), but this is acceptable for authentication workflows. For DVA-C02, recognize that this trade-off is necessary when IAM integration is required.

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the DVA-C02 exam, when you see ‘AWS SDK calls to AWS services’ + ’edge computing’, always choose Lambda@Edge over CloudFront Functions. CloudFront Functions are restricted to lightweight transformations without network access.”

Real World

#

“In production at StreamVibe, we’d likely implement an additional API Gateway + Lambda backend for credential vending rather than using Lambda@Edge for every request. Lambda@Edge has geographic replication costs ($0.60 per 1M requests vs $0.20 for standard Lambda), and debugging edge functions is more complex. However, if sub-50ms response time at the edge is critical (e.g., for real-time bidding or authentication), Lambda@Edge with IAM roles is the architecturally correct pattern. We’d also implement credential caching with short TTLs to reduce STS API calls and costs.”

Additional Production Considerations:

• Use AWS Secrets Manager rotation for the IAM role’s trust policy if roles change frequently
• Implement CloudWatch Logs Insights queries to monitor STS AssumeRole failures across all edge locations
• Consider Cognito Identity Pools as an alternative to custom STS integration for simpler user credential management

Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam. All company names, scenarios, and technical implementations are fictional and created for educational purposes. Always refer to official AWS documentation and practice exams for certification preparation.