Infrastructure apply fails midway. What is the state and your immediate steps?

WHAT THIS TESTS: operational maturity with infrastructure as code, specifically the ability to reason about partial state during non-atomic deployments. The interviewer cares whether you understand that complex updates can fail midway, leaving resources in an inconsistent mix of old and new configurations. They are looking for a data-driven approach to diagnosing what changed, a respect for idempotency and repeatable processes, and a structured choice between rolling forward and rolling back safely.

A GOOD ANSWER COVERS: four things in order. First, halt all automation and lock the state file to prevent concurrent modifications that could deepen the inconsistency. Second, inspect the state file and provider logs to build an exact inventory of which resources were created, updated, or destroyed before the failure and which changes were never reached. Third, classify the failure by blast radius and safety: determine whether the remaining changes can be applied idempotently without risk, or whether the partial state has compromised service health and requires a rollback. Fourth, execute a deliberate recovery path: roll forward by fixing the root cause and applying the remaining changes with a fresh plan, or roll back to the last known good version using versioned state and reproducible artifacts, validating either path with a canary before expanding scope. The answer should reflect the SRE principle that releases must be repeatable and intentional, not unique snowflakes created through manual intervention.

COMMON WRONG ANSWERS: three dangerous patterns. The first is rerunning apply blindly without inspecting state, which can compound partial state or trigger cascading failures. The second is proposing manual resource deletion through a cloud console to force recreation, which destroys repeatability and creates configuration drift. The third is assuming the infrastructure is either fully updated or fully untouched, ignoring the reality of partial state in complex dependency graphs where some resources may be live while others are stale.

LIKELY FOLLOW-UPS: how you prevent this class of failure, which invites discussion of phased rollouts, blue-green deployments, or automated canarying. An interviewer may also ask how you manage state file locking and versioning in a team environment, or how you test infrastructure changes in a staging environment that mirrors production. Another angle is how you communicate status and block dependent deployments while the environment is being stabilized.

ONE CONCRETE EXAMPLE: imagine a Terraform apply that fails after updating an auto scaling group but before replacing the launch template. The state file shows the new scaling group but the old template. Rather than rerunning apply, you inspect the dependency graph, confirm the new group is stable, then run a targeted plan that applies only the launch template change after fixing the IAM permission that caused the timeout. You validate with a five percent canary before promoting to the full fleet. If the failure had corrupted the load balancer instead, you would restore the previous known good state from remote versioned storage and redeploy using the same artifact pipeline to ensure the rollback is identical to the last healthy release.