# Design an infrastructure platform like Terraform Cloud: system design interview question

> Declarative cloud changes: plan accuracy, shared state, concurrent changes, and recovery after partial failure.

Source: https://sysround.com/questions/design-infrastructure-platform-like-terraform-cloud
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design an infrastructure as code platform. Users describe the cloud resources they want, then ask the service to preview and apply changes."

## What to clarify first

- Workspaces and ownership
- Traffic and read:write mix
- Cloud work and duration
- Approval and destructive changes
- Latency
- Consistency and availability
- Provider and worker failures
- Durability and retention
- External changes and secrets
- Provider support and exclusions

## Scope of a strong answer

Core requirements:

- Preview resource creates, updates, replacements, and deletes.
- Apply an approved plan in the correct resource order.
- Coordinate changes to each workspace and preserve its state.
- Recover after worker failure or a partially completed apply.

Usually out of scope:

- A new configuration language
- Custom provider code
- Transactions across workspaces
- Continuous drift repair
- Active-active regions

## What interviewers probe

### Plan contents and approval

Cloud resources can change after a preview. A valid state serial does not prove that the cloud still matches the approved plan.

### Concurrent changes

A delayed worker can still send cloud requests after its lease expires. State ownership alone cannot stop those requests.

### Incomplete changes

A cloud API can create a resource before the worker records success. The service cannot undo all resources as one transaction.

### Resource execution

Resources depend on other resources. A replacement can require a different action order from a create or delete.

## Common mistakes

- The design treats a valid state serial as proof of the current cloud state.
- The design changes approved actions after drift without new approval.
- The design assumes lease expiry stops an old worker's cloud requests.
- The design starts replacement execution before earlier provider effects reach known outcomes.
- The design retries a create after a timeout without checking its outcome.
- The design saves progress only after the entire apply succeeds.

## The bar by level

- **Senior:** Binds approval to an immutable plan and checks cloud facts before execution. Handles duplicate jobs, uncertain provider results, and durable resource progress. Distinguishes state ownership from control over cloud mutations.
- **Staff+:** Defines a takeover protocol that stops old mutations and reconciles pending effects before replacement execution. Explains external drift guarantees when providers lack conditional writes. Defines tenant isolation, quota fairness, and audited recovery.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=infrastructure-as-code-platform


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.