Zero-downtime deployment pattern in Terraform - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a new AWS EC2 instance resource.

Terraform

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "[1]"
}

Drag options to blanks, or click blank then click option'

Ac5.xlarge

Bt2.micro

Cm5.large

Dt3.micro

Attempts:

3 left

💡 Hint

Common Mistakes

Using an instance type that is too large for simple applications.

Using an instance type that is deprecated or unavailable in the region.

The 't3.micro' instance type is a common choice for lightweight applications and supports burstable CPU performance.

2fill in blank

medium

Complete the code to create an AWS Elastic Load Balancer (ELB) resource.

Terraform

resource "aws_elb" "app_elb" {
  name               = "app-elb"
  availability_zones = ["us-west-2a", "us-west-2b"]
  listener {
    instance_port     = 80
    instance_protocol = "HTTP"
    lb_port           = [1]
    lb_protocol       = "HTTP"
  }
}

Drag options to blanks, or click blank then click option'

A443

B8080

C80

D22

Attempts:

3 left

💡 Hint

Common Mistakes

Using port 443 without configuring HTTPS.

Using a non-standard port that clients won't connect to.

The load balancer port should be 80 to accept HTTP traffic on the standard web port.

3fill in blank

hard

Fix the error in the code to properly attach instances to the ELB.

Terraform

resource "aws_elb_attachment" "app_attachment" {
  elb      = aws_elb.app_elb.name
  instance = [1]
}

Drag options to blanks, or click blank then click option'

Aaws_instance.app_server.public_dns

Baws_instance.app_server.id

Caws_instance.app_server.private_ip

Daws_instance.app_server.name

Attempts:

3 left

💡 Hint

Common Mistakes

Using the instance name or IP instead of the ID.

Using an attribute that does not uniquely identify the instance.

The ELB attachment requires the instance ID, which uniquely identifies the EC2 instance.

4fill in blank

hard

Fill both blanks to create a lifecycle rule that prevents Terraform from destroying the old instance immediately.

Terraform

resource "aws_instance" "old_app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  lifecycle {
    [1] = true
    [2]  = true
  }
}

Drag options to blanks, or click blank then click option'

Acreate_before_destroy

Bprevent_destroy

Cignore_changes

Dreplace_triggered_by

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing 'ignore_changes' with lifecycle control.

Not using 'create_before_destroy' causing downtime.

The 'create_before_destroy' ensures the new instance is created before the old one is destroyed, and 'prevent_destroy' protects the resource from accidental deletion.

5fill in blank

hard

Fill all three blanks to define a Terraform output that shows the ELB DNS name after deployment.

Terraform

output "elb_dns_name" {
  value = [1].[2].[3]
}

Drag options to blanks, or click blank then click option'

Aaws_elb

Bapp_elb

Cdns_name

Dname

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'name' instead of 'dns_name' for the ELB attribute.

Mixing resource names or types incorrectly.

The output references the ELB resource 'aws_elb.app_elb' and accesses its 'dns_name' attribute to show the load balancer's DNS.

Practice

1. What is the main goal of a zero-downtime deployment in Terraform?

easy

A. Manually switch traffic after deployment

B. Update applications without stopping them or causing downtime

C. Deploy new versions only during off-hours

D. Stop all running tasks before updating

Solution

1. Step 1: Understand zero-downtime deployment purpose

   Zero-downtime deployment means updating apps without stopping them or causing service interruptions.

2. Step 2: Compare options with this goal

   Only Update applications without stopping them or causing downtime describes updating without stopping or downtime, matching the goal.

3. Final Answer:

   Update applications without stopping them or causing downtime -> Option B

4. Quick Check:

   Zero-downtime = no stopping, no downtime [OK]

Hint: Zero downtime means no stopping or service interruption [OK]

Common Mistakes:

• Thinking deployment must stop all tasks
• Assuming manual traffic switch is required
• Believing updates only happen off-hours

2. Which Terraform setting helps control how many tasks run during an update for zero-downtime?

easy

A. min_healthy_percent

B. max_percent

C. desired_count

D. task_definition

Solution

1. Step 1: Identify settings related to task counts during update

   Terraform uses settings like max_percent and min_healthy_percent to control task numbers during deployment.

2. Step 2: Understand min_healthy_percent role

   min_healthy_percent ensures a minimum percentage of tasks stay healthy and running during updates, preventing downtime.

3. Final Answer:

   min_healthy_percent -> Option A

4. Quick Check:

   min_healthy_percent controls running tasks during update [OK]

Hint: min_healthy_percent keeps tasks running during updates [OK]

Common Mistakes:

• Confusing max_percent with min_healthy_percent
• Using desired_count which sets total tasks, not update behavior
• Selecting task_definition which defines task specs

3. Given this Terraform snippet for ECS service update:

deployment_minimum_healthy_percent = 75
deployment_maximum_percent = 200

What does this configuration ensure during deployment?

medium

A. Exactly 75 tasks run; maximum 200 tasks allowed

B. No new tasks start until all old tasks stop

C. Deployment stops 25% of tasks before starting new ones

D. At least 75% of tasks stay running; up to 200% tasks can run temporarily

Solution

1. Step 1: Interpret deployment_minimum_healthy_percent

   This means at least 75% of current tasks must stay healthy and running during deployment.

2. Step 2: Interpret deployment_maximum_percent

   This allows up to 200% of the desired tasks to run temporarily, enabling new tasks to start before old ones stop.

3. Final Answer:

   At least 75% of tasks stay running; up to 200% tasks can run temporarily -> Option D

4. Quick Check:

   Min healthy 75%, max 200% = safe rolling update [OK]

Hint: Min healthy % keeps tasks running; max % allows extra tasks [OK]

Common Mistakes:

• Thinking percentages mean exact task counts
• Assuming deployment stops tasks before starting new ones
• Confusing min and max percentages

4. You set deployment_minimum_healthy_percent = 100 and deployment_maximum_percent = 100 in Terraform for ECS service. What issue will this cause?

medium

A. Deployment will run twice the desired tasks temporarily

B. Deployment will succeed with zero downtime

C. Deployment will fail because no new tasks can start before old ones stop

D. Deployment will ignore these settings and use defaults

Solution

1. Step 1: Analyze min and max percent both at 100%

   Min healthy 100% means all old tasks must stay running; max 100% means no extra tasks can start.

2. Step 2: Understand deployment impact

   New tasks cannot start until old ones stop, but old ones cannot stop because min healthy is 100%, causing deployment to fail.

3. Final Answer:

   Deployment will fail because no new tasks can start before old ones stop -> Option C

4. Quick Check:

   Min 100% + Max 100% blocks rolling update [OK]

Hint: Min 100% and Max 100% blocks task replacement [OK]

Common Mistakes:

• Assuming deployment will succeed without downtime
• Thinking max 100% allows extra tasks
• Ignoring min healthy effect on stopping old tasks

5. You want to deploy a new version of your app with zero downtime using Terraform ECS service. Your desired task count is 4. Which configuration best supports zero-downtime deployment?

hard

A. deployment_minimum_healthy_percent = 75deployment_maximum_percent = 125

B. deployment_minimum_healthy_percent = 100deployment_maximum_percent = 100

C. deployment_minimum_healthy_percent = 50deployment_maximum_percent = 150

D. deployment_minimum_healthy_percent = 0deployment_maximum_percent = 200

Solution

1. Step 1: Evaluate each option for zero-downtime support

   deployment_minimum_healthy_percent = 50
deployment_maximum_percent = 150 allows only 50% healthy tasks, risking downtime. deployment_minimum_healthy_percent = 100
deployment_maximum_percent = 100 blocks new tasks starting before old stop. deployment_minimum_healthy_percent = 0
deployment_maximum_percent = 200 allows zero healthy tasks, risking downtime. deployment_minimum_healthy_percent = 75
deployment_maximum_percent = 125 keeps 75% healthy and allows 125% max tasks, enabling smooth rolling update.

2. Step 2: Choose best balance for zero-downtime

   deployment_minimum_healthy_percent = 75
deployment_maximum_percent = 125 ensures enough healthy tasks remain while allowing new tasks to start before old stop, supporting zero downtime.

3. Final Answer:

   deployment_minimum_healthy_percent = 75 and deployment_maximum_percent = 125 -> Option A

4. Quick Check:

   Min healthy 75% + max 125% = safe rolling update [OK]

Hint: Min healthy ~75% and max ~125% enable zero downtime [OK]

Common Mistakes:

• Choosing min healthy too low risking downtime
• Choosing min and max both 100% blocking updates
• Allowing zero healthy tasks during deployment