Skip to content
academia.sh
tr
Log in

Course Intermediate

Infrastructure as Code

Published Updated

By the end of this course

Start course

01

Fundamental Concepts

What tying infrastructure to code buys: tying reproducibility and traceability to a number, the difference between a desired-state declaration and a step list, the cost and gain of a rebuild versus an in-place change, the separation between the provisioning layer and the configuration management layer, and detecting a manual change as drift.

  1. 01 What Is Infrastructure as Code The same staging environment is set up twice — once by hand from a prose request, once from a record — and the two setups are compared item by item. For a quarter's worth of changes, how many times the question of who, when, and what changed gets answered, how many items fall outside the record's scope, and the cost of tying to a record in lines and extra steps are counted.
  2. 02 Declarative and Imperative Approaches The same nine-item target is written in two forms — a four-line desired-state definition and a nine-line step list — and run so that the third step fails. The items that reach the target after partial failure, the no-op writes and errors produced on a rerun, and the lines written when the target changes are counted.
  3. 03 Immutable Infrastructure A twelve-machine fleet is updated two ways over eight periods: an in-place patch and a rebuild from an image. The same event sequence is replayed on both paths; the number of servers that diverge from one another, the update duration, the rollback round count, the local state and connections a rebuild cannot carry across, and the case where a rebuild gains nothing are counted.
  4. 04 Provisioning and Configuration Management An environment's thirty-four items are split into two layers — the provisioning layer that creates the resource and the configuration layer that sets up the inside of the resource — and where the boundary is drawn gets counted. Overlapping items, the gap that falls into neither layer, which layer wins on a conflicting value, the drift window after reprovisioning, and the cost of three separate boundary lines are measured.
  5. 05 Drift A drift detector is written: the record is read, the actual state is read from disk, the difference is worked out item by item, and each difference's source is separated. The drift accumulated over a thirty-day period, the detection delay by scan frequency, the drift that never closes because it falls outside the record's scope, and the case where a rollback breaks something that works are counted.

02

Declarative Provisioning

Writing and applying the desired infrastructure: the configuration language's block, expression, and type structures; providers and resources that connect to the target system; data sources that read existing infrastructure; parameterization with variables, locals, and outputs; implicit and explicit dependency ordering; count- and set-based iteration; the plan workflow that shows a change in advance; and bringing an existing resource under management.

  1. 01 Configuration Language We define our own small configuration language and write its parser; the declaration, expression, and type structures the language carries are counted separately. It measures how many of eleven defects in a record without type declarations show up only at apply, how many get caught at parse time once types are added, and how line count and read hops move in opposite directions across three writings of the same target.
  2. 02 Providers and Resources The provider is modeled as a create-read-update-delete interface, and five resource types implement it; the field the record writes and the field that actually stands on the target are counted. It measures how many items in a change set the plan predicts, which fields force a resource to be recreated, and how many fields drift with the record completely unchanged when the provider version changes.
  3. 03 Data Sources It counts the cost of connecting to infrastructure standing outside the record by reading: how many data sources, how many reads a day, how long they take, and how many resources get recomputed versus recreated when a value they read changes. It measures how the drift scan stays limited to the items the record manages, and why a change outside the record never shows up in that scan.
  4. 04 Variables, Locals, and Outputs The same definition is applied to three environments and parameterization's balance sheet is counted: how many values actually vary by environment, how many are written the same in every environment, how many variables never get used at all. As the input surface grows, the odds of giving a wrong value are measured by how many mistakes validation catches versus misses, and the dependencies outputs create in other definitions are counted.
  5. 05 Dependencies and Lifecycle A dependency graph is extracted from the record and a topological order is resolved: how many edges are implicit, how many exist only through an explicit declaration, and how many races a requirement the record never sees produces. Once lifecycle rules are added, the plan's item count, apply's step count, and downtime in seconds are counted separately.
  6. 06 Iteration Constructs The same ten resources are written in three record forms: ten blocks by hand, count-based iteration, set-based iteration. Line count, the cost of an exception, and address stability are counted; it measures that the count-based form produces a six-item plan when a subregion is removed from the middle, and that five shifted addresses correspond to thirty-five missed meter-reading batches on the measurement network.
  7. 07 Plan and Apply Workflow A planner is written that compares the record against state and produces an add, update, recreate, or delete decision item by item, and then the plan itself is measured: how many items are not in the plan but happen at apply, how many are in the plan but do not happen, how many items marked for recreation actually get recreated, and how many lines and minutes it takes to review the plan.
  8. 08 Resource Modification and Import Seven out-of-record resources are brought under management and import's cost is counted: how many fields get hand-matched per item, how many fields stay out of the record, how many needless changes the first plan after import shows. Resource modification's downtime and the fields lost to recreation under partial import are measured.

03

State and Modules

Where the record stands and how it is split: why the state file is needed and what it holds, remote state and locking preventing team collisions, splitting large infrastructure with state splitting, workspaces for multiple instances of the same definition, module authoring with its input, output and version, shared module registries, and the visibility of sensitive values in state and output.

  1. 01 State File Where the record ties to reality: the read cost of mapping without a state file and the items that can never be mapped, the information the state keeps per item, the distinction between a deleted resource and a resource the record does not cover, and the cost of losing state.
  2. 02 Remote State and Locking Two applies writing the same state at the same time: the lost write and the out-of-record resource without a lock, the waiting rounds a lock produces, the queue that lock hold time creates, the stale lock a process leaves behind when it dies without releasing it, and the coverage gap between a local file and a remote store.
  3. 03 State Splitting The plan duration and blast radius of infrastructure growing in a single state, the same measurements in split form, the count of cross-part dependencies that is the cost of splitting, the difference between reading an output and querying a data source, and how many parts reapply when one part changes.
  4. 04 Workspaces and Environments Two setups for three environments: a single definition plus workspace versus separate directories, the count of environment-specific differences, the number of signals that say which environment you are in and applying to the wrong one, and how many environments change together when the definition changes, along with the divergence.
  5. 05 Module Authoring The same record, written separately at three collection points, is extracted into a single module; input surface, line gain and the cost of flexibility growing across six versions are counted. The four items the module's author never saw are also measured.
  6. 06 Module Registries Three modules pulled from a shared module registry, nine definitions and nine releases run a ten-week period in two setups; the version-pinned and unpinned setups are compared by unexpected change, broken definitions and fix-line count. The cost of pinning itself is also counted.
  7. 07 Sensitive Values A fictional password is passed through a definition, and a trace scanner counts how many copies it leaves at seven trace points; then fields are marked sensitive and the scan runs again. The points marking closes and cannot close, the residue left after rotation, and exposure are each measured separately.

04

Validation and Configuration Management

Testing an infrastructure change before it is applied: format and validation checks, policy scanning that catches rule violations early, unit, contract, and end-to-end infrastructure testing, estimating a change's effect on the budget, agent-based and agentless configuration management models, golden server image production, and integrating an approved automated apply flow into a pipeline.

  1. 01 Format and Validation Checks Testing the infrastructure record before it is applied: actually running format, syntax, and type/reference checks over configuration definition files, measuring what each check catches, catches alone, and misses across sixteen known defects, counting run cost in files read and comparisons, and naming the defect class static checking cannot see.
  2. 02 Policy and Compliance Scanning Running externally sourced rules over the infrastructure record: the same policy set run once over the definition text and once over the resolved plan, comparing the two scans' caught, missed, and false-alarm counts, how computed values escape the definition scan, the trade-off between earliness and accuracy, and counting the violations an exemption record drops from the report.
  3. 03 Infrastructure Testing Validating an infrastructure change at three levels: running unit, contract, and end-to-end validation over the same set of fifteen defects, measuring what each level catches, catches alone, its duration, the resources it creates, and its cost in fictional units, naming the common gap all three levels miss, and counting the leftover resources and leaked cost left behind by test resources that are never cleaned up.
  4. 04 Cost Estimation Counting an infrastructure change's effect on the budget before it is applied: producing a monthly estimate per change from the plan diff, separating fixed-unit-price items from usage-dependent items, where the error comes from and how it is distributed when compared against what actually happens, how overall accuracy hides the deviation in individual changes, and how many changes a threshold rule holds for nothing versus how many costly changes it lets through.
  5. 05 Configuration Management Tools Agent-based and agentless configuration management are measured as kinds: the same thirty-four-item setting set is rolled out to fifty machines under two models; the rollout's rounds and duration, the number of machines that diverge from the record on partial failure, how many minutes drift lives, and the model's own cost — the agent process, the connection surface, authorized identity — are all counted.
  6. 06 Server Image Building Configuring at every boot is measured side by side with the golden image: boot duration, the number of outbound calls at boot, and how many machines fail to boot when a dependency drops are counted; how many images get rebaked when a security fix lands, how many days the rollout window takes, and how many components the image's content record misses are measured.
  7. 07 Pipeline Integration An infrastructure change is run through a pipeline: the plan stage and the apply stage are separated, and approval stands in between. The plan the approver approves without reading, the reality that goes stale between plan and apply, the breadth of the pipeline's apply permission, and a manual change being silently reverted, colliding with, or never seen by the pipeline's next run are all counted.

Final exam

Infrastructure as Code — Final Exam

In preparation

This course's question bank is not complete yet. The exam opens here automatically once enough questions are added.

Start typing to search.

↑↓ ↵ Esc navigate · open · close