DevOps Infrastructure as Code Flashcards

24 sample cards from the Infrastructure as Code deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

1. 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.

2. 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.

3. 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.

4. 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).

5. 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).

6. 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.

7. 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.)

8. 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.

9. 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.

10. 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.

11. 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.

12. 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).

13. 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.

14. 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.

15. 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`.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

What this deck covers

Infrastructure as Code flashcards FAQ