AWS Elastic Beanstalk Cheat Sheet (2026): Key Concepts + 10 Exam Practice Questions

AWS Elastic Beanstalk is one of those services that trips up candidates on every AWS certification exam — not because it's complicated, but because the exam loves testing the details most people skim over. Which deployment policy avoids downtime? When should you keep your database outside Beanstalk? What exactly happens to your RDS instance if you terminate an environment?

This cheat sheet gives you everything you need to know about Elastic Beanstalk for the SAA-C03, DVA-C02, and DOP-C02 exams — clearly structured, no filler. And unlike most cheat sheets that stop at theory, this one ends with 10 real exam-style practice questions so you can test your understanding before exam day.

Whether you're reviewing Elastic Beanstalk for the first time or doing a final pass before your exam, you'll leave this page with a clear mental model and a solid sense of where you stand.

What is AWS Elastic Beanstalk?

AWS Elastic Beanstalk is a Platform-as-a-Service (PaaS) that lets you deploy and scale web applications without managing the underlying infrastructure. You upload your code, and Elastic Beanstalk automatically handles capacity provisioning, load balancing, auto scaling, and application health monitoring.

The critical mental model for the exam: Elastic Beanstalk is not serverless. It still provisions and runs EC2 instances, Elastic Load Balancers, and Auto Scaling groups under the hood — you just don't manage them directly. You pay only for those underlying AWS resources. Elastic Beanstalk itself has no additional charge.

This distinction matters because exam questions often present scenarios where a company wants to "stop managing servers" — Elastic Beanstalk is the right answer when the application still needs a traditional runtime environment. Lambda is the right answer when the workload is event-driven and stateless.

Supported Languages and Platforms

Elastic Beanstalk natively supports the following languages:

Language	Notes
Go	—
Java	Including Corretto
.NET	Windows and Linux
Node.js	—
PHP	—
Python	—
Ruby	—

It also supports the following web containers: Tomcat, Passenger, and Puma.

For containerized workloads, Elastic Beanstalk supports Docker in both single-container and multi-container configurations.

Your application's public URL follows this format: subdomain.region.elasticbeanstalk.com

💡 Exam trap: Elastic Beanstalk does NOT support every language out of the box. If an exam question mentions an unsupported language or a custom runtime, the correct answer usually involves Docker — which lets you run any environment inside a container on Beanstalk.

Core Concepts — What You Must Know for the Exam

Elastic Beanstalk has a specific vocabulary that appears directly in exam questions. Learn these definitions precisely — the exam often uses them as distractors.

Concept	Definition
Application	A logical collection of Elastic Beanstalk components — environments, versions, and configurations. Think of it as a folder.
Application Version	A specific, labeled iteration of deployable code pointing to an S3 object. Multiple versions can coexist in one application.
Environment	A single application version deployed onto AWS resources. One environment runs one version at a time, but the same version can run in multiple environments simultaneously.
Environment Tier	Determines the resource type provisioned: web server tier for HTTP requests, worker tier for SQS queue processing.
Environment Configuration	A collection of parameters that define how an environment and its resources behave.
Saved Configuration	A reusable template used as a starting point for new environments.
Platform	A combination of OS, language runtime, web/application server, and Elastic Beanstalk components.

Application Version Lifecycle Policy

There is a hard limit on the number of application versions you can store per application. When you approach this limit, new deployments will fail.

To avoid this, configure an application version lifecycle policy to automatically delete old versions based on either:

Age — delete versions older than X days
Count — keep only the N most recent versions

Versions currently deployed to an environment are never deleted by the lifecycle policy, regardless of the rules you set.

💡 Exam trap: This limit and the lifecycle policy workaround appears regularly in DVA-C02 scenario questions. If you see "deployment is failing because too many versions exist" — lifecycle policy is the answer.

Environment Types

Web Server Environment

Handles incoming HTTP/HTTPS requests from end users. Elastic Beanstalk provisions an EC2 instance (or fleet of instances behind an Elastic Load Balancer) depending on the configuration you choose.

Use this for: web applications, REST APIs, frontend services.

Worker Environment

Pulls tasks from an Amazon SQS queue and processes them asynchronously. Elastic Beanstalk automatically provisions the SQS queue and installs a daemon on each EC2 instance that polls the queue.

Use this for: background jobs, email sending, image processing, long-running tasks.

💡 Exam tip: Web server + worker is a classic decoupled architecture pattern on the exam. If a scenario describes a web app that needs to offload long-running tasks to avoid timeouts — the answer is a worker environment connected via SQS.

Single-Instance vs Load-Balanced

	Single-Instance	Load-Balancing + Autoscaling
Use case	Development, testing	Production
EC2 instances	One, with Elastic IP	Multiple, behind ELB
Cost	Lower	Higher
Availability	No redundancy	Multi-AZ capable
Scaling	Manual	Automatic

Deployment Policies — The Most Tested Topic on the Exam

Deployment policies control how Elastic Beanstalk rolls out new application versions to your environment. This is the single most tested Elastic Beanstalk topic across SAA-C03, DVA-C02, and DOP-C02. You need to know each policy's behavior, downtime impact, and cost implications.

All at Once

Deploys the new version to all instances simultaneously. The fastest deployment method, but your application is completely unavailable during the update.

Downtime: Yes — all instances are out of service during deployment
Cost: No additional instances
Rollback: Manual — re-deploy the previous version (also causes downtime)
Use case: Development and test environments where downtime is acceptable

Rolling

Deploys the new version in batches. At any given moment, a portion of your instances run the old version while another portion runs the new version. Your application stays available throughout, but at reduced capacity during the deployment.

Downtime: No — but reduced capacity during deployment
Cost: No additional instances
Rollback: Manual — requires another rolling deployment backward
Use case: Production environments where some capacity reduction is acceptable

Rolling with Additional Batch

Same as Rolling, but first launches a new batch of instances before starting the update. This ensures you never lose capacity during deployment — the total instance count stays at 100% throughout.

Downtime: No — full capacity maintained at all times
Cost: Small additional cost for the extra batch during deployment
Rollback: Manual — requires another rolling deployment backward
Use case: Production environments where maintaining full capacity is important

Immutable

Deploys the new version to a completely new set of instances in a temporary Auto Scaling group. Once the new instances pass health checks, they replace the old instances entirely.

Downtime: No — traffic shifts only after health checks pass
Cost: Highest — doubles the instance count during deployment
Rollback: Fastest — simply terminate the new Auto Scaling group
Use case: Production environments where rollback speed and deployment safety are the top priority

Traffic Splitting (Canary Deployment)

Deploys the new version to a separate fleet of instances and forwards a configurable percentage of incoming traffic to them. You monitor the new version's health before committing to a full rollout.

Downtime: No
Cost: Additional instances during the split period
Rollback: Automatic — if health checks fail, traffic shifts back immediately
Use case: Canary deployments — testing a new version with a small subset of real users before full rollout

Deployment Policies Comparison

Policy	Downtime	Full Capacity	Extra Cost	Rollback Speed	Best For
All at once	✅ Yes	❌ No	None	Slow	Dev / Test
Rolling	❌ No	❌ Reduced	None	Slow	Production (cost-sensitive)
Rolling + batch	❌ No	✅ Yes	Low	Slow	Production (capacity-sensitive)
Immutable	❌ No	✅ Yes	High	Fast	Production (safety-first)
Traffic splitting	❌ No	✅ Yes	Medium	Automatic	Canary / A-B testing

💡 Exam pattern: Look for these keywords to identify the right policy:

"no downtime" + "rollback quickly" → Immutable

"no downtime" + "lowest cost" → Rolling

"test with real users before full rollout" → Traffic splitting

"development environment" + "fastest deployment" → All at once

"maintain full capacity" + "no extra cost concern" → Rolling with additional batch

Environment Configurations

When Elastic Beanstalk provisions an environment, it creates and manages a set of AWS resources on your behalf. Understanding what gets created — and how to configure it — is essential for both the exam and real-world usage.

What Your Environment Contains

EC2 instances — configured to run your application on the platform you chose. Elastic Beanstalk handles the AMI selection, instance type, and OS configuration.

Auto Scaling group — ensures there is always at least one instance running in single-instance environments, and manages scale-out and scale-in in load-balanced environments based on the rules you define.

Elastic Load Balancer — created automatically when you enable load balancing. Distributes incoming traffic across all healthy instances in your environment.

Amazon RDS — optionally provisioned inside your environment to provide a database. Available engines: MySQL, PostgreSQL, Oracle, SQL Server.

Environment properties — key-value pairs passed to your application at runtime. Used to inject secrets, endpoints, feature flags, and environment-specific settings without hardcoding them.

Amazon SNS notifications — optionally configured to alert you when important environment events occur, such as deployment failures or health degradation.

Elastic IP address — assigned to the EC2 instance in single-instance environments to provide a stable public IP.

Configuration Files (.ebextensions)

You can customize your Elastic Beanstalk environment by including configuration files in your application source bundle. These files:

Live in a folder named .ebextensions at the root of your project
Are formatted in YAML or JSON
Have a .config file extension
Are executed in alphabetical order during environment creation and updates

Use .ebextensions to install packages, run scripts, set environment variables, or configure AWS resources beyond what the console allows.

💡 Exam tip: If a question asks how to customize the Elastic Beanstalk environment at deployment time — install a package, configure nginx, or run a script — the answer is .ebextensions configuration files.

Environment Links

You can connect multiple Elastic Beanstalk environments using environment links. This allows one environment to reference another by name — for example, a frontend web server environment linking to a backend worker environment — without hardcoding IP addresses or endpoints.

Rebuilding Terminated Environments

If an environment is accidentally terminated, you can rebuild it within six weeks of termination using the same name, ID, and configuration. After six weeks, this is no longer possible.

💡 Exam trap: This is a six-week window, not indefinite. Questions sometimes test whether candidates know this limit exists.

Database Best Practices — A Critical Exam Topic

This is one of the most common Elastic Beanstalk traps on the exam. There are two ways to use a database with Elastic Beanstalk, and the difference has significant consequences.

Database Inside Elastic Beanstalk (Not Recommended for Production)

You can provision an RDS instance directly within your Elastic Beanstalk environment. This is convenient for development but has a critical flaw:

If you terminate the environment, the RDS instance is also deleted — along with all its data.

This is fine for throwaway dev environments. It is a serious risk for production.

Database Outside Elastic Beanstalk (Recommended for Production)

Provision your RDS instance independently — completely separate from your Elastic Beanstalk environment. Connect your application to it via environment properties.

Benefits:

Your data persists if the Elastic Beanstalk environment is terminated or replaced
You can connect multiple environments (dev, staging, prod) to different databases
You have full control over RDS configuration, backups, and Multi-AZ settings

💡 Exam pattern: Any question that mentions production data, data persistence, or "what happens to the database when the environment is terminated" — the correct answer always involves an externally provisioned RDS instance.

Monitoring

Basic Health Reporting

By default, Elastic Beanstalk reports environment health based on how your application responds to HTTP health checks. Health status is color-coded: Green (healthy), Yellow (degraded), Red (severely degraded), Grey (unknown).

Enhanced Health Reporting

An optional feature that provides deeper visibility. When enabled, Elastic Beanstalk collects additional metrics and publishes them to Amazon CloudWatch as custom metrics, giving you:

Per-instance health breakdowns
HTTP response code distributions (2xx, 3xx, 4xx, 5xx)
Root cause analysis for degraded instances
Latency percentiles (p50, p75, p99)

💡 Exam tip: If a question asks how to get detailed per-instance health metrics or HTTP status code distributions — the answer is enhanced health reporting.

Environment Monitoring Pages

Page	Purpose
Configuration	Shows provisioned resources and lets you modify environment settings
Health	Shows per-instance health status and detailed health information
Monitoring	Shows environment-level statistics — CPU, latency, request count
Events	Shows informational and error messages from AWS services
Tags	Manage key-value tags applied to environment resources

Log Access

View logs directly from the console without SSH access
Stream logs to CloudWatch Logs for long-term retention
Store logs in S3 — optionally rotated every hour

💡 Exam tip: "Access logs without logging into application servers" is a specific Elastic Beanstalk capability. If a question asks how to retrieve logs without SSH — this is the answer.

Security

Service Role vs Instance Profile

	Service Role	Instance Profile
Assumed by	Elastic Beanstalk itself	EC2 instances running your app
Purpose	Manage AWS resources on your behalf	Allow your app to access AWS services
Example permissions	Create Auto Scaling groups, configure ELB	Read from S3, write to X-Ray, access SSM

💡 Exam trap: These two roles are frequently confused. Service role = what Beanstalk can do. Instance profile = what your application running on EC2 can do. Read the scenario carefully to identify which level the permission error is occurring at.

Managed Platform Updates

Elastic Beanstalk can automatically apply OS patches, runtime updates, and web server fixes during a maintenance window you define. You control the update level: patch, minor, or major version.

Pricing

Elastic Beanstalk itself is completely free. You pay only for the underlying AWS resources — EC2, ELB, Auto Scaling, RDS, S3.

💡 Exam tip: "No additional charge for Elastic Beanstalk" appears directly in exam answer choices. Know it cold.

Quick-Reference — Everything on One Page

Core facts

PaaS — not serverless, not IaaS
Uses EC2, ELB, Auto Scaling, S3, optionally RDS
No charge for Elastic Beanstalk — pay only for underlying resources
Application versions stored in S3
Server logs: S3 or CloudWatch Logs
Terminated environments rebuildable within 6 weeks
Version limits managed with lifecycle policy
Config files in .ebextensions — YAML/JSON with .config extension

Deployment policies

All at once → fastest, downtime, dev/test only
Rolling → no downtime, reduced capacity, no extra cost
Rolling with batch → no downtime, full capacity, small extra cost
Immutable → no downtime, full capacity, highest cost, fastest rollback
Traffic splitting → canary, auto rollback on failure

IAM roles

Service role → Elastic Beanstalk manages AWS resources
Instance profile → EC2 instances access AWS services at runtime

Database rule

Never put production RDS inside Elastic Beanstalk
Internal RDS is deleted when environment is terminated

Environment tiers

Web server tier → HTTP/HTTPS requests
Worker tier → SQS background jobs

10 Exam-Style Practice Questions

Test your understanding before exam day. These questions are written in the same scenario-based format as the real SAA-C03, DVA-C02, and DOP-C02 exams.

Question 1

A company is running a web application on Elastic Beanstalk in a load-balanced environment. They need to deploy a new version with zero downtime and zero capacity reduction. The team also requires the ability to roll back instantly if the new version causes issues. Which deployment policy should they use?

A. Rolling
B. Rolling with additional batch
C. All at once
D. Immutable

Show answer

Answer: D — Immutable

The immutable policy deploys to a brand new set of instances. If health checks fail, new instances are simply terminated — old instances were never touched. This gives zero downtime, zero capacity reduction, and the fastest possible rollback. Rolling with additional batch (B) maintains full capacity but rollback is slow, requiring another full rolling deployment.

Question 2

A developer uploads a new application version to Elastic Beanstalk but the deployment fails with an error stating the application version limit has been reached. What is the most operationally efficient solution?

A. Delete old application versions manually from the S3 bucket
B. Create a new Elastic Beanstalk application for each new version
C. Configure an application version lifecycle policy to automatically delete old versions
D. Increase the default application version limit by contacting AWS Support

Show answer

Answer: C — Application version lifecycle policy

The lifecycle policy automatically deletes old versions based on age or count. Manually deleting from S3 (A) does not remove the version record in Elastic Beanstalk. There is no way to increase the version limit (D). Creating a new application per version (B) defeats the purpose of versioning.

Question 3

A company runs a production web application on Elastic Beanstalk with an RDS database provisioned inside the environment. A developer accidentally terminates the environment. What happens to the database?

A. The database is automatically backed up to S3 before deletion
B. The database is moved to a stopped state and can be restarted
C. The database is permanently deleted along with all its data
D. The database is decoupled and continues running independently

Show answer

Answer: C — The database is permanently deleted

When RDS is provisioned inside an Elastic Beanstalk environment, it is tied to the environment's lifecycle. Terminating the environment terminates the database. This is why production databases should always be provisioned externally and connected via environment properties.

Question 4

A team wants to test a new version of their application with 10% of real production traffic before rolling it out fully. They need automatic rollback if the new version generates errors. Which deployment policy meets these requirements?

A. Immutable
B. Rolling
C. Traffic splitting
D. Rolling with additional batch

Show answer

Answer: C — Traffic splitting

Traffic splitting is Elastic Beanstalk's canary deployment policy. You define the traffic percentage going to the new version, and Elastic Beanstalk automatically rolls back if health checks fail. This is the only policy designed for testing with a subset of real production traffic.

Question 5

A solutions architect needs to install a custom package on every EC2 instance launched by Elastic Beanstalk during environment creation. What is the correct approach?

A. Create a custom AMI with the package pre-installed
B. Add a configuration file in the .ebextensions folder with a .config extension
C. Use AWS Systems Manager Run Command after each instance launches
D. Modify the Elastic Beanstalk platform directly via the AWS console

Show answer

Answer: B — .ebextensions configuration file

Configuration files in .ebextensions with a .config extension are executed automatically during environment creation and updates. This is the standard Elastic Beanstalk-native mechanism for customizing environments at deployment time.

Question 6

A DevOps engineer notices that EC2 instances in an Elastic Beanstalk environment are flagged as unhealthy, but the standard health dashboard does not show enough detail to identify the root cause. Which feature should the engineer enable?

A. AWS CloudTrail logging
B. Amazon CloudWatch detailed monitoring
C. Elastic Beanstalk enhanced health reporting
D. AWS X-Ray tracing

Show answer

Answer: C — Enhanced health reporting

Enhanced health reporting provides per-instance health breakdowns, HTTP status code distributions, and root cause analysis specifically for Elastic Beanstalk environments. CloudWatch detailed monitoring (B) provides EC2 metrics but not Beanstalk-specific health context. X-Ray (D) is for application request tracing, not environment health.

Question 7

A company's Elastic Beanstalk environment runs a web application that processes user uploads. Heavy uploads are causing HTTP request timeouts. The team wants to offload the processing without significantly changing the web application. What is the recommended architecture?

A. Increase the EC2 instance size in the web server environment
B. Enable auto scaling with a lower CPU threshold
C. Create a worker environment connected via an SQS queue
D. Deploy the application using the immutable deployment policy

Show answer

Answer: C — Worker environment + SQS queue

The worker tier is designed for long-running background tasks that should not block HTTP responses. The web application sends a message to SQS, the worker environment picks it up and processes the upload asynchronously. The user gets an immediate HTTP response rather than a timeout.

Question 8

A developer receives the error: "The instance profile aws-elasticbeanstalk-ec2-role associated with the environment does not exist." What are two possible causes? (Select TWO)

A. The developer selected the wrong platform for the application
B. The IAM user does not have permission to create IAM roles
C. The instance profile exists but has insufficient permissions for Elastic Beanstalk
D. The Elastic Beanstalk service is not available in the selected region
E. The application version points to an invalid S3 object

Show answer

Answer: B and C

The instance profile is created automatically — but only if the IAM user has permission to create roles (B). If the profile exists but has outdated or insufficient policies, the same error appears (C). Wrong platform (A), regional availability (D), and S3 object issues (E) produce completely different error messages.

Question 9

A company wants Elastic Beanstalk to automatically apply OS and runtime patches without manual intervention, but only during off-peak hours. Which feature should they configure?

A. AWS Systems Manager Patch Manager
B. Elastic Beanstalk managed platform updates with a maintenance window
C. AWS Config auto-remediation rules
D. EC2 Image Builder pipeline

Show answer

Answer: B — Managed platform updates

Elastic Beanstalk's managed platform updates feature automatically applies OS, runtime, and platform patches during a maintenance window you define. This is the native Elastic Beanstalk solution for automated patching without manual intervention.

Question 10

A team accidentally terminated an Elastic Beanstalk environment. How long do they have to rebuild the environment with the same name, ID, and configuration?

A. 24 hours
B. 7 days
C. 30 days
D. 6 weeks

Show answer

Answer: D — 6 weeks

Elastic Beanstalk retains the metadata of terminated environments for six weeks, during which you can rebuild with the same name, ID, and configuration. After six weeks, this is no longer possible. This specific duration appears in exam questions precisely because candidates rarely remember the exact window.

Ready to Pass Your AWS Exam?

AWS Elastic Beanstalk is a high-frequency exam topic precisely because it sits at the intersection of deployment, infrastructure, security, and cost — all areas AWS loves to test in scenario format. The candidates who struggle with it aren't those who don't know what Elastic Beanstalk is. They're the ones who can't distinguish between deployment policies under pressure, or who forget that terminating an environment destroys an internal RDS instance.

You now have the full picture — concepts, deployment policies, database best practices, monitoring, security, and 10 exam-style questions to validate your understanding.

The next step is practice. Reading a cheat sheet builds recognition. Answering questions under exam conditions builds the recall and decision speed you actually need on exam day.

Practice AWS Elastic Beanstalk questions on Kwizeo → 1,000+ exam-style questions. Personalized progression. 85% first-attempt pass rate. Free to start.

Continue your AWS certification prep:

AWS Certification Path (2026): The Complete Roadmap →
[AWS Cloud Practitioner Study Guide →]
How to Pass the AWS SAA-C03 in 6 Weeks (Real Study Plan) →
Practice AWS Certification Questions on Kwizeo →