Components & Configuration Deep Dive

The settings and mechanics that most commonly appear inside DVA-C02 scenario questions — deployment options in full, health monitoring, .ebextensions, and environment variables.

Deployment Policies — In-Environment (In-Place) Options

Blue/Green Deployment — Environment Swap (CNAME Swap)

Auto Scaling & Load Balancing Built Into an Environment

Health Monitoring

Environment health colors (see the scale at the top of the Overview tab): Green = passing, Yellow = one or more warnings (e.g. elevated latency, some instances degraded), Red = severe (majority of instances failing or application errors), Grey = insufficient data, environment is updating, or processes are suspended.

Environment Configuration & .ebextensions

.ebextensions/01_environment.config
─────────────────────────────────────
option_settings:
  aws:elasticbeanstalk:application:environment:
    NODE_ENV: production
  aws:autoscaling:asg:
    MinSize: 2
    MaxSize: 6

Resources:
  AWSEBCloudwatchAlarmHigh:
    Type: AWS::CloudWatch::Alarm
    Properties:
      MetricName: CPUUtilization
      Namespace: AWS/EC2
      Threshold: 80
      ComparisonOperator: GreaterThanThreshold

packages:
  yum:
    git: []

container_commands:
  01_migrate:
    command: "python manage.py migrate"
    leader_only: true

Environment Variables

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails. Written in the "A company needs to...", "What is the MOST appropriate solution?" style DVA-C02 actually uses.

Integrations & Architecture Example

Related Services

End-to-End Architecture Example

Best Practices & Common Exam Traps

When to Use Elastic Beanstalk

Comparison — Elastic Beanstalk vs ECS/Fargate vs Lambda

Common Exam Traps

Memory Anchors

• 5 in-place policies, 1 separate workflow: All at once, Rolling, Rolling+Batch, Immutable, Traffic Splitting live in the deployment-policy setting; Blue/Green (environment swap) does not.
• Capacity math: All at once = 0% during deploy · Rolling = reduced % · Rolling+Batch / Immutable / Traffic Splitting / Blue-Green = 100%+ maintained.
• Cost math: All at once / Rolling = no extra cost · Rolling+Batch = small temporary extra · Immutable / Traffic Splitting / Blue-Green = up to 2x temporarily.
• Worker tier = SQS, no ELB. Web server tier = ELB, no queue polling.
• Instance profile = your app's permissions. Service role = Beanstalk's own permissions.
• Decouple RDS for anything you'd be upset to lose.
• Enhanced health reporting = the only way to see HTTP status codes/latency in the health dashboard.

Hands-On Lab

Three self-contained exercises using the real EB CLI (and aws elasticbeanstalk) against eu-west-1. They turn the deployment-policy and .ebextensions theory from the other tabs into something you actually watch happen — a broken deploy under the default policy, the same break survived under Immutable, and a config file that installs a package and sets an environment variable for real. Bring your own tiny app (any of the EB-supported platforms works; examples below assume Node.js) and remember to eb terminate the environment when you're done so it doesn't keep billing.

Exercise 1 — Deploy, Watch the Health Dashboard, Then Break It (Default Policy)

1. Confirm the EB CLI is installed, then initialize the application in eu-west-1.

   eb --version
   eb init my-eb-lab-app --platform node.js --region eu-west-1

   A local .elasticbeanstalk/config.yml is created, pinned to the eu-west-1 region and the Node.js platform.
2. Create the environment with default settings (load balanced, All at once deployment policy).

   eb create eb-lab-env --region eu-west-1 --instance-type t3.micro

   After several minutes, the environment reports health Green in both the CLI output and the console health dashboard.
3. Inspect the environment health dashboard directly.

   eb status
   eb health eb-lab-env

   CLI shows Health: Green, causes list is empty, and per-instance status is all "Ok" — matches what the console Health tab renders visually.
4. Introduce a deliberate breaking change — for example, make the app listen on the wrong port or throw on startup — then redeploy without changing the deployment policy (still the default, All at once).

   # edit app.js so the server throws on boot, e.g.:
   #   throw new Error("simulated startup failure");
   
   eb deploy eb-lab-env

   The deploy reports failure; the health dashboard flips to Red/Severe across essentially the whole fleet at once, because All at once pushed the bad build to every instance simultaneously with no healthy fallback capacity.
5. Confirm what happened via events and logs before fixing it.

   eb events eb-lab-env --follow
   eb logs eb-lab-env

   Events show the failed deployment and degraded/severe health transition; the retrieved logs contain the simulated startup error on every instance.

Exercise 2 — Switch to Immutable, Break It Again, Compare

1. First redeploy the known-good version to get the environment back to Green (baseline before changing policy).

   # revert the breaking change in app.js, then:
   eb deploy eb-lab-env

   Health returns to Green — you're back to a clean baseline before introducing a second variable.
2. Add an .ebextensions config file that switches the environment's deployment policy to Immutable.

   mkdir .ebextensions
   cat > .ebextensions/01_deployment_policy.config <<'EOF'
   option_settings:
     aws:elasticbeanstalk:command:
       DeploymentPolicy: Immutable
   EOF
   
   eb deploy eb-lab-env

   The deploy succeeds and applies the configuration change; eb config eb-lab-env now shows DeploymentPolicy: Immutable instead of the default.
3. Reintroduce the exact same breaking change from Exercise 1, then deploy again.

   # reapply the same "throw on boot" change to app.js
   eb deploy eb-lab-env

   The deploy fails, but the environment health dashboard stays Green throughout — Beanstalk launched a brand-new temporary Auto Scaling group running the bad build, watched it fail health checks, and terminated it automatically without ever routing production traffic to it. The original fleet kept serving the last good version the entire time.
4. Confirm the rollback mechanics in the event stream.

   eb events eb-lab-env --follow

   Events show a new temporary environment/ASG being created, instances failing health checks, and an automatic rollback/termination of the temporary fleet — with no "environment health: Severe" event for the live environment itself.
5. Redeploy the good version one more time to leave the environment clean.

   # revert app.js again, then:
   eb deploy eb-lab-env

   Health is Green again, this time still running under the Immutable policy.

Exercise 3 — Install a Package and Set an Environment Variable via .ebextensions

1. Add a second .ebextensions config file that installs an OS package and sets an application environment variable in one go.

   cat > .ebextensions/02_packages_env.config <<'EOF'
   packages:
     yum:
       htop: []
   
   option_settings:
     aws:elasticbeanstalk:application:environment:
       LAB_FEATURE_FLAG: "enabled"
   EOF

   Two new keys exist under .ebextensions: an OS package to install via yum and a new environment variable, both scoped to this application bundle.
2. Deploy the change.

   eb deploy eb-lab-env

   Deploy succeeds; because an environment variable changed, Beanstalk performs a configuration update/instance replacement following the currently configured deployment policy (Immutable, from Exercise 2) rather than an instant in-place change.
3. Verify the package installed by SSHing into an instance.

   eb ssh eb-lab-env
   # on the instance:
   rpm -q htop
   exit

   rpm -q htop returns an installed package version instead of "package htop is not installed" — confirming the packages block ran on the instance.
4. Verify the environment variable took effect.

   eb printenv eb-lab-env

   LAB_FEATURE_FLAG = enabled appears in the printed environment variable list, matching what process.env.LAB_FEATURE_FLAG would return inside the running application.
5. Clean up so the lab stops billing.

   eb terminate eb-lab-env --region eu-west-1

   The environment, its Auto Scaling group, load balancer, and instances are torn down; the application and its stored versions in S3 remain unless you also delete the application itself.

Flashcards — 22 Cards

Click card to flip. Mark right or wrong to track score.

Practice Quiz — 12 Questions

DVA-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.