Build fluency in the vocabulary of keeping live infrastructure consistent with its code definition.
0 / 5 completed
1 / 5
At standup, a dev mentions noticing a production resource's actual configuration no longer matches what's defined in the team's infrastructure-as-code files, because someone changed it manually through the cloud console. What is this discrepancy called?
Infrastructure drift occurs when a resource's actual live configuration no longer matches what's defined in the team's infrastructure-as-code files, typically because someone made a manual, out-of-band change directly through a cloud console or CLI rather than through the code. A planned change fully reflected in the code isn't drift, since the code and reality stay in sync. Drift undermines the core promise of infrastructure as code, which is that the code should be the single accurate source of truth for what's actually deployed.
2 / 5
During a design review, the team wants to regularly compare the actual live state of their infrastructure against what's defined in code, flagging any discrepancy automatically. Which capability supports this?
Automated drift detection regularly compares live infrastructure against the definitions in code, automatically flagging a discrepancy rather than requiring someone to manually check every resource by hand. Manually comparing infrastructure doesn't scale well and is easy to skip or fall behind on. This automated detection surfaces drift promptly, before it accumulates into a larger, harder-to-reconcile gap between code and reality.
3 / 5
In a code review, a dev notices the team's process explicitly disallows any manual change through the cloud console, requiring every change to go through the infrastructure-as-code pipeline instead. What does this represent?
Enforcing infrastructure as code as the sole change path requires every infrastructure change to go through the code and its associated pipeline, rather than allowing a manual console change to bypass that process. Allowing manual changes freely alongside the pipeline is exactly what causes drift to accumulate over time in the first place. This enforcement, often backed by restricted console permissions, is a key preventive practice rather than just detecting drift after the fact.
4 / 5
An incident report shows a manual emergency fix made directly in the cloud console during an incident was never reflected back into the infrastructure-as-code files, and it was silently reverted during the next automated deployment. What practice would prevent this?
Reflecting an emergency manual change back into the infrastructure-as-code files promptly after the incident ensures the next automated deployment doesn't silently revert a fix that's still needed. Assuming an automated deployment will preserve an undocumented change ignores that the code, not the live state, is what the deployment process actually applies. This follow-up step is a well-known necessary practice whenever an emergency requires bypassing the normal code-based change process temporarily.
5 / 5
During a PR review, a teammate asks why the team enforces infrastructure as code as the sole change path instead of allowing a trusted engineer to make a quick manual change through the console when convenient. What is the reasoning?
Allowing a manual change outside the code pipeline, even from a trusted, well-intentioned engineer, creates a discrepancy between the code and the actual live state, which is exactly what infrastructure drift is. Enforcing a single code-based change path keeps the code reliably accurate as the true source of what's deployed. The tradeoff is a small loss of convenience for a genuinely urgent, one-off situation, which is why an emergency change process typically requires promptly reflecting any exception back into the code afterward.