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 where to securely handle credential fetching without embedding secrets in frontend code. In production, this is about knowing exactly which edge compute options support backend AWS SDK calls and how to delegate credential retrieval without compromising security. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
TechHive Solutions recently launched a client-facing social networking app. The app’s frontend is written in JavaScript and uses the AWS SDK for JavaScript to access AWS Security Token Service (AWS STS) for temporary credentials. All assets like images and scripts are stored in an Amazon S3 bucket, which is fronted by an Amazon CloudFront distribution.
Currently, the app stores the IAM role credentials required for the SDK calls inside a plaintext JSON file embedded in the frontend code. This is a security risk and must be eliminated.
The Requirement: #
TechHive’s development team needs to implement a solution that allows the application to obtain user credentials dynamically without any hardcoded credentials inside the frontend JavaScript code.
The Options #
-
A) Add a Lambda@Edge function to the CloudFront distribution and invoke it on viewer requests. Grant the Lambda@Edge function permission to call AWS STS. Move all AWS SDK calls from the frontend into the Lambda@Edge function.
-
B) Add a CloudFront Function to the CloudFront distribution and invoke it on viewer requests. Grant the CloudFront Function permission to call AWS STS. Move all AWS SDK calls from the frontend into the CloudFront Function.
-
C) Add a Lambda@Edge function to the CloudFront distribution and invoke it on viewer requests. Move the hardcoded credentials from the JSON file into the Lambda@Edge function. Move all AWS SDK calls from the frontend into the Lambda@Edge function.
-
D) Add a CloudFront Function to the CloudFront distribution and invoke it on viewer requests. Move the hardcoded credentials from the JSON file into the CloudFront Function. Move all AWS SDK calls from the frontend into the CloudFront Function.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
- Lambda@Edge supports the AWS SDK and can securely assume roles and call AWS STS. This enables backend credential retrieval without hardcoding secrets in the frontend.
- CloudFront Functions are lightweight JavaScript snippets that run at the edge and do not support AWS SDK or calls to AWS APIs, so they cannot retrieve credentials or assume roles.
- Moving hardcoded credentials anywhere in code is a security risk and must be avoided.
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
The Winning Logic #
Lambda@Edge functions run in a Node.js runtime environment with support for the AWS SDK, which means they can assume IAM roles dynamically, call AWS STS to obtain temporary credentials, and return them to the frontend without exposing static credentials. This fits perfectly with the requirement to eliminate any hardcoded credentials.
Additionally, moving SDK calls to Lambda@Edge ensures backend logic stays secure and does not expose sensitive role information in the client-side code.
The Trap (Distractor Analysis): #
-
Why not Option B or D (CloudFront Functions)?
CloudFront Functions are designed strictly for lightweight request/response manipulation using limited JavaScript functionality. They cannot call AWS service APIs or run SDK code as they do not have AWS credentials or the runtime environment. -
Why not Option C?
Although Lambda@Edge can securely run SDK calls, moving hardcoded credentials into Lambda@Edge copies the security risk elsewhere. Best practice is to rely on assigned execution roles and not embed credentials anywhere in code, even backend code.
The Technical Blueprint #
# Example IAM policy snippet to attach to the Lambda@Edge execution role to allow STS access:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/YourAppRole"
}
]
}
The Comparative Analysis #
| Option | API/Runtime Support for AWS SDK | Security Posture | Feasibility to Call STS | Notes |
|---|---|---|---|---|
| A | Full Node.js runtime, AWS SDK | Secure, uses IAM roles | Yes | Correct approach for dynamic creds |
| B | Limited JS runtime, no SDK | Cannot securely call AWS | No | Cannot call STS or run SDK |
| C | Lambda@Edge supported | Hardcoded creds risk | Yes | Embeds secrets – bad security |
| D | CloudFront Function only | Hardcoded creds risk | No | Runs only simple JS, no SDK |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick Lambda@Edge over CloudFront Functions when you need to run AWS SDK calls or access AWS service APIs.
Real World #
In many production environments, a more scalable approach might be to use Amazon Cognito Identity Pools for federated user access, or leverage a backend API proxy to issue credentials securely, but Lambda@Edge remains a valid pattern for edge-secure backend logic.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.