Deliveroo Infrastructure Interview: Terraform Debugging in an AWS Environment

The Deliveroo infrastructure interview calls for more than writing Terraform from a blank file. Official guidance: Deliveroo describes a live exercise using a supplied repository and an AWS environment that already exists. You need to understand what is broken, explain your investigation, and make changes whose effects you can verify.

That makes preparation different from memorizing resource syntax. A configuration can be valid, a plan can show no changes, and the application can still be unreachable. Your job is to connect those observations without treating any one of them as proof that the whole system works.

This article focuses on the live debugging task, with an original evidence packet you can work through aloud.

What Deliveroo's official guide establishes

The infrastructure interview guide describes a 60-minute coding session, with roughly 45 minutes of technical work. Candidates receive temporary access and a Terraform repository with supporting tooling; base infrastructure is deployed beforehand. The work includes fixing issues and making additions.

Its preparation list includes tfenv, an IDE, a Bash-compatible shell, Git, kubectl, and the AWS CLI. It explicitly requires disabling LLM tooling, including Copilot, and preparing to share your screen. Confirm versions, access arrangements, and permitted reference materials against your invitation.

The guide also describes an infrastructure-focused HackerRank screen and separate architecture and behavioral conversations. Role-specific variations are possible. The advice below targets the repository exercise rather than reconstructing every stage.

Evidence boundary: we did not verify two independent infrastructure candidate reports from the same current hiring cycle. The scenario and follow-up questions here are editorial practice material, not leaked tasks, candidate-reported questions, or a guarantee of what your interviewer will ask.

Read the environment before changing it

Begin with the repository's entry points. Read the README, version constraints, provider configuration, variable files, and Makefile before executing a target. A command named setup might initialize dependencies, create infrastructure, or perform several operations. Its name alone does not establish its effect.

Next identify the environment you are observing: AWS account, region, Terraform working directory, backend, and workspace. In the actual exercise, use only the access and targets supplied for that session. Explain that you are checking context so a correct diagnosis is not applied to the wrong environment.

Keep three questions separate. What does the configuration request? Which remote objects does Terraform manage? What is the application doing now? A plan helps compare infrastructure configuration and observed resource properties. It does not replace a request through the application path.

Before choosing a command, state the uncertainty it should reduce. “I will check target health to distinguish registration problems from failed health checks” is more informative than reading out a list of AWS commands. If the output contradicts your hypothesis, update the hypothesis rather than collecting more evidence for the original guess.

For local preparation, create a small directory containing a configuration fragment and written observations. You can rehearse diagnosis without renting a cloud environment. Label simulated observations clearly so you never confuse reasoning practice with deployment validation.

Work through a broken health-check scenario

Original exercise: an Application Load Balancer forwards requests to an EC2 service on TCP port 8080. The target group's HTTP health check uses the traffic port and /health. A recent infrastructure change was applied, but health checks time out. The expected access boundary is application traffic from the load balancer's security group only.

The following packet is constructed for teaching. It is not output from Deliveroo's environment or a real AWS test performed for this article.

Observation	What it tells you	What it does not prove
Target health reports Target.Timeout	The health check did not complete within its timeout.	That the security group is necessarily the cause.
Application listens on 0.0.0.0:8080	The process accepts connections on the instance's interfaces at that port.	That the load balancer can reach it.
Local request to /health returns HTTP 200	That local request succeeds at observation time.	That routing, network controls, or every application endpoint works.
Target registration uses port 8080	The registered target port matches the application's port.	That the target belongs to the intended instance and network.
Application security group allows TCP 80 from the ALB group	A rule exists for the wrong port in this scenario.	That changing this rule resolves every possible fault.
Terraform reports no changes	The inspected configuration and managed objects agree for that run.	That their agreed configuration is operationally correct.

Also assume the packet confirms that the ALB's outbound rule permits TCP 8080 to the application group, the relevant subnet routes are present, and network ACLs permit the required request and return traffic. These are explicit exercise assumptions, not checks you should skip in a real investigation.

Documented behavior: AWS explains that the load balancer and target security groups must permit communication on the relevant target and health-check ports. Its security-group guidance is the basis for evaluating the mismatch.

Your leading hypothesis is now specific: the application group's ingress rule admits port 80 while the target and health check require 8080. Say why that explanation fits the packet, then identify the next evidence you would check before editing: the security group must actually be attached to the intended target.

Make the smallest justified Terraform repair

Here is the corrected rule fragment. The two variables identify existing security groups; this fragment does not create an entire application or load balancer.

resource "aws_vpc_security_group_ingress_rule" "app_from_alb" {
  security_group_id            = var.app_sg_id
  referenced_security_group_id = var.alb_sg_id
  ip_protocol                  = "tcp"
  from_port                    = 8080
  to_port                      = 8080
}

For the exercise, the original values of from_port and to_port were both 80. The proposed repair changes the allowed port while preserving the source group. Opening every port or admitting the public internet would weaken the required access boundary and obscure which mismatch you fixed.

Before applying anything in a supplied environment, inspect the generated plan. Verify the exact rule, source, target group identifier, and port range. Check whether the provider proposes an update or replacement and what interruption that entails. A short summary such as “one change” is insufficient when the resource details show a different security boundary.

The following is a simulated review summary, deliberately not presented as literal Terraform output:

Resource under review: app_from_alb
Before: ALB security group -> application security group, TCP 80
After:  ALB security group -> application security group, TCP 8080
Expected scope: this ingress rule only
Unexpected: public CIDR, unrelated instance replacement, new database

If the plan includes unrelated replacements, pause that change and find the source of the difference. Possible causes include incorrect variables, a different workspace, or a dependency change. Do not hide unrelated work with targeting simply to produce an attractive summary.

The corrected local fixture passed Terraform 1.16.2 validation with the AWS provider and no diagnostics. This was a static configuration check; we did not deploy it to AWS. HashiCorp's validation documentation explains that validation checks configuration consistency, not remote service behavior. A valid ingress rule can still allow the wrong port.

Verify recovery instead of stopping at apply

Define the evidence you expect before making the change. In this case, you want the applied ingress rule to match the intended source and port, target health to recover, and an application request through the load balancer to succeed. You also want the application to remain inaccessible through paths outside the agreed boundary.

AWS documents health-check thresholds and reason codes. Recovery is not necessarily immediate after a rule update. Observe the target's progression over the configured checks rather than interpreting one early unhealthy result as proof that the repair failed.

If the reason changes from timeout to response-code mismatch, you have new evidence. Connectivity may have improved, but the health-check path, matcher, or application behavior needs investigation. Do not keep widening network access to solve a response that the application is already returning.

If health becomes green but the user request still fails, compare the user path with the health path: listener rule, hostname, URL, authentication, and application dependencies. A shallow /health response can pass while a database-backed endpoint fails. That distinction is often the most useful part of your explanation.

Finish with a fresh plan to inspect convergence and a concise account of the observed service behavior. Keep those two conclusions separate: infrastructure matches the configuration, and the tested request works. Neither establishes that every future request will succeed.

Handle a follow-up requirement without losing the diagnosis

Original extension: the interviewer now asks you to add a second application target. Begin by clarifying whether it runs the same process and port, belongs to the same group, and should receive production traffic immediately. Do not assume that cloning an instance is the whole requirement.

Explain the dependency chain: the service must start, the instance must have the intended network controls, the target must be registered correctly, and health checks must establish readiness. Ask what should happen if only the new target fails. That question leads naturally to rollout scope and observation, rather than an unnecessary platform redesign.

Preserve the evidence from the first repair. If a later step fails, distinguish failure introduced by the extension from the original connectivity issue. A short working note with the initial symptom, changed rule, successful check, and new symptom is more useful than relying on memory.

For recovery planning, explain that reverting a commit is not automatically a complete infrastructure rollback. You would review a new plan and the current environment before making another change. In this exercise, returning to port 80 would restore the original defect, so it is not a sensible definition of service recovery.

Practice explaining your next check

Practice question	How to use it for this exercise
Explain OS and networking basics	Trace the local process, TCP connection, and load-balanced request separately.
Design Safe Configuration and Deployment for Hundreds of Services	Explain how a reviewed network change reaches the correct environment.
Design a CI/CD pipeline with scheduler	Separate validation, plan review, execution, and observable outcomes.
Present Your Infrastructure and Platform Experience	Bring one real infrastructure incident and identify your contribution.
Resolve Team Disagreement During a Cross-Functional Performance Fix	Explain how evidence changes a disputed diagnosis.

In rehearsal, have a partner reveal one observation at a time. Before seeing the next observation, name your leading hypothesis, your next check, and the result that would change your mind. This prevents the answer from becoming a memorized command sequence.

If you run out of time, give a precise handoff: what you checked, what you ruled out, what changed, and which verification remains. “I think it works” is weaker than “the rule now matches 8080, but I have not yet observed healthy targets or completed an end-to-end request.”

Use the Terraform preparation guide to repair any gaps in plan and state reasoning, then repeat this packet without notes. The aim is a defensible investigation you can adapt when the next piece of evidence surprises you.

Sources and Further Reading

• Deliveroo infrastructure engineering interview guide: official exercise, tools, and LLM restriction.
• Terraform validate command: scope of local configuration validation.
• Application Load Balancer security groups: listener, target, and health-check connectivity.
• Application Load Balancer target health checks: status, thresholds, and reason codes.

Sources checked September 10, 2026. The troubleshooting packet is an original simulation; no live AWS deployment is claimed.