Infrastructure Provisioning with IaC Quiz Quiz

Assess your understanding of Infrastructure as Code (IaC) practices, tools, and principles. This quiz covers key concepts, benefits, and challenges associated with automating infrastructure provisioning using IaC methodologies.

1. Declarative vs Imperative IaC Approaches

   What is a primary difference between declarative and imperative approaches to Infrastructure as Code, such as when automating the creation of a database server?

   1. Imperative only applies to infrastructure destruction, not creation.
   2. Declarative requires manual intervention while imperative is fully automated.
   3. Imperative is always easier to debug compared to declarative.
   4. Declarative defines the desired state; imperative specifies exact steps to reach that state.

   Explanation: Declarative IaC describes the end result you want, letting the system determine the steps. Imperative approaches require you to spell out each action to reach your goal. The statement about imperative being easier to debug is not universally true. Declarative does not require manual intervention, and imperative can handle both creation and destruction of resources.

2. Version Control Benefits

   Why is storing Infrastructure as Code files in version control systems important for an organization managing multiple cloud environments?

   1. It blocks unauthorized users from viewing the infrastructure code.
   2. It makes the infrastructure immutable and prevents further configuration.
   3. It forces all changes to be performed manually, increasing security.
   4. It allows tracking and auditing changes, promoting consistency and collaboration.

   Explanation: Using version control for IaC helps track edits, audit changes, recover previous infrastructure states, and supports team collaboration. It does not force manual changes—actually, it enables automation. Version control alone does not block unauthorized access; that depends on access policies. Infrastructure does not become immutable just because code is versioned; updates are still possible.

3. Idempotency in IaC

   How does idempotency in Infrastructure as Code benefit automated deployments, for instance, when repeatedly applying a configuration script?

   1. It ensures repeated executions have the same effect, avoiding redundant resource changes.
   2. It causes resources to be re-created every time code runs.
   3. It disables rollback in failure scenarios.
   4. It requires manual approval before each execution.

   Explanation: Idempotency guarantees that applying the same IaC script multiple times yields a consistent result, reducing risk of unintended changes. It does not mean resources are recreated each time; rather, it checks the current state and only applies necessary changes. Idempotency does not disable rollbacks or require manual approvals; these are features of deployment strategy or policy, not idempotency itself.

4. Drift Detection Challenges

   Which scenario best illustrates configuration drift in an IaC-managed environment?

   1. All servers are provisioned identically with no manual changes.
   2. A syntax error is fixed in a local script before any deployment.
   3. A network firewall rule is changed manually after initial provisioning using IaC scripts.
   4. Infrastructure is updated only by rerunning the IaC code.

   Explanation: Configuration drift occurs when resources are altered outside of automated IaC procedures, leading to discrepancies between code and infrastructure. Updating infrastructure only through IaC avoids drift. Provisioning all servers identically with IaC also maintains consistency. Syntax errors fixed before deployment do not cause drift as no infrastructure is affected until a successful script is applied.

5. Mutable vs Immutable Infrastructure

   In the context of IaC, what characterizes a shift from mutable to immutable infrastructure when deploying applications?

   1. Scaling requires physical hardware changes each time.
   2. Resources are replaced entirely upon change rather than being modified in place.
   3. Configuration is stored only on local developer machines.
   4. Infrastructure is patched manually after every deployment.

   Explanation: With immutable infrastructure, any updates result in deploying new resources and decommissioning old ones, improving consistency and reducing errors. Manual patching goes against the immutable approach. Storing configuration solely on developer machines prevents repeatable automation, which is not recommended. Physical scaling is unrelated to the concept of mutable or immutable infrastructure in IaC.