🌍 DevOps · subject

DevOps Infrastructure as Code Syllabus

The Infrastructure as Code syllabus for DevOps in full: 3 chapters and 10 topics, every one listed below, plus 50 Infrastructure as Code flashcards with answers.

3Chapters
10Topics
50Flashcards

Infrastructure as Code syllabus: all 3 chapters

Expand any chapter to see its topics and sub-topics.

  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

DevOps Infrastructure as Code flashcards — 50 questions with 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.

  20. What is AWS CloudFormation?

    CloudFormation is AWS's native IaC service that lets you model and provision AWS (and some third-party) resources using declarative templates written in JSON or YAML.

Show the other 30 Infrastructure as Code flashcards
  1. In CloudFormation, what is a stack?

    A stack is a single unit of related AWS resources that you create, update, and delete together as a group, all defined and managed by one CloudFormation template.

  2. What are the main sections of a CloudFormation template?

    Common sections include: AWSTemplateFormatVersion, Description, Parameters, Mappings, Conditions, Resources (the only required section), Outputs, and Metadata/Transform.

  3. What is the only required section in a CloudFormation template?

    The Resources section, which declares the AWS resources to be created and their properties.

  4. What is a CloudFormation change set?

    A change set is a preview of how proposed changes to a stack will affect running resources before you execute the update, similar to Terraform's plan, helping avoid unintended modifications.

  5. What is drift detection in CloudFormation?

    Drift detection identifies resources in a stack whose actual configuration differs from the template's expected configuration, due to out-of-band manual changes.

  6. What is Ansible and what paradigm does it follow?

    Ansible is an open-source configuration management and automation tool by Red Hat. It is primarily procedural/imperative, agentless, and uses YAML-based playbooks to describe automation tasks.

  7. Why is Ansible described as agentless, and how does it connect to managed nodes?

    Ansible requires no agent software installed on managed nodes. It connects over SSH (Linux/Unix) or WinRM (Windows) and executes modules remotely, using Python on the target as needed.

  8. What is an Ansible playbook?

    A playbook is a YAML file containing one or more plays that map groups of hosts to a set of tasks (module calls), defining the automation/configuration to run in order.

  9. What is an Ansible inventory?

    The inventory is a file (INI or YAML) that lists the managed hosts and organizes them into groups, optionally with variables, telling Ansible which machines to target.

  10. What is an Ansible role?

    A role is a structured, reusable way to package related tasks, handlers, variables, templates, and files into a standard directory layout, making playbooks modular and shareable (often via Ansible Galaxy).

  11. What is Puppet and what paradigm does it use?

    Puppet is a declarative configuration management tool that defines the desired end state of systems. It traditionally uses a master/agent (pull) architecture and its own Puppet DSL (Ruby-based).

  12. What is a Puppet manifest?

    A manifest is a file (with a .pp extension) written in the Puppet DSL that declares resources and their desired state for nodes to enforce.

  13. What architecture does Puppet typically use, and how do agents get configuration?

    Puppet uses a master/agent (pull-based) architecture: agents periodically poll the Puppet master, which compiles a catalog of desired state, and the agent applies it locally. (A masterless mode also exists.)

  14. What is a catalog in Puppet?

    A catalog is a compiled document describing the desired state of every managed resource on a node, generated by the Puppet master from manifests and applied by the agent.

  15. What is Chef and what language/paradigm does it use?

    Chef is a configuration management tool that uses a Ruby-based DSL. It is procedural in authoring recipes but converges to a desired state, and traditionally uses a master/agent (pull) model with a Chef Server.

  16. In Chef, what is a recipe and what is a cookbook?

    A recipe is a Ruby file that declares resources describing the desired configuration. A cookbook is a collection of recipes plus templates, files, and attributes that packages a configuration unit for reuse.

  17. What does the Chef client do, and what is convergence?

    The Chef client runs on each node, pulls cookbooks from the Chef Server, and applies recipes. Convergence is the process of bringing the node into the desired state defined by the run-list.

  18. Compare Ansible, Puppet, and Chef on architecture (agent vs agentless).

    Ansible is agentless (push over SSH/WinRM). Puppet and Chef traditionally use agents with a master/server and a pull model (though both support masterless modes).

  19. Compare the languages used by Puppet, Chef, and Ansible.

    Puppet uses its own declarative Ruby-based DSL (manifests). Chef uses a procedural Ruby-based DSL (recipes). Ansible uses declarative YAML playbooks. Terraform uses HCL.

  20. What does it mean to 'define infrastructure resources' in IaC?

    It means declaring the desired components (compute instances, networks, storage, security groups, DNS, etc.) and their attributes and interdependencies in code, so the tool can create and manage them automatically.

  21. What is a resource dependency, and how do tools resolve ordering?

    A dependency exists when one resource must be created before another (e.g., a subnet before an instance). Tools build a dependency graph; Terraform infers implicit dependencies from references and supports explicit ones via `depends_on`.

  22. What is the difference between Terraform variables and outputs?

    Input variables parameterize a configuration so values can be supplied at runtime, making it reusable. Outputs expose selected values from the configuration (e.g., an IP address) for users or for consumption by other modules.

  23. Why is hardcoding secrets in IaC files a bad practice, and what are alternatives?

    Hardcoded secrets get committed to version control and exposed to anyone with repo access. Alternatives include secret managers (HashiCorp Vault, AWS Secrets Manager), environment variables, encrypted variables, and marking values as sensitive.

  24. Why should IaC be stored in version control systems like Git?

    Version control provides history and auditability of changes, collaboration via branches and pull requests, code review, rollback to previous known-good states, and traceability of who changed what and when.

  25. What is the GitOps approach to IaC?

    GitOps uses a Git repository as the single source of truth for declarative infrastructure and application configuration; automated agents continuously reconcile the live system to match the committed state, with all changes made via Git commits/PRs.

  26. Why is the Terraform state file sensitive, and how should it be handled in version control?

    State can contain secrets and resource metadata in plaintext, so it should NOT be committed to Git. Instead, store it in a secure remote backend with encryption and access controls, and exclude it via .gitignore.

  27. What is the recommended workflow for reviewing IaC changes before applying them?

    Use a pull/merge request, generate a plan (terraform plan or a CloudFormation change set) so reviewers can see exactly what will change, require peer code review, and run automated validation/linting in CI before merging and applying.

  28. What is the difference between `terraform validate` and `terraform fmt`?

    `terraform validate` checks that the configuration is syntactically valid and internally consistent. `terraform fmt` automatically rewrites configuration files to a canonical format and style.

  29. What is the role of CI/CD pipelines in an IaC workflow?

    CI/CD automates linting, validation, security scanning, plan generation on pull requests, and applying changes on merge, ensuring infrastructure changes are tested, reviewed, and deployed consistently and repeatably.

  30. What is a Terraform workspace and what problem does it help solve?

    A workspace is a named, separate instance of state within the same configuration, often used to manage multiple distinct deployments (e.g., dev, staging, prod) without duplicating code, each with its own isolated state.

DevOps Infrastructure as Code FAQ

What is in the DevOps Infrastructure as Code syllabus?

DevOps Infrastructure as Code is split into 3 chapters: Introduction to IaC, IaC Tools and Writing IaC Scripts. Together they contain 10 topics.

How many chapters are in DevOps Infrastructure as Code?

3 chapters, containing 10 topics. The largest chapter is IaC Tools, with 5 topics.

Are there flashcards for DevOps Infrastructure as Code?

Yes — a 50-card Infrastructure as Code deck, printed in full in the flashcards section of this page and available in the Examius app with spaced repetition. The free plan covers one exam of your choice, including its flashcards; Examius Pro, a one-time purchase, unlocks every other exam and deck.