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

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.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

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

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

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 ask about

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 (L5/E5): 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 (L6+/E6+): 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.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design an infrastructure platform like Terraform Cloud
Reported date not specified
Source snapshot: Nov 12, 2026
View source

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

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

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 ask about

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 (L5/E5)

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 (L6+/E6+)

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.