2. IaC Architecture and Delivery Lifecycle

Introduction and Context

Infrastructure as Code (IaC) is not merely a technique for replacing manual server configuration with scripts. It is an operating model for designing, reviewing, delivering, governing, operating, and eventually retiring infrastructure through controlled, repeatable, machine-readable processes. In a DevOps environment, IaC connects architectural intent with executable change. Terraform commonly expresses the desired state of cloud and platform resources, while Ansible is often used to configure operating systems, applications, and services. In practice, organizations frequently combine both approaches within a broader delivery system.

The value of IaC depends less on the ability to write a resource block or a playbook than on the quality of the lifecycle surrounding that code. Poorly designed infrastructure code can reproduce errors at high speed, expose sensitive information, create uncontrolled environments, and make retirement difficult. A mature IaC capability therefore begins with requirements and architecture, continues through source control, review, testing, and environment promotion, and remains active during operations, change management, and decommissioning.

This chapter presents IaC as a lifecycle and governance discipline. It examines architectural decisions, repository design, branching and promotion strategies, Terraform and Ansible delivery workflows, documentation, operational feedback, security, and retirement. The central argument is that infrastructure is a product with a lifecycle, not a collection of disposable scripts.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Describe the stages of an IaC delivery lifecycle from requirements to retirement.

2. Distinguish architectural intent, desired state, actual state, and configuration behavior.

3. Design repositories, environments, modules, inventories, and promotion paths for maintainable IaC.

4. Explain the roles of source control, branching, peer review, testing, and policy checks.

5. Compare alternative environment and release strategies and select an appropriate approach.

6. Analyze operational, security, governance, and organizational risks in IaC delivery.

7. Apply lifecycle principles to a realistic Terraform and Ansible scenario.

IaC as an Architectural Discipline

Traditional infrastructure delivery often separates architecture from implementation. An architect produces a diagram, an operations team provisions resources, and a security team reviews the result after deployment. IaC makes this separation less defensible because the implementation itself becomes an executable expression of architecture. Network boundaries, identity permissions, storage settings, scaling rules, monitoring integrations, and configuration defaults are represented in code and can be examined before they affect a running environment.

Three perspectives are useful. Desired state describes what the organization intends to exist: for example, a private application subnet, a database with encrypted storage, and a workload identity with restricted permissions. Actual state describes what currently exists in the platform. Configuration behavior describes how tools create, modify, or configure resources to reduce the difference between desired and actual state. Terraform primarily manages declarative resource state and relationships. Ansible generally performs configuration tasks, although idempotent playbooks also express a desired condition such as “the package is installed” or “the service is enabled.”

An IaC architecture should make several boundaries explicit:

• The boundary between reusable infrastructure components and environment-specific composition.
• The boundary between provisioning and configuration management.
• The boundary between application delivery and platform delivery.
• The boundary between code, state, secrets, and generated artifacts.
• The boundary between individual team autonomy and organizational governance.

A sound architecture is modular without becoming fragmented. A Terraform module might create a standard network or managed database, while a root configuration composes those modules for a particular product environment. Ansible roles may provide a standard web server configuration, while inventories and variables describe the hosts on which the role is applied. Excessive abstraction, however, can hide important behavior. A module that accepts dozens of poorly documented parameters may be less maintainable than a smaller, explicit component.

From Requirements to an Infrastructure Design

The lifecycle begins before code is written. Requirements should identify workload behavior, availability expectations, data sensitivity, performance characteristics, geographical constraints, recovery objectives, compliance obligations, cost limits, and ownership. Infrastructure requirements are frequently incomplete because stakeholders express goals in application language. “The service must remain available during a zone failure” must be translated into topology, redundancy, health checks, deployment strategy, and recovery procedures.

A requirements-to-design process can be organized into five analytical activities.

First, establish service boundaries. Determine which components are owned by the platform team, product team, security function, or a managed provider. This prevents IaC repositories from becoming unclear mixtures of application, platform, and organizational responsibilities.

Second, identify non-functional requirements. Availability, latency, recovery time objective, recovery point objective, auditability, cost, and data residency influence architecture more strongly than the choice of syntax. A low-risk development environment should not automatically receive the same resilience and capacity as production, but its differences should be intentional and documented.

Third, model dependencies. A workload may depend on identity services, network routes, secrets, container registries, databases, DNS, certificates, observability systems, and external APIs. Dependency analysis helps determine provisioning order and ownership. It also exposes circular designs in which two components cannot be created independently.

Fourth, define invariants and policies. An invariant is a condition that must remain true, such as encryption being enabled, public access being prohibited for a database, or mandatory tags identifying an owner and cost centre. Invariants can be documented, tested, and enforced through policy-as-code.

Fifth, select lifecycle and failure assumptions. The design should state whether resources are persistent, replaceable, stateful, ephemeral, or shared. It should also identify what happens when a deployment fails, a region becomes unavailable, credentials expire, or a resource must be restored.

The output is not simply a diagram. It may include an architecture decision record, a dependency model, naming and tagging rules, data classification, environment definitions, recovery requirements, and a map of responsibilities. These artefacts provide the context against which infrastructure code can be reviewed.

The IaC Delivery Lifecycle

The lifecycle is iterative rather than strictly linear. Operational findings can change requirements, and retirement planning can influence the initial design. Nevertheless, the following stages provide a practical control model.

1. Discover and Specify

Stakeholders define the service, its constraints, ownership, environments, interfaces, and success criteria. The team determines whether a requirement is best implemented as a platform capability, a reusable module, an application configuration, or a manual exception. Ambiguity at this stage becomes expensive later because code tends to conceal unresolved decisions behind defaults.

2. Architect and Decompose

The desired platform is decomposed into networks, identity, compute, storage, data services, observability, and supporting controls. Components are assigned boundaries and interfaces. The team decides which parts should be reusable modules, which values should be variables, and which settings must be fixed by organizational policy.

3. Implement in Source Control

Infrastructure code, tests, documentation, examples, policy definitions, and pipeline configuration are committed to a version-control repository. The repository becomes the authoritative record of proposed and accepted change. Secrets should not be committed; they should be supplied through a secret manager, protected pipeline variable, or short-lived identity mechanism.

Terraform practitioners typically format and validate code, initialize providers, create a plan, and apply an approved plan. Ansible practitioners commonly lint YAML and roles, validate inventories, run syntax checks, test idempotence, and execute playbooks against controlled targets. Both tools benefit from pinned versions and explicit dependency management.

4. Review and Verify

A pull request or merge request provides a formal point for peer review. Reviewers examine not only syntax but also blast radius, identity permissions, data protection, naming, cost, rollback behavior, observability, and compatibility with existing resources. Automated checks may include formatting, static analysis, security scanning, unit tests for modules, policy tests, and plan analysis.

Terraform plans should be treated as change proposals, not as harmless previews. A plan that replaces a database or removes a route requires a different level of scrutiny from one that adds a non-production tag. Ansible changes should be assessed for privilege escalation, ordering, idempotence, service interruption, and behavior when a task partially succeeds.

5. Promote Through Environments

Approved changes should move through environments using a defined promotion model. A typical sequence is development, integration or testing, staging, and production. Promotion does not mean blindly copying a development state into production. It means promoting the same reviewed version of a component while supplying environment-specific values through controlled configuration.

Environment isolation can be implemented through separate Terraform state files, workspaces, directories, accounts or subscriptions, and Ansible inventories. Each option has trade-offs. Separate accounts provide strong isolation but may increase administration. Workspaces can be convenient but may obscure differences when used carelessly. Separate root configurations are explicit and often easier to review, although they require more repository structure.

6. Deploy and Observe

Deployment is an operational event, not the end of the process. Pipelines should record who approved a change, which commit was deployed, which plan or playbook ran, what identity was used, and what result occurred. Monitoring should verify both infrastructure health and service behavior. Logs, metrics, traces, configuration drift alerts, and cost signals provide evidence about whether the implementation meets its requirements.

7. Operate, Change, and Reconcile

Infrastructure changes continuously because of security patches, scaling, provider changes, incidents, and new product requirements. Teams must decide how emergency changes are handled. Direct console changes may be necessary during an incident, but they create drift and should be followed by reconciliation: either the code is updated to represent the approved change or the manual change is deliberately removed.

Drift is not always an error. Some platforms update managed resources automatically, and some attributes are controlled externally. The important question is whether the difference is understood, authorized, and sustainable. Regular plan reviews, drift detection, and ownership of exceptions prevent the actual environment from becoming an undocumented second source of truth.

8. Retire and Verify Disposal

Retirement includes more than deleting compute resources. It involves dependencies, DNS records, identities, snapshots, backups, certificates, monitoring alerts, state entries, data retention, billing associations, and documentation. Destruction must be authorized and, for regulated or valuable data, supported by retention and disposal evidence. A deliberate retirement workflow reduces orphaned resources and prevents credentials or access paths from surviving the service they supported.

Repository, State, and Documentation Design

Repository design communicates how a team thinks about ownership and change. One repository may contain a complete platform for a product; another may separate reusable modules from environment compositions. There is no universal structure, but a useful design keeps interfaces visible and limits hidden coupling.

A conceptual Terraform repository might contain reusable modules, environment root configurations, policy tests, pipeline definitions, and architecture documentation. An Ansible repository might contain roles, inventories, group variables, host variables, playbooks, collections, and test material. Generated files, local caches, plans containing sensitive values, and credentials should be excluded or protected appropriately.

Terraform state deserves particular attention. State maps configuration resources to objects managed by Terraform and may contain sensitive information. It should normally be stored in a protected remote backend with encryption, access control, locking where supported, versioning, and recovery procedures. State is not merely a cache that can be copied casually. A corrupted, exposed, or concurrently modified state can cause service disruption and security compromise.

Ansible does not use a Terraform-style state file for general configuration reconciliation, so the team must define how inventory, variables, facts, and external systems represent reality. This difference matters: Terraform commonly plans a resource graph from stored state and provider observations, whereas Ansible generally evaluates tasks against target systems during execution. Combining the tools requires clear ownership. Terraform may create instances and attach identities; Ansible may configure the operating system and application. Neither should silently overwrite the other's responsibilities.

Documentation should be treated as part of the deliverable. At minimum, a component should state its purpose, inputs, outputs, supported versions, dependencies, security assumptions, examples, ownership, operational procedures, and destruction implications. Architecture decision records are useful when a choice has meaningful alternatives or long-term consequences. Documentation that is generated from code can improve consistency, but generated documentation does not replace explanations of intent.

Branching, Review, and Promotion Strategies

A branching model is a coordination mechanism, not a goal. Long-lived feature branches can isolate work but increase merge conflicts and delay integration. Short-lived branches with frequent pull requests encourage small changes and rapid feedback. A trunk-based model may suit mature teams with strong automated testing and feature controls; a release-branch model may be appropriate where infrastructure changes require formal release windows or extended validation.

Regardless of model, effective practice includes small changes, descriptive commits, protected production branches, mandatory reviews for high-risk changes, and traceability from a requirement or incident to the deployed revision. Reviews should involve the right expertise. A platform engineer may understand resource behavior, while a security engineer may identify excessive permissions and a service owner may understand availability consequences.

Promotion strategies include:

• Direct sequential promotion: the same commit is applied progressively to increasingly important environments.
• Rebuild promotion: each environment is created from the same reusable definition, with environment-specific inputs.
• Blue-green infrastructure: a new environment is created alongside the old one and traffic is switched after validation.
• Canary or progressive delivery: a change is exposed to a limited portion of traffic before wider adoption.

Blue-green and canary approaches can reduce deployment risk but may temporarily increase cost and require compatible data migration. Rebuilding an environment improves repeatability but may be unsuitable for stateful systems without carefully designed data handling. The appropriate approach depends on failure tolerance, resource cost, statefulness, and organizational control requirements.

Testing and Policy as Code

IaC testing operates at several levels. Formatting and syntax checks detect basic defects. Static analysis identifies insecure or suspicious patterns. Unit tests can verify module inputs and outputs. Integration tests provision real or representative resources and validate behavior. End-to-end tests assess whether a complete service works. Post-deployment checks confirm health, connectivity, identity behavior, and observability.

Idempotence is especially important for configuration management. Running an Ansible playbook twice should normally produce no unnecessary changes after the first successful run. Non-idempotent commands, uncontrolled shell scripts, time-dependent logic, and tasks that depend on undocumented host conditions reduce confidence.

Policy as code converts governance requirements into executable rules. Examples include prohibiting public storage, requiring encryption, restricting permitted regions, enforcing tags, or limiting privileged roles. Policy tools can inspect Terraform plans, configuration files, or cloud APIs. Policies should be proportionate: an unreviewable collection of exceptions encourages teams to bypass controls. A mature system records exceptions, assigns owners, defines expiry dates, and distinguishes blocking policies from advisory warnings.

A Detailed Illustrative Case: Promoting a Retail Ordering Platform

Background

A fictional retailer, Northstar Retail, operates an online ordering platform. Its initial infrastructure was created manually in a cloud console. Development, testing, and production differ in undocumented ways, and an audit has identified public network paths, inconsistent tags, and excessive administrator permissions. The organization decides to establish a Terraform and Ansible delivery lifecycle.

Situation and Problem

The platform consists of a web tier, application services, a managed database, object storage, monitoring, and a deployment runner. The database contains customer order data and must not be publicly reachable. The service owner requires high availability across two availability zones, while the finance team requires cost visibility by product and environment. The team must introduce IaC without interrupting production.

Analysis

The team first maps ownership and dependencies. Terraform will manage network components, identity roles, compute or container resources, managed database settings, storage, and monitoring integrations. Ansible will configure a small set of virtual machines used for specialized integration services. Application deployment remains under the application pipeline. Production and non-production use separate cloud accounts, reducing accidental cross-environment access.

The team identifies several risks. Importing existing resources into state may produce incorrect assumptions. A naïve apply could replace the database. Manual security fixes may be lost if they are not represented in code. A shared administrator credential would undermine auditability. Finally, development settings must not be copied into production simply because the code is shared.

Approach and Solution

Northstar creates a repository containing reusable network, database, identity, and monitoring modules, together with explicit root configurations for development, staging, and production. Each environment has a separate protected state backend. State access is granted to the deployment identity rather than to every developer.

The team imports existing resources gradually and reviews the resulting plans. Before any production apply, it runs validation, security scanning, policy checks, and integration tests in a temporary environment. A policy blocks public database access and requires encryption, ownership tags, and approved regions. A second policy warns when a proposed change exceeds a cost threshold; high-impact changes require architecture approval.

Ansible roles configure operating-system hardening, service users, logging agents, and the integration service. Roles are tested for idempotence, and inventories are separated by account and environment. Secrets are retrieved at runtime from a managed secret store. The pipeline uses short-lived credentials through workload identity rather than stored cloud keys.

Changes are developed in short-lived branches. A pull request displays the Terraform plan and test results. Two reviewers approve production changes: one for platform correctness and one for security or operational risk. The same commit is promoted from development to staging and then production, while environment-specific values remain outside reusable module logic.

Outcome

The retailer gains a traceable infrastructure history, consistent security controls, and repeatable environment construction. Drift detection identifies two manually changed firewall rules, which are reconciled after review. A later database parameter change is first tested in staging and then promoted during an approved maintenance window. The organization also discovers that retirement must include monitoring alerts and deployment identities, not only compute resources.

Learning Points

The case demonstrates that IaC success depends on lifecycle controls rather than syntax alone. Importing existing infrastructure requires caution; state must be protected; environment separation should be deliberate; policy checks should be automated; and promotion must preserve traceability. Most importantly, operational ownership continues after deployment.

Risks, Limitations, and Common Mistakes

IaC introduces substantial benefits but does not eliminate complexity. Common mistakes include treating plans as automatically safe, granting pipelines excessive privileges, storing secrets in repositories or state, using mutable shared environments, and relying on copy-and-paste rather than reusable components. Another error is excessive modularization: abstractions that hide provider behavior can make review and troubleshooting difficult.

State locking and concurrency controls are essential where multiple pipeline executions could modify the same resources. Provider upgrades, module changes, and platform API changes should be tested because apparently minor version changes can alter defaults or resource behavior. Destructive operations require explicit safeguards, backups where appropriate, and a clear approval path.

Rollback is more complicated than reverting a Git commit. A code revert may not restore data, external side effects, schema changes, certificates, or provider-managed behavior. Teams should distinguish infrastructure rollback from application rollback and design forward-fix procedures where reversal is unsafe.

Organizational risks are also significant. If teams own code but not the resulting service, defects may be passed between development and operations. If all infrastructure changes require a central team, delivery may become a bottleneck. Platform teams should provide reusable capabilities and guardrails while preserving appropriate product-team autonomy.

Security, Governance, and Professional Responsibility

IaC repositories are privileged assets. Access should follow least privilege, with separate identities for development, testing, and production. Pipeline credentials should be short-lived where possible, and approvals should be recorded. Sensitive values must be excluded from logs, plans, pull-request comments, and generated documentation. Encryption, secret rotation, dependency control, and vulnerability scanning should cover both infrastructure code and the systems it creates.

Governance should be risk-based. Production destruction, identity changes, public exposure, and regulated data movement deserve stronger controls than harmless documentation edits. Audit records should connect the request, reviewer, commit, plan, identity, execution result, and observed outcome. Separation of duties may be required in regulated contexts, but it should not become a purely ceremonial approval process.

Professional responsibility includes communicating uncertainty. Engineers should not describe an untested plan as safe, claim that code guarantees compliance without evidence, or conceal manual changes because they are inconvenient to reconcile. Infrastructure decisions affect availability, privacy, finances, and sometimes public safety. Technical competence therefore includes the duty to make assumptions and limitations visible.

Current Developments and Emerging Practice

IaC is increasingly integrated with platform engineering, internal developer platforms, and policy automation. Developers may request approved infrastructure through service templates while platform teams provide standardized modules and controls. This model can reduce cognitive load, but templates must expose meaningful choices and avoid creating opaque platforms.

Ephemeral environments are being used for pull-request validation and integration testing. They improve feedback but require automated cleanup, cost controls, data isolation, and careful treatment of external dependencies. Infrastructure drift detection is also becoming more continuous, with event-driven alerts and automated remediation for narrowly defined policies.

Artificial intelligence can assist with code suggestions, documentation, plan explanation, anomaly detection, and policy review. It should not receive uncontrolled access to production credentials or be trusted to approve destructive changes without human accountability. Generated infrastructure may contain insecure defaults, hidden permissions, or provider-specific errors. Human review, automated testing, and explicit authorization remain necessary.

Declarative infrastructure is also expanding beyond traditional virtual machines into managed services, Kubernetes resources, identity, observability, and software supply-chain controls. As the scope expands, teams must avoid assuming that every resource has identical lifecycle semantics. A stateless compute instance, a customer database, and an identity policy require different testing, backup, approval, and retirement procedures.

Best-Practice Synthesis

A mature IaC delivery system generally follows these principles:

1. Begin with explicit service requirements, ownership, dependencies, and failure assumptions.

2. Keep architecture, code, policy, tests, and operational documentation connected.

3. Separate reusable components from environment composition and protect state independently.

4. Use version control as the authoritative change record and keep production changes reviewable.

5. Promote tested revisions through isolated environments rather than relying on manual reconstruction.

6. Treat plans, playbooks, credentials, and state as operationally sensitive.

7. Automate validation, security checks, policy enforcement, drift detection, and cleanup.

8. Design for observability, recovery, reconciliation, and retirement from the beginning.

9. Use the least privilege necessary and maintain traceable, time-bounded exceptions.

10. Prefer small, reversible changes, while recognizing that data and identity changes may not be reversible.

Chapter Summary

IaC is a lifecycle discipline that transforms infrastructure architecture into versioned, testable, reviewable, and operationally governed change. The lifecycle begins with requirements and architectural decomposition, continues through implementation, source control, review, testing, promotion, deployment, observation, and reconciliation, and ends with controlled retirement. Terraform commonly manages declarative infrastructure state, while Ansible commonly configures systems through repeatable, idempotent tasks; their boundaries must be explicit when used together.

Repository structure, state protection, documentation, branching, environment isolation, policy as code, and promotion strategy determine whether IaC remains maintainable at organizational scale. Security and governance must address privileged pipelines, secrets, drift, auditability, and destructive actions. The Northstar Retail case illustrates how importing existing infrastructure, separating environments, testing plans, and enforcing policies can reduce operational risk. Emerging practices such as ephemeral environments, internal platforms, continuous drift detection, and AI assistance offer value only when accompanied by human accountability and strong controls.

Key Terms

Desired state: The condition that infrastructure code declares should exist.

Actual state: The condition currently observed in a platform or target system.

Configuration drift: An unintended or unexplained difference between desired and actual state.

Terraform state: Data mapping declared Terraform resources to real infrastructure objects.

Ansible role: A reusable structure containing tasks, variables, handlers, templates, and related configuration.

Module: A reusable, parameterized collection of infrastructure definitions.

Root configuration: The environment-level Terraform configuration that composes modules and providers.

Idempotence: The property that repeated execution produces no unnecessary change after the desired condition is reached.

Environment promotion: Moving a reviewed infrastructure revision through controlled environments.

Policy as code: Expressing governance or security rules in machine-evaluable form.

Pull request: A proposed source-control change submitted for review and automated verification.

Blast radius: The extent of systems, resources, or users potentially affected by a change.

Remote backend: A protected service used to store and coordinate Terraform state.

Infrastructure module interface: The documented inputs, outputs, assumptions, and behavior exposed by a reusable component.

Ephemeral environment: A temporary environment created for a limited purpose and automatically removed afterward.

Architecture decision record: A document capturing an important design decision, its rationale, and consequences.

Drift reconciliation: The process of investigating and resolving differences between code and deployed infrastructure.

Workload identity: A mechanism allowing an automated workload to obtain authorized access without long-lived static credentials.

Infrastructure retirement: The controlled removal of resources, access, data, dependencies, and operational records.

Review Questions

Short Answer Questions

1. Distinguish desired state from actual state in an IaC system.

2. Why should Terraform state be stored in a protected remote backend?

3. What is the purpose of a pull request in infrastructure delivery?

4. Explain idempotence in the context of Ansible.

5. Identify two activities that must be included when retiring infrastructure.

Long Answer Questions

1. Explain the complete IaC delivery lifecycle from requirements discovery to retirement.

2. Discuss how repository structure, environment isolation, and state management affect IaC maintainability.

3. Compare trunk-based development and release-branch approaches for infrastructure code.

4. Explain how policy as code, testing, and peer review work together to reduce infrastructure risk.

5. Discuss the security and governance responsibilities associated with Terraform and Ansible pipelines.

Analytical / Application Questions

1. A production plan proposes replacing a managed database after a module upgrade. What analysis, safeguards, and approvals should occur before deployment?

2. An organization has separate development and production environments, but engineers frequently make console changes in production. Design a drift-reconciliation and governance process.

3. A platform team wants to create ephemeral environments for every pull request. Evaluate the benefits, risks, cost controls, data requirements, and retirement mechanisms that should be considered.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the relationship between desired state and actual state in IaC?

A. Desired state is what the platform currently contains, while actual state is what the code intends

B. Desired state is the intended condition, while actual state is the condition observed in the platform

C. Both terms describe the contents of a source-control repository

D. Actual state exists only before the first deployment

Correct Answer: B. Desired state is the intended condition, while actual state is the condition observed in the platform

Question 2

A team wants to ensure that a production database cannot be publicly reachable. Which approach most directly implements this requirement as an automated control?

A. Adding a note to the architecture diagram

B. Relying on an administrator to inspect the console after deployment

C. Creating a policy-as-code rule that evaluates the proposed infrastructure

D. Using a longer Git commit message

Correct Answer: C. Creating a policy-as-code rule that evaluates the proposed infrastructure

Question 3

Why is a Terraform plan treated as a change proposal rather than as proof that a deployment is safe?

A. A plan cannot show any resource changes

B. A plan may propose high-impact actions such as replacement or deletion that still require analysis

C. Terraform plans are unrelated to the configured resources

D. Plans are generated only after production deployment

Correct Answer: B. A plan may propose high-impact actions such as replacement or deletion that still require analysis

Question 4

Which repository practice most effectively supports controlled environment promotion?

A. Copying and editing production files manually for every release

B. Promoting a reviewed revision while supplying controlled environment-specific values

C. Allowing each environment to use unrelated code branches indefinitely

D. Storing credentials beside environment variables in the repository

Correct Answer: B. Promoting a reviewed revision while supplying controlled environment-specific values

Question 5

What is the principal purpose of protecting Terraform state?

A. To prevent developers from formatting Terraform code

B. To preserve mappings to managed resources and prevent unauthorized or concurrent modification

C. To make Ansible inventories unnecessary

D. To ensure all infrastructure is created in one cloud account

Correct Answer: B. To preserve mappings to managed resources and prevent unauthorized or concurrent modification

Question 6

An Ansible playbook changes a service every time it runs, even when the desired configuration is already present. Which property is missing?

A. Idempotence

B. Environment isolation

C. State locking

D. Blue-green deployment

Correct Answer: A. Idempotence

Question 7

Which action best addresses a manual production firewall change discovered by drift detection?

A. Ignore it because the platform is already running

B. Delete the entire environment immediately

C. Investigate and authorize the change, then reconcile code and actual infrastructure

D. Disable future drift detection

Correct Answer: C. Investigate and authorize the change, then reconcile code and actual infrastructure

Question 8

Why might separate cloud accounts or subscriptions be preferred for production and non-production?

A. They guarantee that infrastructure code contains no defects

B. They provide stronger isolation and reduce accidental cross-environment access

C. They eliminate the need for source control

D. They make state and secrets publicly accessible

Correct Answer: B. They provide stronger isolation and reduce accidental cross-environment access

Question 9

Which retirement activity is most likely to be overlooked if a team focuses only on deleting compute resources?

A. Removing obsolete monitoring alerts and deployment identities

B. Running a code formatter

C. Creating an additional development branch

D. Increasing application capacity

Correct Answer: A. Removing obsolete monitoring alerts and deployment identities

Question 10

What is the most appropriate use of AI assistance in IaC delivery?

A. Allowing an AI system with unrestricted credentials to approve destructive production changes

B. Using AI for suggestions or plan explanation while retaining testing, review, and human authorization

C. Replacing all architecture decisions with generated code

D. Committing AI-generated secrets to the repository for convenience

Correct Answer: B. Using AI for suggestions or plan explanation while retaining testing, review, and human authorization