How to Troubleshoot a 502 Bad Gateway Error in Elastic Beanstalk
A company uses AWS Elastic Beanstalk to deploy a web application. The deployment fails with a '502 Bad Gateway' error. The developer checks the logs and sees that the application is running but returns errors. The environment uses a load balancer. What is the MOST likely cause?
⚠ Common exam trap
Many candidates confuse a 502 Bad Gateway with a security group or missing file issue, but the 502 specifically points to a communication failure between the proxy and the application process, not to external network access or deployment artifacts.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The application is not binding to the correct port or is crashing under load.
A 502 Bad Gateway error from an Elastic Beanstalk environment with a load balancer typically indicates that the reverse proxy (nginx or Apache) is unable to communicate with the application process. Since the logs show the application is running but returning errors, the most likely cause is that the application is not binding to the correct port (expected port 8080 by default) or is crashing under load, causing the proxy to receive no valid response and return a 502.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The application source bundle is missing a required file.
Why it's wrong here
A missing required file in the source bundle typically prevents deployment or causes the application process to fail during startup, resulting in a failed environment health status or an HTTP 500 from the application itself. A 502 Bad Gateway is generated by the nginx reverse proxy or load balancer when it cannot obtain a valid HTTP response from the configured upstream, such as when the connection is refused or reset. Even if the app crashes because of a missing file, Elastic Beanstalk's health checks would detect it and report severe health or return 503, not 502, unless the proxy specifically cannot reach the listener—which relates to port binding, not file presence.
- ✗
The security group of the environment does not allow inbound HTTP traffic.
Why it's wrong here
If the environment's security group denies inbound HTTP traffic from the load balancer, the load balancer's health checks and request forwarding will time out because connections to the instance are blocked. This usually manifests as 504 Gateway Timeout or 503 Service Unavailable from the Elastic Load Balancer, since no healthy instances are available. A 502 specifically indicates that the proxy received an invalid or empty HTTP response, not that traffic was filtered; a blocking security group would cause a connection timeout at the TCP layer rather than a malformed proxy response.
- ✗
The environment's environment variables are misconfigured.
Why it's wrong here
Environment variables that are misconfigured typically cause the application to fail at runtime by throwing exceptions, producing wrong outputs, or returning HTTP 500 responses because the code itself is running but cannot complete its logic. A 502 Bad Gateway is not an application-level error; it's a proxy-level signal that the upstream server didn't respond correctly to the proxy. Unless the misconfigured variable directly causes the process to exit without releasing the port, it won't trigger 502—it will more likely fail health checks and lead to 500/503 from the app or ELB.
- ✓
The application is not binding to the correct port or is crashing under load.
Why this is correct
The correct answer is that the application is either listening on a different port than the one nginx is configured to forward to (typically the PORT environment variable set by Elastic Beanstalk), or it is crashing under load, causing the port to close and nginx to receive a connection refused. In either case, when nginx attempts to proxy the request to the application's localhost port, it fails to get a valid HTTP response and returns 502 Bad Gateway to the client. Monitoring memory usage, checking nginx error logs for 'connect() failed' lines, and confirming the application binds to 0.0.0.0 instead of 127.0.0.1 are key diagnostic steps.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.