{"id":22464,"date":"2026-10-12T08:11:16","date_gmt":"2026-10-12T08:11:16","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=22464"},"modified":"2026-10-12T08:12:28","modified_gmt":"2026-10-12T08:12:28","slug":"terraform-architecture-and-components-through-diagram","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/terraform-architecture-and-components-through-diagram\/","title":{"rendered":"Terraform Architecture and Components through diagram"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Terraform Architecture & End-to-End Workflow<\/h1>\n\n\n\n

This reference architecture covers the standard Terraform CLI workflow, including execution from a developer machine or CI\/CD runner. It shows the relationship between Terraform configuration, Terraform Core, provider plugins, state management, execution plans, and actual cloud infrastructure.<\/p>\n\n\n\n

1. Complete list of Terraform architecture components<\/h2>\n\n\n\n
#<\/th>Component<\/th>Responsibility<\/th><\/tr>
1<\/td>Developer \/ DevOps Engineer<\/td>Writes infrastructure configuration and initiates changes<\/td><\/tr>
2<\/td>Git \/ Version Control<\/td>Stores and versions Terraform configuration<\/td><\/tr>
3<\/td>Execution Environment<\/td>Developer laptop, CI\/CD runner, or HCP Terraform execution environment<\/td><\/tr>
4<\/td>Root Module<\/td>Main Terraform configuration (.tf<\/code> files)<\/td><\/tr>
5<\/td>Child Modules<\/td>Reusable infrastructure configuration, from local paths, Git, or registries<\/td><\/tr>
6<\/td>Input Variables & Locals<\/td>Provide configurable and derived values<\/td><\/tr>
7<\/td>Resources & Data Sources<\/td>Declare infrastructure to manage and external information to read<\/td><\/tr>
8<\/td>Terraform Core \/ CLI<\/td>Evaluates configuration, constructs dependency graphs, plans and executes changes<\/td><\/tr>
9<\/td>Provider Configuration & Plugins<\/td>Connect Terraform Core to external platform APIs<\/td><\/tr>
10<\/td>Authentication & Authorization<\/td>Provide credentials and permissions to access platforms and state<\/td><\/tr>
11<\/td>Terraform Registry<\/td>Source for published providers and modules<\/td><\/tr>
12<\/td>Initialization Artifacts<\/td>.terraform\/<\/code> cache and .terraform.lock.hcl<\/code> provider dependency lock file<\/td><\/tr>
13<\/td>Backend<\/td>Defines where Terraform stores its state<\/td><\/tr>
14<\/td>Terraform State<\/td>Maps Terraform resource instances to real infrastructure objects<\/td><\/tr>
15<\/td>State Locking<\/td>Prevents concurrent conflicting state operations where supported<\/td><\/tr>
16<\/td>Dependency Graph<\/td>Determines resource dependencies and execution order<\/td><\/tr>
17<\/td>Execution Plan<\/td>Describes proposed create, update, replacement, or delete actions<\/td><\/tr>
18<\/td>Approval \/ Policy Checks<\/td>Optional human review and organizational governance<\/td><\/tr>
19<\/td>Terraform Apply<\/td>Executes the approved infrastructure changes<\/td><\/tr>
20<\/td>Cloud \/ SaaS APIs<\/td>Receive provider requests to inspect and modify external resources<\/td><\/tr>
21<\/td>Actual Infrastructure<\/td>AWS, Azure, GCP, Kubernetes, databases, SaaS resources, etc.<\/td><\/tr>
22<\/td>Output Values<\/td>Expose selected values from the resulting infrastructure<\/td><\/tr>
23<\/td>Drift Detection \/ Reconciliation<\/td>Subsequent plans identify differences between configuration, state, and actual resources<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

This follows HashiCorp’s documented Core\u2013Provider architecture, initialization workflow, plan\/apply behavior, and state-management model.<\/p>\n\n\n\n

2. Terraform workflow \u2014 high-level phases<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

The important architectural distinction is that Terraform Core calculates and orchestrates changes; provider plugins communicate with external APIs; and the backend stores Terraform state. These are separate responsibilities.<\/p>\n\n\n\n

3. Terraform Architecture Diagram \u2014 End-to-End<\/h2>\n\n\n\n
flowchart TB\n    subgraph SOURCE[\"01 - CONFIGURATION & SOURCE CONTROL\"]\n        direction LR\n        DEV[\"Developer \/ Git \/ CI Pipeline\"]\n        ROOT[\"Root Module - HCL<br\/>Providers, Resources, Data Sources<br\/>Variables, Outputs, Backend\"]\n        MOD[\"Child Modules<br\/>Local \/ Git \/ Registry\"]\n        VARS[\"Input Values<br\/>tfvars \/ TF_VAR \/ Workspace\"]\n        AUTH[\"Credentials & Identity<br\/>IAM \/ OIDC \/ Environment\"]\n        DEV --> ROOT\n        ROOT -.->|References| MOD\n    end\n\n    subgraph CORE[\"02 - TERRAFORM CORE & EXECUTION WORKFLOW\"]\n        direction LR\n        INIT[\"1. terraform init<br\/>Initialize Backend<br\/>Install Modules & Providers\"]\n        VALID[\"2. terraform validate<br\/>Check Configuration<br\/>Optional: terraform fmt -check\"]\n        PLAN[\"3. terraform plan -out=tfplan<br\/>Refresh Actual Resources<br\/>Build Dependency Graph<br\/>Calculate Changes\"]\n        GATE{\"4. Review<br\/>Approved?\"}\n        APPLY[\"5. terraform apply tfplan<br\/>Execute Saved Plan\"]\n        DONE([\"6. Complete<br\/>Outputs Available\"])\n\n        INIT --> VALID --> PLAN --> GATE\n        GATE -->|Yes| APPLY --> DONE\n    end\n\n    subgraph RUNTIME[\"03 - STATE & PROVIDER INTEGRATION\"]\n        direction LR\n        STATE[(\"Terraform State Backend<br\/>Local \/ S3 \/ HCP Terraform<br\/>State Locking If Supported\")]\n        PROVIDER[\"Provider Plugins<br\/>AWS \/ Azure \/ Google<br\/>Kubernetes \/ SaaS\"]\n        API[\"Cloud & Service APIs\"]\n        INFRA[\"Actual Infrastructure<br\/>VPC \/ EC2 \/ EKS \/ Databases<br\/>DNS \/ Kubernetes \/ SaaS\"]\n\n        PROVIDER <-->|API Requests & Responses| API\n        API <-->|Read & Modify| INFRA\n    end\n\n    ROOT --> INIT\n    MOD -.->|Resolved During Init| INIT\n    VARS -.->|Runtime Input Values| PLAN\n    AUTH -.->|Provider Authentication| PROVIDER\n    AUTH -.->|Backend Authentication| STATE\n\n    INIT -.->|Configure Backend| STATE\n    INIT -.->|Install Plugins| PROVIDER\n\n    PLAN <-->|Read State; Lock If Supported| STATE\n    PLAN <-->|Refresh & Read Data| PROVIDER\n\n    APPLY <-->|Read & Update State| STATE\n    APPLY -->|Create \/ Update \/ Delete| PROVIDER\n\n    GATE -.->|No: Revise & Replan| ROOT\n\n    classDef source fill:#E8F2FF,stroke:#2864C5,color:#14396E,stroke-width:2px\n    classDef step fill:#F0EAFE,stroke:#8056C8,color:#402070,stroke-width:2px\n    classDef decision fill:#FFF0C4,stroke:#DB9200,color:#704A00,stroke-width:3px\n    classDef state fill:#FFF0DC,stroke:#D48827,color:#794609,stroke-width:2px\n    classDef provider fill:#DEF7F5,stroke:#15948C,color:#095E58,stroke-width:2px\n    classDef resource fill:#E3F5E9,stroke:#2E9954,color:#135B32,stroke-width:2px\n    classDef success fill:#D7F5DF,stroke:#26994D,color:#145C30,stroke-width:3px\n\n    class DEV,ROOT,MOD,VARS,AUTH source\n    class INIT,VALID,PLAN,APPLY step\n    class GATE decision\n    class STATE state\n    class PROVIDER,API provider\n    class INFRA resource\n    class DONE success\n\n    style SOURCE fill:#F5F9FF,stroke:#A7C6F1,stroke-width:2px\n    style CORE fill:#FBF8FF,stroke:#C4ADEA,stroke-width:2px\n    style RUNTIME fill:#F5FBFA,stroke:#A4D9D0,stroke-width:2px\n<\/pre><\/div>\n\n\n\n
4. How to explain this architecture during training<\/h2>\n\n\n\n
    \n
  1. Configuration: The engineer defines desired infrastructure using HCL, optionally using reusable modules.<\/li>\n\n\n\n
  2. Initialization: Terraform prepares the backend and downloads required modules and provider plugins.<\/li>\n\n\n\n
  3. Validation: Terraform checks whether the configuration is valid. Formatting checks are optional.<\/li>\n\n\n\n
  4. Planning: Terraform reads the existing state, normally refreshes managed resources through providers, constructs a dependency graph, and calculates the required changes.<\/li>\n\n\n\n
  5. Approval: The engineer or CI\/CD process reviews the execution plan. This is an external workflow gate, not a mandatory Terraform component.<\/li>\n\n\n\n
  6. Applying: Terraform instructs provider plugins to execute the planned changes through platform APIs and persists updated state.<\/li>\n\n\n\n
  7. Continuous management: Future plans compare the desired configuration with current infrastructure to identify drift and new changes.<\/li>\n<\/ol>\n\n\n\n
    5. Important architectural accuracy notes<\/h2>\n\n\n\n
      \n
    • Plan vs. Apply: A normal terraform plan<\/code> doesn’t modify managed infrastructure. terraform apply tfplan<\/code> executes a previously saved plan without another interactive approval prompt. Protect saved plan files because they can contain sensitive data. HashiCorp Developer+2<\/li>\n\n\n\n
    • State vs. Infrastructure: Terraform state stores resource mappings and metadata; it is not the actual infrastructure. A backend manages state storage and locking where supported. HashiCorp Developer+1<\/li>\n\n\n\n
    • Provider vs. Backend: A provider communicates with target service APIs; a backend handles Terraform state. The two serve different purposes. HashiCorp Developer+1<\/li>\n\n\n\n
    • HCP Terraform: For remotely executed HCP workspaces, the same logical responsibilities apply, but the plan\/apply process runs on HCP-managed infrastructure or a configured agent. VCS-driven workflows use their own run and approval process rather than necessarily applying a local tfplan<\/code> file. HashiCorp Developer+1<\/li>\n<\/ul>\n\n\n\n
      The central concept for students: Terraform configuration describes the desired infrastructure, Terraform Core determines the changes, providers interact with the actual platforms, and Terraform state tracks the resources being managed.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Terraform Architecture & End-to-End Workflow This reference architecture covers the standard Terraform CLI workflow, including execution from a developer machine or CI\/CD runner. It shows the relationship… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-22464","post","type-post","status-publish","format-standard","hentry","category-uncategorised"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/22464","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=22464"}],"version-history":[{"count":5,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/22464\/revisions"}],"predecessor-version":[{"id":78963,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/22464\/revisions\/78963"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=22464"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=22464"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=22464"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}