AWS / Intermediate: application service contracts / Lesson 12

Infrastructure as code and change review

Use templates, change evidence, ownership, and recovery policy to reason about infrastructure effects without provisioning any resource.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the assumptions, responsibilities, and trade-offs of infrastructure as code and change review.
Interpret both examples and distinguish declared intent from verified evidence.
Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.

A template describes effectful intent

CloudFormation models resources and orchestrates supported creation and update workflows. A small template edit can replace storage, alter access, or change network exposure. AWS CDK and other tools introduce their own synthesis and dependency contracts and do not make those effects harmless. Record account, Region, stack, artifact identity, template, parameters, and role before real authorization. The first example is a non-runnable CloudFormation teaching template for a bucket with explicit retention attributes. Parsing YAML proves only syntax, not service acceptance, permission, secure operation, or a free deployment. No template is submitted.

yaml Illustrative CloudFormation retention template

AWSTemplateFormatVersion: "2010-09-09"
Description: Non-runnable synthetic S3 retention example
Resources:
  LabBucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true
      VersioningConfiguration: {Status: Enabled}
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault: {SSEAlgorithm: AES256}

The format version is a template-language identifier. If deployed this could create chargeable retained resources, so it remains non-runnable; retention and versioning do not prove backup or complete security.

Review proposed change and actual scope

A change set helps preview selected stack changes, including resource replacement where reported, but is not a guarantee that execution will succeed or that every external consequence is visible. Read the resource-specific update semantics, dependencies, permissions, and quota implications. The second synthetic record blocks storage replacement until data recovery is reviewed. Do not approve solely by counting changed resources; one replacement can dominate risk. Time, configuration, or target changes after review can invalidate assumptions, so bind approval to the exact reviewed inputs and execution context rather than a moving branch or friendly environment label.

yaml Synthetic infrastructure approval record

reviewed_template: lab-template-9
target: approved-account-and-Region-reference
proposed_storage_replacement: true
data_restore_evidence: not-yet-verified
decision: block-until-recovery-and-ownership-review

A single destructive consequence blocks this fictional approval. The record is not a CloudFormation change set, executable policy, or claim that a real plan was inspected.

Understand deletion, replacement, and retention

DeletionPolicy and UpdateReplacePolicy govern different lifecycle situations under supported resource behavior. Retaining a resource does not create a historical backup or remove its costs, and snapshots depend on resource support. A stack rollback can itself fail and cannot undo every external side effect. Identify data ownership, key access, dependencies, and restoration before changes that can destroy or orphan resources. Do not delete a stack or retained resource merely to clear an unexplained status. Keep the required recovery path and accountable decision authority explicit, especially when application writes occurred during partial infrastructure change.

Protect secrets and reconciliation ownership

Do not embed credentials in templates, parameter files, outputs, metadata, source history, or build logs. A masking option is not a universal secret-storage guarantee; use the documented integration and access controls for sensitive references. Drift detection has supported resource and property coverage and is not a complete forensic inventory. Decide whether a manual emergency change should be reconciled into approved desired state or reversed. Multiple tools continuously managing one resource can fight, so keep ownership and exceptions clear. Provider APIs, tool versions, and resource schemas evolve and require compatibility review before reuse.

Validate locally and authorize separately

Useful local checks include syntax, policy logic, parameter contracts, and synthetic lifecycle decisions. Real provider validation, planning, deployment, drift inspection, and restore testing need explicit authorization and an isolated environment. This course runs none of those actions and uses no AWS CLI, SDK, account credentials, endpoint, or admin tool. Retain review evidence and verify actual user and data outcomes after a real approved change, not only the stack status. Infrastructure as code improves visibility and repeatability when ownership, trust, and recovery are designed; it is not a promise that every declaration is safe or automatically reversible.

Common errors and fixes

A small template diff causes major data risk

Why it happens: Text size replaced resource-specific replacement review.
How to fix it: Read change effects and verify recovery before approval.
Prevent it next time: Bind review to exact input and target identities.

Retain is mistaken for a free backup

Why it happens: Lifecycle retention was confused with historical recovery and billing.
How to fix it: Review data copies, ownership, and continuing charges.
Prevent it next time: Document retained-resource lifecycle and cleanup authorization.

A masked parameter is logged elsewhere

Why it happens: Display masking was treated as complete secret protection.
How to fix it: Remove exposure and follow approved credential response.
Prevent it next time: Keep secrets out of outputs, metadata, and logs.

Check your understanding

1. Does a successfully created change set prove the update will finish safely?

Show worked solution

No. Execution can fail because of permission, quota, resource state, dependency, or service behavior, and data consequences need separate review. Inspect exact effects and recovery evidence, then verify outcomes after any authorized execution rather than treating preview as a guarantee.

2. What is the difference between preserving a resource and restoring yesterday’s application state?