Infrastructure Provisioning: Mermaid Flowchart

Infrastructure Provisioning flowchart diagram

About Source

Infrastructure provisioning is the automated process of declaring, planning, and applying the cloud resources — networks, compute, storage, and services — required to run an application, using Infrastructure as Code (IaC) tools like Terraform, Pulumi, or AWS CloudFormation.

How provisioning works

The process starts with an engineer writing or updating IaC configuration files that declare the desired state of the infrastructure: VPCs, subnets, security groups, compute instances, managed databases, DNS records, and so on. These files are version-controlled alongside application code, so every infrastructure change is reviewed through a Pull Request Workflow.

When a change is merged, the CI system runs terraform validate and tflint (or equivalent) to catch syntax errors and policy violations before any cloud resources are touched. Next, the pipeline generates an execution plan — terraform plan — and posts the plan as a comment on the pull request or approval ticket. This diff shows exactly which resources will be created, modified, or destroyed.

A human reviewer inspects the plan, paying particular attention to any resource deletions or replacements that could cause downtime. After approval (see Deployment Approval Flow), the pipeline runs terraform apply, which communicates with cloud provider APIs to provision or update resources. State is stored remotely (e.g., in S3 with DynamoDB locking) to prevent concurrent modifications.

Post-apply, the pipeline runs automated compliance checks against the live environment and stores the updated state. If the apply fails partway through, the IaC tool's state machine records partial completion, allowing the pipeline to retry safely from a known position. The Infrastructure Drift Detection diagram shows how configuration drift is identified between planned and actual states.

Frequently asked questions

Infrastructure provisioning is the automated process of declaring and applying the cloud resources required to run an application using Infrastructure as Code tools like Terraform, Pulumi, or AWS CloudFormation. Every resource — network, compute, database, DNS — is defined in version-controlled configuration files.

An engineer writes HCL configuration declaring the desired infrastructure state. The CI pipeline validates and lints the config, generates a `terraform plan` diff showing what will change, and after human review, runs `terraform apply` to provision or update resources via cloud provider APIs. State is stored remotely to prevent concurrent modifications.

Terraform is declarative and focused on provisioning cloud resources — it computes the minimal set of API calls needed to reach the desired state. Ansible is procedural and focused on configuring software on existing servers — it runs playbooks of tasks in sequence. Modern teams often use both: Terraform to provision and Ansible (or cloud-init) to configure.

The most common mistakes are storing Terraform state locally (causing conflicts and data loss), not reviewing the plan before applying (unexpected resource deletions causing downtime), and not enforcing remote state locking (concurrent applies corrupting state).

Use Terraform when your team is comfortable with HCL and you want a mature ecosystem of providers and modules. Use Pulumi when you want to write infrastructure in a general-purpose language (TypeScript, Python, Go) — enabling reuse of existing libraries and better type safety. Both are production-ready; the choice is largely about team preference and existing language expertise.

mermaid

flowchart TD
    WriteIaC[Write or update IaC configuration] --> PRReview[Submit via pull request]
    PRReview --> Validate[Run terraform validate and lint]
    Validate --> ValidGate{Validation passed?}
    ValidGate -->|No| FixConfig[Fix configuration errors]
    FixConfig --> Validate
    ValidGate -->|Yes| Plan[Generate terraform plan]
    Plan --> ReviewPlan[Human reviews execution plan]
    ReviewPlan --> PlanGate{Plan approved?}
    PlanGate -->|No| RejectPlan[Reject and request changes]
    RejectPlan --> WriteIaC
    PlanGate -->|Yes| Apply[Run terraform apply]
    Apply --> ApplyGate{Apply succeeded?}
    ApplyGate -->|No| RetryApply[Inspect partial state and retry]
    RetryApply --> Apply
    ApplyGate -->|Yes| StoreState[Store updated remote state]
    StoreState --> ComplianceCheck[Run post-apply compliance checks]
    ComplianceCheck --> Done[Infrastructure provisioned]