🌍 DevOps · subject

DevOps Infrastructure as Code Syllabus

Every chapter and topic of Infrastructure as Code examined in DevOps — 3 chapters, 10 topics, plus 50 flashcards written against it.

3Chapters
10Topics
0Sub-topics
~8hEst. first pass
4%Of DevOps
50Flashcards

Infrastructure as Code syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Infrastructure as Code in DevOps, not a summary of it.

  1. Introduction to IaC

    2 topics
    • IaC Concepts and Practices
    • Benefits of IaC
  2. IaC Tools

    5 topics
    • Terraform
    • AWS CloudFormation
    • Ansible
    • Puppet
    • Chef
  3. Writing IaC Scripts

    3 topics
    • Defining Infrastructure Resources
    • Managing State
    • Version Control for IaC

Infrastructure as Code flashcards for DevOps

19 of 50 cards from the Infrastructure as Code deck — real questions with worked answers.

  1. What is Infrastructure as Code (IaC)?

    IaC is the practice of provisioning and managing infrastructure (servers, networks, databases, load balancers) through machine-readable definition files rather than manual configuration or interactive tools. The code becomes the single source of truth for the desired infrastructure state.

  2. What is the difference between declarative and imperative IaC approaches?

    Declarative (functional) IaC specifies the desired end state and lets the tool determine how to achieve it (e.g., Terraform, CloudFormation, Puppet). Imperative (procedural) IaC specifies the exact sequence of commands to reach the state (e.g., Ansible playbooks, Chef recipes, scripts).

  3. What is idempotency in the context of IaC, and why does it matter?

    Idempotency means applying the same configuration multiple times produces the same result without unintended side effects. It matters because it lets you safely re-run IaC to converge infrastructure to the desired state regardless of the current state.

  4. What is the difference between mutable and immutable infrastructure?

    Mutable infrastructure is updated in place (patching/modifying existing servers). Immutable infrastructure is never modified after deployment; changes require building a new instance/image from scratch and replacing the old one, reducing configuration drift.

  5. What is configuration drift?

    Configuration drift is the gradual divergence of actual infrastructure from its defined/desired state, caused by manual changes, ad-hoc fixes, or out-of-band updates. IaC combats drift by re-applying the codified desired state.

  6. List the key benefits of Infrastructure as Code.

    Speed and repeatability of provisioning, consistency across environments, reduced configuration drift, version control and auditability, easy rollback, lower cost through automation, self-documenting infrastructure, scalability, and support for disaster recovery.

  7. How does IaC support disaster recovery?

    Because the entire infrastructure is codified, it can be recreated reliably and quickly in a new region or account from the same definition files, dramatically reducing recovery time after a failure or outage.

  8. What is the difference between provisioning tools and configuration management tools in IaC?

    Provisioning tools create and manage infrastructure resources/instances (e.g., Terraform, CloudFormation). Configuration management tools install software and configure the OS/applications on already-provisioned machines (e.g., Ansible, Puppet, Chef). Some tools overlap.

  9. What language does Terraform use to define infrastructure?

    Terraform uses HCL (HashiCorp Configuration Language), a declarative language. It can also accept JSON. Configuration files use the .tf extension.

  10. What is a Terraform provider?

    A provider is a plugin that lets Terraform interact with a specific platform's API (e.g., AWS, Azure, Google Cloud, Kubernetes). Providers define and manage the resource types available for that platform.

  11. What is the purpose of `terraform init`?

    It initializes a working directory: downloads the required provider plugins, sets up the backend for state storage, and installs modules. It must be run before plan or apply.

  12. What does `terraform plan` do?

    It creates an execution plan: it compares the desired configuration against the current state and shows the additions, changes, and deletions Terraform will make, without actually applying them (a dry run).

  13. What does `terraform apply` do?

    It executes the actions proposed in the plan to create, update, or destroy real infrastructure so it matches the configuration, and then updates the state file.

  14. What does `terraform destroy` do?

    It destroys all the remote infrastructure resources managed by the current Terraform configuration and state.

  15. What is a Terraform module?

    A module is a reusable, self-contained package of Terraform configuration (a directory of .tf files) that groups related resources. Modules promote reuse, organization, and consistency; the root module calls child modules.

  16. What is the Terraform state file and why is it needed?

    The state file (terraform.tfstate) maps the resources in your configuration to real-world objects, tracks metadata and dependencies, and enables Terraform to determine what changed. It is essential for planning updates and detecting drift.

  17. What is a Terraform remote backend and why use one?

    A remote backend (e.g., AWS S3, Terraform Cloud, Azure Blob) stores the state file remotely instead of locally. It enables team collaboration, secures sensitive state data, and supports state locking to prevent concurrent modifications.

  18. What is state locking in Terraform and how is it commonly implemented?

    State locking prevents multiple users from running operations against the same state simultaneously, avoiding corruption. With an S3 backend it is commonly implemented using a DynamoDB table for the lock.

  19. What is the difference between `terraform import` and writing new configuration?

    `terraform import` brings an existing, manually-created resource under Terraform management by recording it in the state file. You still must write matching configuration; import only updates state, it does not generate config.

See more Infrastructure as Code flashcards →

Planning Infrastructure as Code for DevOps

Infrastructure as Code is about 4% of the DevOps syllabus by topic count — 10 of 226 topics, spread over 3 chapters. At roughly 45 minutes per topic plus 12 minutes per sub-topic, a first pass runs to about 8 hours.

The heaviest chapters are IaC Tools (5 topics), Writing IaC Scripts (3 topics), Introduction to IaC (2 topics) . Front-load those while your energy is high; the short chapters are better revision filler later.

Work top-down: read the chapter, then tick topics off individually rather than marking the whole chapter done. Sub-topics are where silent gaps hide.

Infrastructure as Code (DevOps) FAQ

What is in the DevOps Infrastructure as Code syllabus?

Infrastructure as Code is split into 3 chapters — Introduction to IaC, IaC Tools and Writing IaC Scripts, containing 10 topics and 0 sub-topics in total.

How is Infrastructure as Code structured in the DevOps syllabus?

3 chapters. Infrastructure as Code accounts for about 4% of the topics in the whole DevOps syllabus (10 of 226).

How long should I spend on Infrastructure as Code for DevOps?

Budget around 8 hours for a first pass through Infrastructure as Code — about 45 minutes per topic plus 12 minutes per sub-topic across its 10 topics. Add revision cycles on top.

Are there flashcards for DevOps Infrastructure as Code?

Yes — a 50-card Infrastructure as Code deck. Sample cards are printed on this page, and the full deck is free in the Examius app with spaced repetition scheduling.