CL-009·CL Track·Advanced·10–45 hrs saved

Stop Every Team from Inventing Its Own Cloud — Build IaC That's Governed, Recoverable, and Drift-Resistant

An AI-assisted workflow to design an Infrastructure-as-Code operating model — repository strategy, modules, pipelines, state protection, policy-as-code, and drift management — before code goes to production.

3Phases

25Prompts

10–45Hours saved

7Deliverables

Executive Brief

Your Challenge

Your teams adopted Infrastructure-as-Code by letting everyone pick their own tools and write their own templates. Now you have duplicate modules, inconsistent tagging, state files scattered across teams, permanent credentials sitting in pipeline secrets, and production changes made through the portal that nobody reconciles back to code. The automation runs, but you can't prove environments are consistent, secure, or recoverable — and every incident takes longer because no one knows which configuration is the real one.

Common Obstacles

Organizations fail in two opposite directions. Decentralize completely and you get duplication, inconsistent security, fragmentation, and repeated architecture mistakes. Over-centralize and you get platform bottlenecks, slow approvals, inflexible modules, and teams bypassing standards to ship. Underneath both sits the same set of hazards: state files treated as ordinary storage, secrets marked "sensitive" that still land in state, plans reviewed as code without inspecting what the provider will actually destroy, and drift that gets overwritten automatically — erasing an approved emergency fix the code never captured.

The ABME Approach

This workflow builds the operating model in the right order: define objectives and ownership boundaries, choose tools to fit the organization, then design the repository, module, environment, and state architecture. From there it hardens the delivery chain — short-lived pipeline identities, protected state, policy-as-code, and security scanning — and standardizes deployment with plan review, destructive-change controls, and evidence retention. Drift detection, controlled manual-change reconciliation, and recovery planning close the loop so the environment stays consistent under real operational pressure, not just on the first deploy.

Insight Summary

Infrastructure-as-Code is successful when infrastructure changes are intentional, reviewable, testable, recoverable, and understandable — not merely when cloud resources can be created automatically.

phase-1

Define the IaC operating model before standardizing tools. Tool choice should follow organizational needs, not popularity — and the operating model determines which tool can even work.

phase-2

State is sensitive infrastructure data. Marking a variable sensitive does not stop a provider from writing generated credentials, connection strings, or private keys into state.

phase-2

Permanent pipeline credentials are a standing compromise waiting to happen. Short-lived federated identity scoped by repository, branch, and environment is both safer and easier to govern.

phase-3

A plan is not proof that a change is safe. It reveals what the provider will do — including replacement and destruction — but a valid plan can still deploy an insecure or operationally harmful design.

phase-3

Do not automatically overwrite drift. The environment may contain an approved emergency correction the code does not yet represent; reverting a commit is not the same as restoring deleted data.

tactical

Prefer a few strong modules with secure defaults over a large uncontrolled catalog — a consumer should not have to remember every baseline control.

The Journey

Three phases; each lists the tools you'll use there.

Define the Operating Model

Establish objectives, principles, tool strategy, ownership boundaries, and repository and module architecture before building anything.

Gather cloud architecture, standards, inventories, and constraints
Define IaC objectives and core principles
Select the approved tool or tools against organizational needs
Choose an operating model and assign responsibility boundaries
Design the repository, module, and environment architecture

Prerequisites Checklist IaC Design and Review Prompt Pack

Harden the Delivery Chain

Protect state, replace permanent credentials, pin dependencies, and enforce security and policy controls in CI.

Design state separation, protection, locking, and recovery
Implement short-lived pipeline identities and least-privilege roles
Pin provider, module, action, and tool versions
Add secret scanning, security scanning, and policy-as-code
Review public modules and supply-chain risk

IaC Design and Review Prompt Pack current-state-findings-example risk-register-example

Standardize Deployment and Manage Drift

Establish plan review, destructive-change controls, drift management, and recovery so the environment stays consistent and auditable.

Design CI and production deployment pipelines with plan comparison
Require human approval for destructive and high-risk changes
Establish drift detection, classification, and reconciliation
Plan rollback, recovery, and the bootstrap process
Run the validation checklist and set the review cadence

Validation Checklist iac-maturity-model implementation-roadmap-example

What's Inside the Execution Layer

Numbered deliverables grouped by phase. Membership unlocks every tool.

🔒 The full execution layer — every checklist, matrix, and the prompt pack — is included with ABME membership.

Unlock Full Blueprint

Full Playbook

Overviewpublic

Infrastructure-as-Code, commonly abbreviated as IaC, is the practice of defining, provisioning, changing, and governing infrastructure through machine-readable, version-controlled code.

Infrastructure-as-Code can manage:

Cloud accounts, subscriptions, and projects
Resource groups
Virtual networks
Subnets
Routing
Firewalls
Security groups
Load balancers
Compute
Containers
Kubernetes clusters
Databases
Storage
Identity roles
Policies
Logging
Monitoring
Backup
Budgets
Tags
Application platform services

Infrastructure-as-Code is not merely a faster way to create cloud resources. When implemented correctly, it becomes:

The approved definition of infrastructure
A repeatable deployment mechanism
A change-control record
A policy-enforcement point
A security-validation mechanism
A disaster-recovery capability
A documentation source
A governance control
A platform-product interface

Poor Infrastructure-as-Code can create a different form of infrastructure risk. Common issues include:

Monolithic templates
Hard-coded values
Embedded secrets
Excessive permissions
Uncontrolled modules
State-file exposure
Manual changes outside code
Inconsistent environments
Untested destructive changes
Poor versioning
Fragile dependencies
No rollback strategy
Provider-version drift
Inadequate review
Missing ownership

The objective is not to convert every cloud action into code immediately. The objective is to create an infrastructure delivery system that is repeatable, reviewable, secure, testable, modular, governed, recoverable, observable, and maintainable.

This workflow uses AI to help design an Infrastructure-as-Code operating model, create repository structures, develop modules, define delivery pipelines, identify security controls, generate tests, plan state management, manage drift, and establish governance.

The central question is: “How should cloud infrastructure be expressed, reviewed, tested, deployed, and maintained as code so that environments remain consistent, secure, and supportable?”

Business Problempublic

Organizations frequently adopt Infrastructure-as-Code by allowing individual teams to choose tools and create templates independently. This can lead to:

Duplicate modules
Inconsistent naming
Inconsistent tagging
Different network patterns
Different security controls
Different state-management approaches
Unapproved providers
Hard-coded environment values
Long-lived credentials in pipelines
Unclear module ownership
Unreliable deployments
Production drift
Difficult upgrades
Slow incident recovery
Repeated architecture mistakes

Other organizations over-centralize IaC and create:

Large platform bottlenecks
Slow approval processes
Inflexible modules
Poor developer experience
Excessive abstraction
Modules that expose too few capabilities
Teams bypassing standards to deliver work

A mature IaC model balances central governance, team autonomy, reusable platform capabilities, security, delivery speed, and operational clarity.

Typical Use Casespublic

Use this workflow when:

Building a cloud landing zone
Automating cloud environment provisioning
Standardizing infrastructure deployment
Creating reusable cloud modules
Migrating manual infrastructure into code
Designing an IaC repository
Creating a cloud deployment pipeline
Implementing policy-as-code
Reviewing Terraform or Bicep architecture
Preparing infrastructure for production
Building ephemeral environments
Automating disaster recovery
Enforcing naming and tagging standards
Managing multi-account or multi-subscription environments
Improving cloud change control
Detecting configuration drift
Creating self-service infrastructure
Building an internal developer platform
Reviewing a failed IaC implementation
Preparing for an audit
Standardizing cloud-provider deployment patterns

Do NOT Use This Workflow Whenpublic

This workflow is not intended to:

Generate production infrastructure without human review
Store secrets directly in code
Place credentials in state files intentionally
Replace architecture review
Replace cloud security review
Replace provider documentation
Assume generated code is syntactically or operationally correct
Apply destructive changes automatically without safeguards
Import every legacy resource into code without evaluating value
Build abstractions before requirements are understood
Use one enormous module for an entire enterprise
Treat IaC as complete configuration management
Treat a successful deployment as proof of application readiness
Bypass change management for high-risk production changes
Assume rollback is always possible
Use untrusted public modules without review
Allow production deployment from unprotected branches
Expose sensitive plan or state data to unauthorized users

All generated infrastructure code, policies, tests, and pipelines require qualified technical review and controlled validation.

Expected Outcomepublic

After completing this workflow, you should have:

IaC objectives
Tool-selection rationale
Operating model
Repository strategy
Module architecture
Environment strategy
State-management design
Variable and configuration strategy
Secret-management approach
Identity and access model
Branching and versioning model
CI/CD pipeline design
Validation and testing strategy
Policy-as-code design
Security controls
Drift-management process
Import and adoption strategy
Release-management process
Rollback and recovery strategy
Documentation standards
Governance framework
Responsibility matrix
Implementation roadmap
Metrics
Risk register
Comprehensive AI prompts

🔒 The complete playbook — reference models, worked examples, and operational guidance — is included with ABME membership.

Unlock Full Blueprint

Objectives and Principlesprotected

Infrastructure-as-Code Objectives

A successful IaC program should answer:

Which infrastructure must be managed as code?
Which IaC tool or tools are approved?
Who owns shared modules?
Who owns workload deployments?
How are environments separated?
How is state protected?
How are secrets handled?
How are provider identities authenticated?
How are modules versioned?
How are breaking changes communicated?
How are plans reviewed?
Which tests must pass?
Which policies must be enforced?
How are destructive changes controlled?
How is drift detected?
How are manual emergency changes reconciled?
How are existing resources imported?
How is rollback handled?
How is recovery performed if the IaC platform is unavailable?
How is developer experience measured?
How are cost implications reviewed?
How is production evidence retained?

Core Principles

Recommended IaC principles include:

Code is the authoritative desired state.
Changes are reviewed before deployment.
Environments are reproducible.
Secrets are retrieved securely at runtime.
Modules have clear ownership.
Modules expose intentional interfaces.
Production changes are traceable.
Destructive actions receive additional review.
State is encrypted and access-controlled.
Pipelines use short-lived identities.
Policies are automated where practical.
Tests are proportional to risk.
Manual changes are exceptional and reconciled.
Provider and module versions are controlled.
Deployment evidence is retained.
Simplicity is preferred over premature abstraction.

Tooling and Operating Modelprotected

Declarative and Imperative Approaches

Tool Selection

Evaluate tools based on:

Supported providers
Existing workforce skills
Multi-cloud requirements
State management
Module ecosystem
Policy integration
Testing support
CI/CD support
Vendor support
Licensing
Community maturity
Provider feature coverage
Import capability
Drift detection
Execution model
Security
Cost
Long-term maintainability

Native and Cross-Platform Tools

IaC Operating Model

Responsibility Boundaries

Define ownership for:

Cloud foundation
Resource hierarchy
Identity
Network
Security controls
Shared services
Workload infrastructure
Application deployment
Modules
Pipelines
State
Policies
Tests
Documentation
Drift
Incident response

Repository and Module Architectureprotected

Repository Strategy

Example Repository Structure

infrastructure/
├── modules/
│   ├── network/
│   ├── compute/
│   ├── database/
│   ├── monitoring/
│   └── backup/
├── environments/
│   ├── development/
│   ├── test/
│   ├── staging/
│   └── production/
├── policies/
├── tests/
├── scripts/
├── docs/
├── examples/
├── .github/
└── README.md

A larger federated model may separate reusable modules from environment implementations.

Module Architecture

A module should represent a cohesive infrastructure capability. Examples:

Secure storage account
Standard virtual network
Application hosting platform
Managed database
Kubernetes cluster
Logging integration
Backup policy
Workload landing zone

Avoid modules that are:

Too small to provide meaningful value
Too large to understand safely
Highly coupled to unrelated services
Filled with optional flags for every conceivable scenario
Impossible to upgrade independently

Module Design Principles

Modules should provide:

Clear purpose
Clear inputs
Clear outputs
Secure defaults
Required tagging
Validation
Documentation
Examples
Versioning
Ownership
Upgrade guidance
Known limitations

Secure Defaults

Modules should enable approved defaults such as:

Encryption
Logging
Private networking
Backup
Monitoring
Managed identity
Minimum TLS
Public-access restrictions
Required tags
Diagnostic settings

A consumer should not need to remember every baseline control.

Module Interfaces

Inputs should be intentional, typed, validated, documented, and stable where practical. Outputs should expose only what downstream consumers require. Avoid exposing internal implementation details unnecessarily.

Variable Design

Classify variables as:

Required
Optional
Environment-specific
Sensitive
Computed
Derived
Provider-specific

Avoid:

Hard-coded subscriptions
Hard-coded account IDs
Hard-coded regions
Hard-coded resource names
Hard-coded credentials
Excessive boolean switches
Unvalidated free-form values

Naming

Naming should be deterministic, consistent, provider-compatible, collision-resistant, understandable, and automated. Inputs may include organization, workload, environment, region, resource type, and instance number. Do not make names so compressed that operators cannot understand them.

Tagging and Labeling

Modules should apply required metadata such as:

Business owner
Technical owner
Workload
Environment
Cost center
Data classification
Criticality
Managed by
Repository
Expiration
Compliance scope

Tagging rules should be validated in code and policy.

Environments and Stateprotected

Environment Strategy

Common approaches include:

Separate directories
Separate state
Separate repositories
Separate accounts or subscriptions
Separate workspaces
Parameterized deployments

Production and nonproduction should have appropriate isolation. Avoid relying solely on a variable such as environment = "production" to provide security separation.

Environment Promotion

A promotion model may use:

Module development
Module test
Module release
Development deployment
Integration testing
Staging deployment
Production plan
Production approval
Production deployment
Post-deployment validation

Promotion should reuse tested module versions rather than copy and modify code manually.

State Management

State may contain:

Resource identifiers
Configuration values
Dependency data
Provider metadata
Sensitive values
Generated secrets

State must be treated as sensitive infrastructure data.

State Protection

Protect state using:

Encryption at rest
Encryption in transit
Access control
Versioning
Locking
Backup
Audit logging
Private connectivity
Separation by environment
Recovery procedures

State Separation

Separate state based on:

Environment
Workload
Ownership
Blast radius
Deployment cadence
Security boundary
Recovery boundary

A single enterprise-wide state file creates excessive risk. Too many tiny state files create dependency and operational complexity.

State Locking

State locking prevents simultaneous conflicting changes. Validate:

Lock acquisition
Lock timeout
Stale-lock recovery
Emergency unlock authority
Audit evidence

Manual state unlock should be controlled.

State Recovery

Document:

State backup
Version recovery
Corruption response
Lock recovery
Import procedures
Resource reconciliation
Emergency contacts
Validation

Never edit state manually without a controlled, reviewed procedure.

Sensitive Values in State

Some providers and resources may write sensitive values into state even when variables are marked sensitive. Assess:

Provider behavior
Resource outputs
Generated credentials
Certificates
Connection strings
Database passwords
Private keys

Avoid creating secrets through IaC where the resulting secret must be stored in state unless the risk is understood and controlled.

Identity, Secrets, and Dependenciesprotected

Secret Management

Secrets should be:

Stored in an approved secret-management platform
Retrieved at deployment or runtime
Access-controlled
Rotated
Audited
Excluded from source control
Excluded from logs
Excluded from plan artifacts where practical

Pipeline Identity

Pipelines should use:

Workload identity federation
Managed identity
OpenID Connect federation
Short-lived credentials
Scoped service principals or roles

Avoid:

Permanent access keys
Shared administrator accounts
Credentials stored in repository secrets indefinitely
Excessive cross-environment permissions

Least-Privilege Deployment Roles

Deployment permissions should be scoped by:

Environment
Subscription or account
Resource type
Action
Repository
Pipeline
Branch
Approval state

Separate planning permission from deployment permission where appropriate.

Provider Configuration

Control:

Provider versions
Provider aliases
Regions
Subscriptions
Accounts
Projects
Authentication
Feature flags
Retry behavior

Pin provider versions within an intentional range and test upgrades.

Dependency Locking

Lock:

Provider versions
Module versions
Action versions
Container images
Tool versions
Policy packages

Uncontrolled dependency updates can introduce unexpected infrastructure changes.

Module Sources

Module sources may include internal registries, approved Git repositories, provider registries, public registries, and local modules. Public modules require review for:

Security
Maintenance
Licensing
Versioning
Ownership
Supply-chain risk
Default behavior

Versioning

Use semantic or equivalent versioning. Example:

Major version: breaking interface or behavior
Minor version: backward-compatible capability
Patch version: backward-compatible fix

Versioning should communicate consumer impact.

Module Release Process

A module release should include:

Code review
Static validation
Security scanning
Unit or component tests
Example deployment
Documentation
Change log
Version tag
Upgrade notes
Deprecation notice where applicable

Breaking Changes

Breaking changes may include:

Renamed variables
Removed outputs
Changed defaults
Resource replacement
Changed naming
Changed network behavior
Changed encryption
Changed identity model
State movement

Provide migration guidance before consumers upgrade.

Pipelines, Review, and Approvalprotected

Continuous Integration

A typical validation pipeline may perform:

Formatting
Initialization
Syntax validation
Linting
Static security scanning
Policy validation
Documentation validation
Unit testing
Cost estimation
Plan generation
Plan artifact retention
Review status reporting

Continuous Deployment

A deployment pipeline may perform:

Confirm approved source revision.
Confirm module versions.
Authenticate with short-lived identity.
Acquire state lock.
Generate final plan.
Compare final plan to approved plan.
Require environment approval.
Apply changes.
Capture outputs.
Run post-deployment tests.
Publish evidence.
Release state lock.
Notify owners.

Pull Request Review

Reviewers should evaluate:

Architecture
Security
Resource replacement
Network exposure
Identity changes
Data impact
Cost
Naming
Tagging
Module usage
Provider changes
State changes
Test evidence
Rollback
Documentation

Plan Review

A plan should be reviewed for:

Resources created
Resources modified
Resources destroyed
Replacement actions
Permission changes
Public exposure
Route changes
Data-service changes
Backup changes
Logging changes
Cost impact
Unexpected drift

A plan is not proof that a change is safe.

Plan Artifacts

Plan artifacts may contain sensitive information. Protect them through:

Restricted access
Short retention
Encryption
Audit logging
Redaction where possible
Controlled download
No public build logs

Human Approval

Require explicit approval for:

Production changes
Resource destruction
Database replacement
Network-boundary changes
Identity and permission changes
Encryption-key changes
State operations
Provider major upgrades
Policy exceptions
High-cost resources

Automated Approval

Low-risk changes may qualify for automation when:

Module is approved.
Environment is nonproduction.
No destructive action exists.
Policy checks pass.
Cost remains below threshold.
Security posture is unchanged.
Tests pass.
Ownership is clear.

Automation thresholds should be documented.

Testing and Validationprotected

Testing Strategy

Testing may include:

Formatting tests
Syntax tests
Linting
Static security tests
Policy tests
Unit tests
Contract tests
Integration tests
Deployment tests
Destruction tests
Recovery tests
Compliance tests
Cost tests
Post-deployment tests

Static Validation

Static validation can identify:

Syntax errors
Deprecated syntax
Missing variables
Unused variables
Insecure configurations
Public exposure
Missing encryption
Missing logging
Unpinned dependencies
Policy violations

Static validation cannot prove runtime behavior.

Module Unit Tests

Module tests should validate:

Required resources
Default settings
Input validation
Conditional behavior
Naming
Tagging
Outputs
Security defaults
Invalid-input rejection

Integration Testing

Deploy modules to isolated test environments and validate:

Provider behavior
Resource creation
Service availability
Network connectivity
Identity
Logging
Monitoring
Encryption
Backup
Destruction
State behavior

Destruction Testing

Validate that test resources can be safely removed. Assess:

Deletion protection
Retention
Orphaned resources
Dependencies
State cleanup
Data preservation
Cost cleanup

Do not test destructive procedures against production.

Post-Deployment Validation

Validate:

Resource health
Configuration
Policy compliance
Monitoring
Logging
Connectivity
Identity
Backup
Cost allocation
Application integration

Policy and Securityprotected

Policy-as-Code

Policy-as-code can enforce:

Allowed regions
Allowed resource types
Required encryption
Required tags
Public-access restrictions
Network restrictions
Approved images
Minimum TLS
Backup requirements
Logging requirements
Cost thresholds
Naming standards

Preventive and Detective Policy

Policy Exceptions

Each exception should include:

Exception ID
Control
Business justification
Risk
Compensating control
Owner
Approver
Start date
Expiration date
Review date
Remediation plan

Exceptions should be visible and time-bound.

Security Scanning

Scan IaC for:

Public exposure
Weak encryption
Excessive permissions
Insecure protocols
Missing logging
Missing backup
Insecure Kubernetes settings
Embedded secrets
Untrusted modules
Vulnerable pipeline components

Scanner findings require context and validation.

Secret Scanning

Secret scanning should cover:

Source code
Commit history
Pull requests
Pipeline logs
Plan artifacts
State-related scripts
Documentation
Example files

If a secret is committed, removing it from the latest version is insufficient. Rotate the secret and address repository history as required.

Supply-Chain Security

Assess:

Module source
Provider source
Dependency signatures
Checksums
Action versions
Container images
Registry security
Maintainer trust
Release provenance
Dependency scanning

Pin external CI/CD actions to reviewed versions or immutable references where appropriate.

Drift and Manual Changeprotected

Drift Management

Drift occurs when actual infrastructure differs from the desired code. Common causes include:

Manual changes
Emergency remediation
Provider defaults
External controllers
Automated cloud services
Incomplete imports
Failed deployments
Portal-based changes

Drift Detection

Drift detection may run:

On every pull request
Before deployment
Daily
Weekly
After incidents
After emergency changes
After provider maintenance

Drift Classification

Drift Response

For each drift finding determine:

Resource
Difference
Cause
Owner
Risk
Correct source of truth
Immediate action
Code update
Infrastructure update
Incident requirement
Validation
Closure evidence

Do not automatically overwrite all drift. The code may be outdated, and the actual environment may contain an approved emergency correction.

Manual Change Process

Manual changes may be necessary during incidents. The process should require:

Incident or change record
Named owner
Reason
Scope
Evidence
Expiration
IaC reconciliation
Review
Closure

Adoption and Refactoringprotected

Importing Existing Infrastructure

Before import:

Inventory resources.
Confirm ownership.
Confirm desired disposition.
Review security.
Review naming.
Review dependencies.
Select state boundaries.
Back up state.
Test import in nonproduction where possible.
Define reconciliation steps.

Importing a resource does not automatically produce maintainable configuration.

Adoption Strategies

Resource Refactoring

IaC refactoring may include:

Moving resources between modules
Renaming resource blocks
Splitting state
Consolidating state
Changing module sources
Introducing for_each
Reorganizing directories
Replacing legacy modules

Refactoring must preserve resource identity where intended. Test state moves carefully.

Destructive Changes, Rollback, and Recoveryprotected

Destructive Change Management

Destructive changes may result from:

Resource renaming
Immutable property changes
Module refactoring
Provider behavior
Lifecycle changes
State mismatch
Configuration removal

Controls may include:

Deletion protection
Lifecycle rules
Plan inspection
Separate approvals
Maintenance window
Backup
Recovery test
Manual confirmation
Staged migration

Rollback Strategy

IaC rollback is not always equivalent to reverting a code commit. A previous configuration may not restore:

Deleted data
Destroyed databases
Changed schemas
Rotated keys
External integrations
Identity sessions
Provider-side changes

Define:

Code rollback
Infrastructure rollback
Data recovery
State recovery
Forward-fix criteria
Decision authority
Maximum rollback window

Recovery of the IaC Platform

Plan for failure of:

Source repository
CI/CD platform
State backend
Secret store
Artifact store
Module registry
Identity provider
Cloud control plane
Policy engine

Maintain:

Repository backups
State backups
Emergency access
Tool bootstrap instructions
Provider authentication recovery
Dependency mirrors where required
Manual recovery runbooks

Bootstrap Problem

Some resources required to deploy IaC may themselves be managed by IaC. Examples:

State backend
Pipeline identity
Key vault
Module registry
Logging
Policy assignment

Define a controlled bootstrap process with minimal dependencies and strong documentation.

Boundaries and Multi-Cloudprotected

Multi-Cloud IaC

A multi-cloud strategy should determine:

Shared standards
Provider-specific modules
Common pipeline model
Separate state
Separate identities
Common policy language
Provider-native exceptions
Skills
Support ownership

Avoid forcing identical abstractions over materially different provider capabilities.

Kubernetes Infrastructure-as-Code

Define management boundaries for:

Cloud infrastructure
Kubernetes cluster
Node pools
Add-ons
Helm releases
Namespaces
Network policies
Admission policies
Secrets
Application manifests

Avoid circular ownership between cluster provisioning and in-cluster tooling.

Configuration Management Boundary

IaC generally manages infrastructure resources. Configuration management may manage:

Operating-system settings
Package installation
Application configuration
Local users
Service configuration
Runtime state

Define which tool owns each layer.

Application Deployment Boundary

Separate:

Infrastructure deployment
Platform configuration
Application deployment
Database migration
Feature release

These may use different pipelines and approval models.

Cost, Documentation, and Observabilityprotected

Cost Management

Integrate cost review into IaC. Evaluate:

Estimated monthly cost
Cost increase
High-cost resources
Data-transfer impact
Backup cost
Logging cost
Reserved-capacity assumptions
Test-environment cleanup
Resource expiration

Cost Policy

Potential controls include:

Cost estimate required on pull requests
Approval above threshold
Sandbox expiration
Approved service tiers
Budget tags
Environment schedules
High-cost resource review

Cost tools provide estimates, not invoices.

Documentation Standards

Each repository should include:

Purpose
Ownership
Architecture
Prerequisites
Authentication
Tool versions
Directory structure
Deployment steps
Variables
Outputs
Examples
Testing
State details
Recovery
Troubleshooting
Support
Change process

Generated Documentation

Documentation may be generated from variable descriptions, output descriptions, module metadata, provider requirements, test results, and architecture definitions. Generated documentation should supplement—not replace—operational guidance.

Change Records and Evidence

Retain:

Pull request
Review approvals
Plan
Policy results
Security scan
Cost estimate
Deployment log
Post-deployment validation
Incident references
Exception references
Release version

Retention should align with audit and operational requirements.

Observability

Monitor the IaC delivery system itself. Track:

Pipeline success
Pipeline duration
Plan failures
Apply failures
Policy failures
Drift findings
State-lock failures
Provider errors
Module adoption
Deployment frequency
Rollback frequency
Manual changes
Security findings
Cost-estimate variance

IaC Maturity Modelprotected

Level 1 — Scripted

Individual scripts
Limited version control
Manual execution
Minimal testing

Level 2 — Repeatable

Standard tools
Version control
Basic modules
Remote state
Manual approvals

Level 3 — Governed

Shared modules
CI/CD
Policy checks
Security scanning
Environment separation
Drift detection

Level 4 — Productized

Self-service platform
Strong developer experience
Versioned modules
Automated testing
Cost visibility
Measured service levels

Level 5 — Optimized

Continuous compliance
Risk-based automation
Automated remediation
Strong supply-chain security
Data-driven improvement

Governanceprotected

Define standards for:

Approved IaC tools
Approved versions
Repository ownership
Module ownership
Module publishing
Public module use
State backends
State access
Pipeline identity
Environment separation
Branch protection
Required reviews
Security scanning
Policy enforcement
Cost review
Production approval
Drift handling
Manual changes
Import
Destructive changes
Exceptions
Documentation
Evidence retention
Deprecation
Recovery

Worked Examplesprotected

Example IaC Program Input

Organization: A regulated enterprise operating in Azure and AWS.

Current State:

Terraform is used by several teams.
Bicep is used by the Azure platform team.
State backends differ by team.
Some pipelines use permanent credentials.
Production portal changes are common.
Modules are copied between repositories.
No central module registry exists.
Security scanning is inconsistent.
Drift is discovered during deployments.
Public modules are used without formal review.

Objectives:

Standardize infrastructure delivery.
Reduce production drift.
Improve security.
Preserve team autonomy.
Support audit evidence.
Enable self-service workload environments.

Example Current-State Findings

IAC-001 — Permanent Pipeline Credentials

Severity: Critical · Confidence: High

Evidence: Multiple production deployment pipelines use long-lived cloud credentials stored as repository secrets.

Business Impact: Credential compromise could permit unauthorized infrastructure changes across production environments.

Recommendation: Replace permanent credentials with workload identity federation or equivalent short-lived authentication. Restrict access by repository, branch, environment, and role.

IAC-002 — Shared Production State

Severity: High · Confidence: High

Evidence: Unrelated production workloads share one state file.

Technical Impact: A state corruption, lock failure, or erroneous operation could affect multiple business services.

Recommendation: Separate state by workload ownership and blast radius while preserving required dependencies through explicit outputs or data interfaces.

IAC-003 — Manual Production Drift

Severity: High · Confidence: High

Evidence: Production firewall and service configuration changes are regularly performed through the cloud portal and are not reconciled to code.

Recommendation: Establish an emergency-change process, recurring drift detection, ownership, and mandatory reconciliation.

IAC-004 — Unversioned Module Copies

Severity: Medium · Confidence: High

Evidence: Teams copy shared modules into workload repositories and modify them locally.

Operational Impact: Security fixes and improvements cannot be distributed predictably.

Recommendation: Create versioned internal modules with ownership, release notes, examples, and supported upgrade paths.

IAC-005 — Plan Artifacts Expose Sensitive Data

Severity: High · Confidence: Medium

Evidence: Plan output containing resource identifiers and configuration values is retained in broadly accessible build logs.

Recommendation: Restrict plan visibility, reduce retention, prevent sensitive output, and review provider behavior.

Example Target Operating Model

Platform Team owns:

Approved IaC tools
Shared modules
State standards
Pipeline templates
Policy framework
Developer documentation
Platform support

Security Team owns:

Security policies
Critical guardrails
Scanner standards
Exception approval
Security findings

Workload Teams own:

Workload infrastructure definitions
Module consumption
Workload variables
Tests
Deployment evidence
Operational support

Cloud Governance owns:

Standards
Compliance reporting
Exceptions
Maturity measurement
Cross-team reviews

Example CI Pipeline

Pull Request Opened
        │
        ▼
Formatting and Syntax Validation
        │
        ▼
Linting and Secret Scanning
        │
        ▼
Security and Policy Scanning
        │
        ▼
Module and Unit Tests
        │
        ▼
Cost Estimate
        │
        ▼
Infrastructure Plan
        │
        ▼
Plan Summary Posted to Pull Request
        │
        ▼
Required Human Review

Example Production Deployment Pipeline

Approved Merge
      │
      ▼
Authenticate with Short-Lived Identity
      │
      ▼
Acquire State Lock
      │
      ▼
Generate Final Plan
      │
      ▼
Compare with Reviewed Plan
      │
      ▼
Production Approval
      │
      ▼
Apply
      │
      ▼
Post-Deployment Tests
      │
      ▼
Publish Evidence and Notify Owners

Example Risk Register

Risk	Probability	Impact	Mitigation	Owner
State corruption affects production	Low	Critical	State versioning, backup, separation, recovery test	Platform Team
Pipeline credential compromise	Medium	Critical	Federated short-lived identity	Security Team
Module upgrade replaces resources	Medium	High	Versioning, plan review, integration tests	Module Owner
Manual drift overrides secure configuration	High	High	Drift detection and change reconciliation	Workload Owner
Public module introduces supply-chain risk	Medium	High	Approved registry and module review	Platform Security
Policy blocks urgent delivery	Medium	Medium	Time-bound exception process	Governance
IaC rollback fails to restore data	Medium	Critical	Separate data recovery and rollback planning	Workload Team
Provider upgrade changes behavior	Medium	High	Version pinning and test environment	Platform Team
Plan logs expose sensitive values	Medium	High	Restricted artifacts and log controls	DevOps Team
Excessive abstraction slows delivery	Medium	Medium	Module usability review and consumer feedback	Platform Product Owner

Implementation Roadmap

Phase 1 — Establish Standards

Inventory tools
Inventory repositories
Inventory modules
Inventory pipelines
Inventory state backends
Identify long-lived credentials
Define approved tools
Define ownership
Define state standards
Define minimum pipeline controls
Define emergency-change process

Phase 2 — Secure the Delivery Chain

Implement short-lived pipeline identities
Protect state
Implement branch protection
Add secret scanning
Add static security scanning
Add policy checks
Restrict production deployment
Protect plan artifacts
Pin dependencies
Review public modules

Phase 3 — Create Reusable Platform Capabilities

Build internal module registry
Publish priority modules
Add secure defaults
Add tests
Add examples
Add documentation
Establish module release process
Establish support and deprecation process

Phase 4 — Standardize Deployment

Publish pipeline templates
Integrate cost estimates
Require plan review
Add post-deployment validation
Add evidence retention
Implement production approval
Implement destructive-change controls
Train workload teams

Phase 5 — Manage Existing Infrastructure

Detect drift
Classify manual changes
Import suitable resources
Rebuild problematic resources
Split oversized state
Reconcile source of truth
Remove abandoned templates
Reduce portal-based changes

Phase 6 — Productize and Optimize

Add self-service workflows
Measure developer experience
Automate low-risk changes
Improve module adoption
Improve policy feedback
Automate compliance evidence
Test IaC recovery
Continuously refine standards

Metricsprotected

Useful IaC metrics include:

Percentage of cloud resources managed by code
Percentage of production changes deployed through pipelines
Manual production changes
Drift findings
Critical drift findings
Mean time to reconcile drift
Pipeline success rate
Deployment failure rate
Rollback rate
Mean deployment time
Plan-to-apply variance
Destructive changes
Emergency changes
State-lock failures
State-recovery tests
Long-lived pipeline credentials
Security-scan findings
Secret-scan findings
Policy violations
Policy exceptions
Module adoption
Module upgrade age
Module test coverage
Provider-version age
Cost estimate variance
Post-deployment validation success
Developer satisfaction
Time to provision an environment
Audit-evidence completeness

Suggested Review Cadenceprotected

Every Commit or Pull Request

Review:

Formatting
Syntax
Linting
Security
Secrets
Policy
Tests
Cost
Plan

Every Deployment

Review:

Final plan
Approval
State lock
Apply result
Post-deployment validation
Evidence

Daily or Weekly

Review:

Drift
Pipeline failures
Policy violations
State health
Security findings
Expired exceptions

Monthly

Review:

Module adoption
Manual changes
Provider versions
Cost-estimate accuracy
Deployment metrics
State boundaries
Developer feedback

Quarterly

Review:

IaC standards
Public dependencies
Module roadmaps
Policy effectiveness
Access permissions
Recovery procedures
Maturity progress

Annually

Review:

Tool strategy
Operating model
Licensing
Platform architecture
Supply-chain strategy
Major module redesign
Recovery exercise

After a Significant Event

Review immediately after a significant IaC incident, state event, credential compromise, provider upgrade failure, or destructive deployment.

Automation Opportunitiesprotected

Repository generation
Module scaffolding
Variable documentation
Output documentation
Test generation
Security scanning
Policy generation
Cost estimation
Plan summarization
Destructive-change detection
Drift analysis
Module upgrade analysis
State inventory
Import planning
Release-note generation
Evidence collection
Compliance reporting
A mature automated IaC platform could accept an approved infrastructure request, recommend an approved module, generate a workload-specific implementation, validate naming and tagging, run security and policy checks, estimate cost, generate and summarize a plan, highlight destructive changes, route approvals by risk, deploy through short-lived identity, run post-deployment tests, publish evidence, detect drift continuously, route exceptions and remediation, and measure delivery performance and developer experience.

Pro Tipsprotected

Define the IaC operating model before standardizing tools.
Treat code as the desired state, not as unquestionable truth.
Separate state according to ownership and blast radius.
Protect state as sensitive infrastructure data.
Use short-lived pipeline identities.
Avoid embedding secrets in code or generated artifacts.
Create secure defaults in reusable modules.
Keep module interfaces intentional.
Prefer a few strong modules over a large uncontrolled catalog.
Version modules and publish upgrade guidance.
Pin provider and pipeline dependencies.
Review actual plans, not only source code.
Highlight replacements and destructive changes.
Require additional approval for destructive production changes.
Test modules in isolated environments.
Test destruction and recovery procedures.
Add policy checks with useful remediation messages.
Build an exception process before enforcing every control.
Detect drift continuously.
Reconcile emergency changes quickly.
Do not automatically overwrite unexplained drift.
Include cost estimates in pull requests.
Retain deployment evidence.
Back up source, state, and critical platform dependencies.
Measure developer experience as well as control compliance.
Require qualified human review of AI-generated code and recommendations.

Common Mistakesprotected

Treating IaC as a one-time conversion project — Infrastructure-as-Code requires continuous ownership, testing, maintenance, and governance.
Using one state file for everything — this increases blast radius and complicates ownership.
Creating too many state files — excessive fragmentation creates dependency and operational overhead.
Storing secrets in variables — sensitive variables may still appear in state or provider operations.
Using permanent pipeline credentials — short-lived federated identity is safer and easier to govern.
Copying modules between repositories — copied modules become unversioned, inconsistent forks.
Creating a giant universal module — excessive abstraction reduces usability and increases risk.
Making modules too small — tiny modules may add complexity without meaningful governance or reuse.
Trusting public modules automatically — public availability does not establish security, maintenance, or suitability.
Failing to pin dependencies — unexpected upgrades can change deployment behavior.
Reviewing code but not the plan — the plan reveals actual provider actions, including replacement and destruction.
Treating the plan as proof of safety — a valid plan can still deploy an insecure or operationally harmful design.
Applying a different plan than the one reviewed — generate or verify the final production plan after approval and before deployment.
Auto-applying destructive production changes — high-risk replacements and deletions require additional controls.
Assuming code revert equals rollback — deleted data and changed external systems may not be recoverable through code.
Ignoring state recovery — the IaC system depends on state availability and integrity.
Editing state manually — manual state changes can create severe inconsistencies.
Overwriting drift automatically — the environment may contain an approved emergency fix that the code does not yet represent.
Allowing manual changes without reconciliation — temporary changes become permanent hidden configuration.
Importing everything without a strategy — some legacy resources should be rebuilt, retained temporarily, or retired.
Ignoring cost in pull requests — infrastructure code creates recurring financial commitments.
Logging full plans publicly — plan output may contain sensitive infrastructure data.
Treating IaC as configuration management — infrastructure and operating-system configuration require clear tool boundaries.
Ignoring developer experience — teams bypass processes that are too slow, unclear, or difficult.
Using AI-generated IaC without testing — generated code may contain incorrect resource types, unsafe defaults, outdated syntax, excessive permissions, or destructive lifecycle behavior.

Security Considerationsprotected

Infrastructure code and related artifacts may expose account identifiers, subscription identifiers, project identifiers, resource names, network ranges, DNS names, identity roles, permission models, firewall rules, internal architecture, state data, connection information, provider configuration, security-control details, and recovery design.
Before sharing IaC with an AI system, remove credentials.
Remove tokens.
Remove access keys.
Remove private keys.
Remove active connection strings.
Remove state files unless securely sanitized.
Remove sensitive plan output.
Sanitize account and network details where required.
Confirm the AI platform is approved.
Confirm retention and model-training settings.
Follow source-code classification requirements.
Follow vulnerability-disclosure procedures.
Restrict distribution of generated analysis.
Do not apply generated IaC directly to production.

Brian Diamond

Founder, BrianOnAI

Twenty-five years designing, operating, and governing enterprise infrastructure — from MSP operations across dozens of client environments to enterprise infrastructure leadership. This blueprint codifies the operating model he's implemented in production, not theory.

Related Blueprints

Assess Cloud Readiness and Select a Migration Strategy Design a Secure Cloud Landing Zone Design Cloud Identity and Access Controls Design Cloud Network Architecture Estimate and Optimize Cloud Costs Plan and Execute a Cloud Workload Migration Design Cloud Backup and Disaster Recovery Review Cloud Security and Configuration Prepare a Cloud Workload for Production

⚠ Normalization Warnings — 10 for review

This document has ~60 domain H1 sections. They were consolidated into thematic body GROUPS (Objectives and Principles, Tooling and Operating Model, Repository and Module Architecture, Environments and State, Identity/Secrets/Dependencies, Pipelines/Review/Approval, Testing and Validation, Policy and Security, Drift and Manual Change, Adoption and Refactoring, Destructive/Rollback/Recovery, Boundaries and Multi-Cloud, Cost/Docs/Observability, Worked Examples) to avoid a flat 50+ section page. Grouping is editorial — confirm the theme boundaries.
RESTRUCTURE: 'Primary Prompt' and 'Follow-Up Prompts' (two source H1s plus 24 H2 follow-ups) combined into one prompt_pack tool with 25 prompts; 'when' guidance lines are editorial additions, prompt text verbatim (including the source's run-together formatting).
CLASSIFICATION TO CONFIRM: 'Prerequisites' classified as a checklist TOOL (gather-before-start items are completable). Alternative: body/prose.
CLASSIFICATION: 'Validation Checklist' is a clear checklist tool with seven heading groups preserved verbatim.
CLASSIFICATION: Several tiered/optioned sections classified as reference (Declarative/Imperative, Native/Cross-Platform, Operating Model, Repository Strategy, Preventive/Detective Policy, Drift Classification, Adoption Strategies, IaC Maturity Model, Suggested Review Cadence). These are consulted, not completed. Review Cadence is borderline between reference and a checklist tool — filed as reference per the consult-vs-complete rule; confirm.
CLASSIFICATION: The 'Example ...' sections (program input, current-state findings, target operating model, CI pipeline, production pipeline, risk register, implementation roadmap) classified as body/example and grouped under 'Worked Examples'. The Implementation Roadmap here is a worked EXAMPLE roadmap tied to the sample scenario, so it was kept as example rather than promoted to playbook.roadmap — confirm.
ASCII diagram code blocks (repository structure, CI pipeline, production pipeline) preserved verbatim in <pre><code> with language 'text'. The repository structure in the source was run together on one line; it was reconstructed into the intended tree layout — confirm fidelity.
Risk register rendered as an HTML table inside the example section (verbatim rows).
STATS: prompts=25 (1 primary + 24 follow-ups); deliverables=7 (prerequisites-checklist, iac-design-prompt-pack, validation-checklist counted as tools plus worked-example artifacts are not counted as deliverables). Confirm deliverable count convention.
No Quick Wins section present; playbook.quick_wins and roadmap intentionally empty. Common Mistakes, Security Considerations, Automation Opportunities, and Pro Tips mapped to playbook flat lists (each source subsection collapsed into a single item combining heading + explanation).

SEO Block

Title tag: Build Cloud Infrastructure-as-Code | ABME (41 chars)
Meta: Design a secure, governed Infrastructure-as-Code operating model: modules, state protection, short-lived pipeline identities, policy-as-code, and drift management. (163 chars)
Schema: HowTo · noindex: false
Related: cl-001, cl-002, cl-003, cl-004, cl-005, cl-006, cl-007, cl-008, cl-010
Keywords: infrastructure as code, terraform operating model, iac governance, state management terraform, policy as code, iac drift management, short-lived pipeline identity, reusable terraform modules, iac ci/cd pipeline, cloud landing zone iac

Copied

Stop Every Team from Inventing Its Own Cloud — Build IaC That's Governed, Recoverable, and Drift-Resistant

Executive Brief

Your Challenge

Common Obstacles

The ABME Approach

Insight Summary

The Journey

Define the Operating Model

Harden the Delivery Chain

Standardize Deployment and Manage Drift

What's Inside the Execution Layer

Prerequisites Checklist

IaC Design and Review Prompt Pack

Primary Prompt

Select an IaC Tool

Design an IaC Repository

Design a Reusable Module

Review an IaC Module

Design State Management

Review IaC State Risk

Design an IaC CI Pipeline

Design a Production Deployment Pipeline

Create Policy-as-Code Controls

Review an IaC Plan

Detect Destructive Changes

Create an IaC Test Strategy

Create Module Tests

Review Pipeline Identity

Create a Drift-Management Process

Analyze Drift

Import Existing Resources

Refactor IaC Safely

Review Public Modules

Create a Module Versioning Policy

Design IaC Recovery

Add Cost Controls

Validation Checklist

Strategy

Repository

Modules

State

Identity and Secrets

CI/CD

Governance

Full Playbook

Overviewpublic

Business Problempublic

Typical Use Casespublic

Do NOT Use This Workflow Whenpublic

Expected Outcomepublic

Objectives and Principlesprotected

Infrastructure-as-Code Objectives

Core Principles

Tooling and Operating Modelprotected

Declarative and Imperative Approaches

Tool Selection

Native and Cross-Platform Tools

IaC Operating Model

Responsibility Boundaries

Repository and Module Architectureprotected

Repository Strategy

Example Repository Structure

Module Architecture

Module Design Principles

Secure Defaults

Module Interfaces

Variable Design

Naming

Tagging and Labeling

Environments and Stateprotected

Environment Strategy

Environment Promotion

State Management

State Protection

State Separation

State Locking

State Recovery

Sensitive Values in State

Identity, Secrets, and Dependenciesprotected

Secret Management