The Labs / Cloud

CloudWorking~5h

Deploy infrastructure that can undo itself

A small but real cloud stack (a VM or container service, a storage bucket, and networking) defined entirely in Terraform, with state stored remotely and versioned. You deploy it, make a breaking change, and then prove you can revert to the last-known-good state using the plan/apply workflow instead of clicking around a console.

Start this build

What it proves

The line you can defend in an interview.

Résumé line

Defined and deployed cloud infrastructure as code in Terraform (remote state, plan/apply workflow) and proved a controlled rollback to a prior state after a bad change, with before/after plan output as evidence.

Can define real infrastructure declaratively instead of hand-clicking a console
Understands state as the source of truth, not the live resources
Treats deploys as reversible operations, not one-way doors
Can produce evidence (plan diffs, logs) that a change was safe

The brief

What you build, step by step.

01Define at least 3 real resources in Terraform (e.g. compute instance, storage bucket, network/security group) with variables for environment-specific values.
02Configure a remote state backend (not local .tfstate) so state is shared and lockable.
03Run terraform plan and apply to stand up the stack for real; capture the applied state as v1.
04Make a breaking change (e.g. a config that removes required egress or misconfigures a resource), apply it, and observe the failure.
05Roll back to v1 using version-controlled config (git revert + apply, or a saved plan) — not manual console edits — and verify the stack matches v1 exactly.
06Document the diff between the broken and rolled-back plans as proof the rollback was clean.

The proof

It’s done when these pass.

terraform apply succeeds and stands up all defined resources on the real provider

checked output

The breaking change is applied and its failure mode is captured (error output or health-check failure)

checked output

terraform plan after rollback shows zero pending changes against the v1 config

automated test

A written rollback log shows the before/broken/after plan diffs in order

artifact

Stack

Terraforma cloud provider (AWS/GCP/Azure free tier)remote state backendgit

Sage Method

frame → map → decide → prove

You keep

A Terraform module + remote state + a rollback log with before/broken/after plan diffs

← Back to all builds

Deploy infrastructure that can undo itself

The line you can defend in an interview.

Résumé line

Can define real infrastructure declaratively instead of hand-clicking a console

Understands state as the source of truth, not the live resources

Treats deploys as reversible operations, not one-way doors

Can produce evidence (plan diffs, logs) that a change was safe

What you build, step by step.

01Define at least 3 real resources in Terraform (e.g. compute instance, storage bucket, network/security group) with variables for environment-specific values.

02Configure a remote state backend (not local .tfstate) so state is shared and lockable.

03Run terraform plan and apply to stand up the stack for real; capture the applied state as v1.

04Make a breaking change (e.g. a config that removes required egress or misconfigures a resource), apply it, and observe the failure.

05Roll back to v1 using version-controlled config (git revert + apply, or a saved plan) — not manual console edits — and verify the stack matches v1 exactly.

06Document the diff between the broken and rolled-back plans as proof the rollback was clean.

It’s done when these pass.

terraform apply succeeds and stands up all defined resources on the real provider

checked output

The breaking change is applied and its failure mode is captured (error output or health-check failure)

checked output

terraform plan after rollback shows zero pending changes against the v1 config

automated test

A written rollback log shows the before/broken/after plan diffs in order

artifact