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 how to leverage ALB’s built-in authentication features without changing application code. In production, this is about knowing exactly which load balancer types support OIDC authentication and how listener rules are configured. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
TechForward, a fintech startup, has an internal web dashboard that contains highly confidential financial data. The CTO wants this dashboard to be accessible publicly but strictly limited to employees who authenticate via the company’s OpenID Connect (OIDC) identity provider. The lead developer must enable secure access without touching or redeploying the existing web application code.
The Requirement #
Implement authentication to ensure only users authenticated through the OIDC IdP can access the public website, all without modifying the backend application.
The Options #
- A) Create a public Network Load Balancer (NLB).
- B) Create a public Application Load Balancer (ALB).
- C) Configure a listener on the load balancer for HTTPS port 443 and add a default authenticate action with the OIDC IdP configuration.
- D) Configure a listener on the load balancer for HTTP port 80 and add a default authenticate action with the OIDC IdP configuration.
- E) Configure a listener on the load balancer for HTTPS port 443 and add a default AWS Lambda action with an ARN to a Lambda authentication function.
Google adsense #
leave a comment:
Correct Answer #
B) Create a public Application Load Balancer (ALB).
C) Configure a listener on the load balancer for HTTPS port 443 and add a default authenticate action with the OIDC IdP configuration.
Quick Insight: The Developer Imperative #
- ALBs natively support OIDC authentication, letting you secure access without modifying application code.
- NLBs don’t support advanced Layer 7 authentication features like OIDC.
- HTTPS on port 443 is required for secure auth flows; HTTP on port 80 cannot enforce authenticated sessions securely.
- While Lambda authorizer is possible, it requires custom code and changes, so it’s out of scope here.
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 #
Options B and C
The Winning Logic #
The Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS) and supports native integration for OIDC authentication. This allows you to add a ‘default authenticate’ action on an HTTPS listener that redirects unauthenticated requests to the OIDC provider, handles tokens, and enforces authentication before forwarding requests to the backend. With this approach, you do not need to modify any application code, fulfilling the “no changes to website” requirement.
- Option B: NLB lacks support for Layer 7 routing and authentication, so it cannot perform OIDC authentication.
- Option C: HTTPS on port 443 is mandatory because OIDC requires encrypted sessions to secure tokens and user credentials.
- Option D: HTTP on port 80 cannot enforce OIDC securely and is not supported for this action.
- Option E: Lambda actions can implement custom authentication, but this requires custom code and Lambda permissions, violating the problem constraint of not editing the app or adding new logic.
The Trap (Distractor Analysis) #
- Why not A? Network Load Balancer is a Layer 4 load balancer. It cannot inspect HTTP headers or support OIDC authentication natively.
- Why not D? While ALB can listen on port 80, OIDC authentication requires HTTPS (443) because tokens and credentials must be transferred securely.
- Why not E? Although Lambda authorizers provide custom auth scenarios, they involve writing and maintaining Lambda code and add operational complexity, which is against the requirement “without editing the website” or adding custom auth logic.
The Technical Blueprint #
# Example AWS CLI commands to create an ALB with OIDC authentication configuration
aws elbv2 create-load-balancer \
--name techforward-alb \
--subnets subnet-abc123 subnet-def456 \
--security-groups sg-0123456789abcdef0 \
--scheme internet-facing \
--type application
aws elbv2 create-listener \
--load-balancer-arn <alb-arn> \
--protocol HTTPS \
--port 443 \
--certificates CertificateArn=<certificate-arn> \
--default-actions Type=authenticate-oidc,AuthenticateOidcConfig='ClientId=<client-id>,Issuer=<oidc-issuer-url>,AuthorizationEndpoint=<auth-endpoint>,TokenEndpoint=<token-endpoint>,UserInfoEndpoint=<userinfo-endpoint>,Scope=openid,email,SessionCookieName=AWSELBAuthSession,OnUnauthenticatedRequest=authenticate,TokenValidationParameters={"Audience":["<client-id>"]}',Type=forward,TargetGroupArn=<target-group-arn>
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low | High throughput | TCP/UDP forwarding only; no auth |
| B | Moderate (Layer 7 APIs) | Slightly higher latency due to auth | Ideal for HTTP-based auth like OIDC |
| C | Native support for OIDC | Efficient token handling | Required for secure HTTPS OIDC auth |
| D | Incorrect port | No secure auth | Not valid for OIDC authentication |
| E | High (custom Lambda) | Adds compute latency | Custom auth logic - beyond scope, complex |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the AWS Developer Associate exam, when a question involves requiring OpenID Connect authentication without modifying backend code, always think Application Load Balancer with HTTPS listener and default authenticate action.”
Real World #
“In real projects, you might see Lambda authorizers for bespoke authentication needs, but to keep costs and complexity down, the ALB native OIDC feature is often preferred.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.