Common IaC Interview Questions Quiz Quiz

Challenge your understanding of Infrastructure as Code principles, tools, and best practices with targeted questions covering version control, configuration management, idempotency, and common IaC pitfalls. Sharpen your skills for IaC interviews and demonstrate practical knowledge of automated infrastructure deployment strategies.

1. Version controlling IaC code

   Why is it considered a best practice to store Infrastructure as Code (IaC) files in a version control system, even for small internal projects?

   1. It enables tracking changes, rollback, and collaboration among team members.
   2. It encrypts all secrets automatically during code commits.
   3. It speeds up the execution of infrastructure deployment.
   4. It ensures resources are deleted when files are removed from the repository.

   Explanation: Storing IaC files in a version control system makes it possible to track changes over time, revert to previous versions, and work collaboratively, which are essential for maintaining reliable infrastructure. While version control does not directly encrypt secrets (that requires specific tools or workflows), nor does it automatically delete cloud resources when files are deleted. Storing files does not inherently speed up deployment; execution speed depends on the tools and infrastructure, not the repository.

2. Understanding idempotency in IaC

   In the context of Infrastructure as Code, what does it mean for an operation to be idempotent?

   1. It produces the same result every time it is applied, regardless of the current state.
   2. It limits execution to specific operating systems.
   3. It runs only once, then skips all future executions.
   4. It creates resources at random each time it runs.

   Explanation: Idempotency in IaC refers to the property where repeated application of code does not change the outcome if the desired state is already achieved, which helps prevent accidental changes or drift. The operation does not just run once and skip afterward; that describes a one-time job, not idempotency. Idempotency is unrelated to randomness or restricting operations by operating system.

3. Declarative vs imperative configuration

   Which of the following best exemplifies a declarative approach in Infrastructure as Code?

   1. Using a wizard interface to select different infrastructure options.
   2. Describing the desired final state of resources without specifying the exact steps to reach it.
   3. Writing a script with commands to manually create resources step-by-step.
   4. Manually configuring networking settings on each server.

   Explanation: The declarative model focuses on describing what the end state of the infrastructure should be, leaving the process of reaching that state to the underlying tool. In contrast, imperative scripts require step-by-step instructions and manual configuration lacks automation. Wizard interfaces are not code-based approaches and don't offer the repeatability of declarative IaC.

4. Managing configuration drift

   What is a primary risk associated with configuration drift when using Infrastructure as Code?

   1. All resources are locked and impossible to update.
   2. The code will automatically destroy the infrastructure without warning.
   3. Infrastructure may differ from what the code specifies due to manual changes.
   4. Servers will always auto-scale beyond their defined limits.

   Explanation: Configuration drift occurs when manual changes cause the live environment to deviate from the configuration defined in code, leading to unpredictability and potential issues. It does not cause code to delete infrastructure as a standard reaction, nor does it automatically enforce scaling. Locking resources and being impossible to update is not a common result of configuration drift.

5. Common IaC mistake scenario

   During a deployment, an engineer accidentally committed sensitive API keys in plain text to the IaC files. What is the recommended best practice to prevent this issue?

   1. Manually review all code changes after every deployment.
   2. Store secrets in a secure secrets management system and reference them in code.
   3. Always hide sensitive strings by using complex variable names.
   4. Include secrets at the top of the configuration file for quick editing.

   Explanation: Best practice is to manage secrets outside of code repositories using a dedicated secrets management system, referencing secrets securely within IaC files. Using complex variable names does not protect secrets, and manual reviews after deployments are insufficient for prevention. Placing secrets at the top of files increases the risk of exposure rather than reducing it.