{"id":879,"date":"2026-07-02T06:11:33","date_gmt":"2026-07-01T23:11:33","guid":{"rendered":"https:\/\/sumberlaba.com\/index.php\/2026\/07\/02\/mastering-infrastructure-as-code-a-comprehensive-guide-to-using-terraform-for-infrastructure-management\/"},"modified":"2026-07-02T06:11:33","modified_gmt":"2026-07-01T23:11:33","slug":"mastering-infrastructure-as-code-a-comprehensive-guide-to-using-terraform-for-infrastructure-management","status":"publish","type":"post","link":"https:\/\/sumberlaba.com\/index.php\/2026\/07\/02\/mastering-infrastructure-as-code-a-comprehensive-guide-to-using-terraform-for-infrastructure-management\/","title":{"rendered":"Mastering Infrastructure as Code: A Comprehensive Guide to Using Terraform for Infrastructure Management"},"content":{"rendered":"

Mastering Infrastructure as Code: A Comprehensive Guide to Using Terraform for Infrastructure Management<\/h1>\n

Modern infrastructure management has evolved far beyond manually logging into servers or clicking through cloud provider dashboards. The rise of Infrastructure as Code (IaC) has transformed how organizations provision, manage, and version their infrastructure. Among the most powerful and widely adopted IaC tools is Terraform, an open-source tool developed by HashiCorp that allows you to define and provision complete infrastructure using a declarative configuration language. With Terraform, you can manage resources across hundreds of providers\u2014from major public clouds like AWS, Azure, and Google Cloud to SaaS services like Cloudflare, Datadog, and even on-premise systems. This tutorial will guide you through everything you need to know to use Terraform effectively for your infrastructure needs, from installation and basic syntax to advanced concepts like state management and modular design.<\/p>\n

The core philosophy behind Terraform is “describe your infrastructure as code, then apply that code to create, update, or destroy resources.” This means you write human-readable configuration files that define the desired state of your infrastructure, and Terraform handles the rest\u2014creating infrastructure, tracking changes, and ensuring that the real-world state matches your configuration. Unlike imperative tools like Ansible or Chef that require you to script the steps to achieve a state, Terraform is declarative: you specify what you want, not how to get it. This abstraction allows you to treat your infrastructure as a version-controlled asset, integrate it into CI\/CD pipelines, and collaborate with team members using familiar code review processes. Whether you are deploying a simple virtual machine or a sprawling multi-cloud architecture, Terraform provides the foundation for repeatable, auditable, and scalable infrastructure management.<\/p>\n

\"Article<\/p>\n

Step 1: Installing Terraform and Setting Up Your Environment<\/h2>\n

The first step on your Terraform journey is getting the tool installed on your local machine. Terraform is distributed as a single binary for Windows, macOS, and Linux, making installation straightforward. Visit the official Terraform downloads page, select your operating system, and download the appropriate package. For macOS, you can use Homebrew: brew install hashicorp\/tap\/terraform<\/code>. For Linux (Debian\/Ubuntu), you can add the HashiCorp repository: curl -fsSL https:\/\/apt.releases.hashicorp.com\/gpg | sudo apt-key add - && sudo apt-add-repository \"deb [arch=amd64] https:\/\/apt.releases.hashicorp.com $(lsb_release -cs) main\" && sudo apt-get update && sudo apt-get install terraform<\/code>. For Windows, you can use Chocolatey: choco install terraform<\/code>. After installation, verify by running terraform version<\/code> in your terminal. You should see the version number and architecture.<\/p>\n

Next, you need to set up credentials for the provider you plan to use. For example, if you are using AWS, you need to configure your AWS access keys. You can set them as environment variables (AWS_ACCESS_KEY_ID<\/code> and AWS_SECRET_ACCESS_KEY<\/code>), use a shared credentials file (~\/.aws\/credentials<\/code>), or assign an IAM role if running on an EC2 instance. For Azure, you can use az login<\/code> or service principal credentials in environment variables. For GCP, you can set GOOGLE_APPLICATION_CREDENTIALS<\/code> pointing to a service account JSON key. It is a best practice not to hardcode credentials in your Terraform files\u2014always use environment variables, secret stores, or provider-specific authentication mechanisms. Once your provider is authenticated, you can start writing your first configuration.<\/p>\n

Create a new directory for your project, for example my-first-terraform<\/code>, and navigate into it. Initialize the directory as a Terraform workspace by running terraform init<\/code>. This command downloads the necessary provider plugins and sets up the backend for storing state. You will see output indicating that Terraform has initialized successfully. If you have a main.tf<\/code> file with provider blocks, terraform init<\/code> will automatically fetch those providers. In the next steps, we will write those configuration files.<\/p>\n

Step 2: Understanding HashiCorp Configuration Language (HCL) Syntax<\/h2>\n

Before you start writing infrastructure definitions, you need to understand the building blocks of Terraform’s language, HCL. HCL is designed to be both human-readable and machine-friendly. A Terraform configuration consists of blocks, arguments, and expressions. Blocks are the core structural elements, defined by a block type (like resource<\/code>, data<\/code>, provider<\/code>, variable<\/code>, output<\/code>) enclosed in curly braces. Each block can contain labels (like resource type and name) and arguments that assign values to parameters. For example, to define an AWS EC2 instance, you write:<\/p>\n

resource \"aws_instance\" \"web\" {\n  ami           = \"ami-0c55b159cbfafe1f0\"\n  instance_type = \"t2.micro\"\n}<\/code><\/pre>\n
Here resource<\/code> is the block type, aws_instance<\/code> is the resource type from the AWS provider, and web<\/code> is a logical name you choose to refer to this resource within your configuration. Inside the block, you set arguments like ami<\/code> and instance_type<\/code>. Strings are quoted, and values can be simple literals, references to other resources, or expressions. HCL supports interpolation using ${...}<\/code> syntax, though modern Terraform prefers var.name<\/code> or resource.name.attribute<\/code> directly. You can also define variables and outputs, which we will cover later.<\/p>\n
Comments in HCL use #<\/code> for single-line or \/* ... *\/<\/code> for multi-line blocks. Indentation is not required but highly encouraged for readability. Terraform files typically have the extension .tf<\/code>. You can split your configuration across multiple .tf<\/code> files; Terraform combines all files in the same directory (and subdirectories if using modules) into a single configuration. This modular approach helps organize large infrastructures. For now, create a file named main.tf<\/code> in your project directory and start with a provider block.<\/p>\n
Step 3: Defining Providers<\/h2>\n
A provider is a plugin that Terraform uses to interact with a specific platform (cloud, SaaS, etc.). Each provider exposes resources and data sources that you can use in your configuration. The first thing you typically define is a provider<\/code> block. For AWS, it might look like:<\/p>\n
provider \"aws\" {\n  region = \"us-east-1\"\n}<\/code><\/pre>\n
This tells Terraform to use the AWS provider for resources in the us-east-1<\/code> region. You can also configure provider version constraints to ensure compatibility. For example: required_providers { aws = { source = \"hashicorp\/aws\" version = \"~> 4.0\" } }<\/code> in a terraform<\/code> block at the top of your configuration. This best practice locks down the provider version and prevents unexpected breaking changes when running terraform init<\/code> on different machines. You can define multiple providers if you are working with a multi-cloud or hybrid environment. For instance, you could have both provider \"aws\"<\/code> and provider \"azurerm\"<\/code> in the same configuration, allowing you to orchestrate resources across clouds.<\/p>\n
Providers are downloaded automatically by terraform init<\/code> from the Terraform Registry or from a local mirror. The registry hosts hundreds of official and community providers. Always pin your provider versions using a terraform { required_providers }<\/code> block to avoid surprises. Here is a complete example:<\/p>\n
terraform {\n  required_providers {\n    aws = {\n      source  = \"hashicorp\/aws\"\n      version = \"~> 4.0\"\n    }\n  }\n}\n\nprovider \"aws\" {\n  region = \"eu-west-1\"\n}<\/code><\/pre>\n
After writing this in your main.tf<\/code>, run terraform init<\/code> again. Terraform will download the AWS provider plugin (version ~>4.0) and store it in the .terraform<\/code> directory. Now you are ready to define resources.<\/p>\n
Step 4: Writing Resources and Data Sources<\/h2>\n
Resources are the most important elements in Terraform. They represent infrastructure components like virtual machines, databases, load balancers, DNS records, etc. Each resource has a type (like aws_instance<\/code>, azurerm_resource_group<\/code>, google_compute_instance<\/code>) and a local name. The arguments you pass depend on the resource. Let’s create a simple AWS VPC infrastructure with a subnet and an EC2 instance. First, define a VPC:<\/p>\n
resource \"aws_vpc\" \"main\" {\n  cidr_block = \"10.0.0.0\/16\"\n}<\/code><\/pre>\n
Then define a subnet that references the VPC:<\/p>\n
resource \"aws_subnet\" \"public\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = \"10.0.1.0\/24\"\n}<\/code><\/pre>\n
Notice how we reference the VPC ID using aws_vpc.main.id<\/code>. Terraform automatically creates dependencies based on these references, so it knows to create the VPC before the subnet. You can also add explicit dependencies using depends_on<\/code>, but it’s rarely needed. Finally, create an EC2 instance in that subnet:<\/p>\n
resource \"aws_instance\" \"web\" {\n  ami           = \"ami-0c55b159cbfafe1f0\"\n  instance_type = \"t2.micro\"\n  subnet_id     = aws_subnet.public.id\n\n  tags = {\n    Name = \"WebServer\"\n  }\n}<\/code><\/pre>\n
To make your configuration dynamic, you can use variables and data sources. Data sources allow you to fetch information from your provider that is not managed by this configuration. For example, to get the latest Amazon Linux 2 AMI ID dynamically rather than hardcoding it:<\/p>\n
data \"aws_ami\" \"amazon_linux\" {\n  most_recent = true\n  owners      = [\"amazon\"]\n\n  filter {\n    name   = \"name\"\n    values = [\"amzn2-ami-hvm-*-x86_64-gp2\"]\n  }\n}\n\nresource \"aws_instance\" \"web\" {\n  ami           = data.aws_ami.amazon_linux.id\n  instance_type = \"t2.micro\"\n  subnet_id     = aws_subnet.public.id\n}<\/code><\/pre>\n
Now, whenever you apply this configuration, Terraform will query AWS for the latest AMI matching your filters. This makes your infrastructure more resilient and up-to-date. After writing resources, always run terraform fmt<\/code> to automatically format your files, and terraform validate<\/code> to check for syntax errors.<\/p>\n
Step 5: Using Variables and Outputs for Reusability<\/h2>\n
Hardcoding values like region, instance type, and AMI IDs makes your configuration rigid. Variables allow you to parameterize your Terraform code. Define variables in a variables.tf<\/code> file (or within any .tf<\/code> file). Example:<\/p>\n
variable \"instance_type\" {\n  description = \"Type of EC2 instance\"\n  type        = string\n  default     = \"t2.micro\"\n}\n\nvariable \"region\" {\n  description = \"AWS region\"\n  type        = string\n}<\/code><\/pre>\n
You can then use these variables in your main configuration: instance_type = var.instance_type<\/code>. When you run terraform apply<\/code>, Terraform will prompt you for any variables without a default value. Alternatively, you can pass them via a .tfvars<\/code> file (e.g., terraform.tfvars<\/code>) with content like region = \"us-east-1\"<\/code>. You can also use environment variables prefixed with TF_VAR_<\/code> (e.g., export TF_VAR_region=us-west-2<\/code>). This separation of configuration and code allows you to reuse the same Terraform configuration across multiple environments (dev, staging, production) with different variable files.<\/p>\n
Outputs are equally important\u2014they expose information after the apply, such as the public IP of an EC2 instance or the DNS name of a load balancer. Define outputs in outputs.tf<\/code>:<\/p>\n
output \"instance_ip\" {\n  value = aws_instance.web.public_ip\n}\n\noutput \"vpc_id\" {\n  value = aws_vpc.main.id\n}<\/code><\/pre>\n
After running terraform apply<\/code>, you’ll see these outputs displayed in the terminal. You can also query them later with terraform output instance_ip<\/code>. Outputs are useful for passing information to other systems or for display in dashboards. Combine variables with loops (count<\/code> or for_each<\/code>) to create multiple instances of the same resource without repetition. For example, to create three subnets: resource \"aws_subnet\" \"public\" { count = 3; cidr_block = cidrsubnet(var.vpc_cidr, 8, count.index); ... }<\/code>.<\/p>\n
Step 6: Managing State and Remote Backends<\/h2>\n
One of Terraform’s most critical concepts is state. State is a JSON file that maps the resources in your configuration to real-world infrastructure. It tracks metadata like resource IDs, dependencies, and attributes. By default, Terraform stores state locally in a file called terraform.tfstate<\/code>. However, for team collaboration and CI\/CD, you should use a remote backend. Remote backends store state in a shared location (like AWS S3, Azure Storage, HashiCorp Consul, or Terraform Cloud). This prevents conflicts when multiple people run Terraform on the same configuration.<\/p>\n
To set up an S3 backend, first create an S3 bucket and a DynamoDB table for state locking (preventing concurrent modifications). Then add a backend block to your configuration:<\/p>\n
terraform {\n  backend \"s3\" {\n    bucket         = \"my-terraform-state-bucket\"\n    key            = \"prod\/terraform.tfstate\"\n    region         = \"us-east-1\"\n    dynamodb_table = \"terraform-state-lock\"\n    encrypt        = true\n  }\n}<\/code><\/pre>\n
Run terraform init<\/code> again, and Terraform will migrate the local state to the remote backend. You’ll notice a prompt asking if you want to copy existing state. Say yes. After migration, any terraform plan<\/code> or apply<\/code> will use the remote state. State locking prevents two team members from applying conflicting changes simultaneously. If you use no locking, you risk state corruption. Always enable locking (DynamoDB for S3, blob lease for Azure, etc.). For enterprises, Terraform Cloud provides a managed backend with collaboration features like run history, policy enforcement, and private module registry.<\/p>\n
State can contain sensitive data (e.g., database passwords are sometimes stored as attributes). Therefore, always encrypt your state at rest and in transit. For S3, enable default bucket encryption. Limit access to the bucket using IAM policies\u2014only specific roles or users should be able to read\/write state. Treat your state file as a critical asset; backup it regularly. Use terraform state<\/code> commands to inspect, move, or remove resources from state when needed. For example, terraform state list<\/code> shows all resources tracked, and terraform state show aws_instance.web<\/code> shows details.<\/p>\n
Step 7: Working with Modules for Scalable Infrastructure<\/h2>\n
As your infrastructure grows, you’ll want to organize code into reusable modules. A module is any set of Terraform configuration files in a directory. You can call a module from another configuration using a module<\/code> block. Modules accept input variables and produce outputs, just like the root module. They encapsulate a group of resources that together provide a unit of functionality\u2014for example, a VPC module, a web server module, or a database module. You can source modules from the local filesystem, the Terraform Registry, or Git repositories.<\/p>\n
To use a module from the registry, you can write:<\/p>\n
module \"vpc\" {\n  source = \"terraform-aws-modules\/vpc\/aws\"\n  version = \"3.0.0\"\n\n  name = \"my-vpc\"\n  cidr = \"10.0.0.0\/16\"\n  azs  = [\"us-east-1a\", \"us-east-1b\"]\n  private_subnets = [\"10.0.1.0\/24\", \"10.0.2.0\/24\"]\n  public_subnets  = [\"10.0.3.0\/24\", \"10.0.4.0\/24\"]\n\n  enable_nat_gateway = true\n  tags = { Environment = \"dev\" }\n}<\/code><\/pre>\n
This module creates a complete VPC with public and private subnets, NAT gateways, route tables, and more\u2014saving you from writing hundreds of lines of code. You can then reference outputs from the module elsewhere: module.vpc.vpc_id<\/code>. Always pin module versions to avoid unexpected changes. For custom modules, place them in a modules\/<\/code> directory and reference them with a relative path, e.g., source = \".\/modules\/web_app\"<\/code>. Modules promote reusability, enforce consistency across environments, and simplify code review. When designing modules, follow best practices: limit the number of variables, provide sensible defaults, and document usage with README files. Also, consider using terraform-docs<\/code> to auto-generate documentation from inputs and outputs.<\/p>\n
Tips and Best Practices for Terraform Success<\/h2>\n
Tip 1: Always Use Remote State with Locking<\/h3>\n
Local state is fine for experimentation, but as soon as you work with a team or in production, remote state with locking is non-negotiable. Without locking, two concurrent applies can lead to state corruption, resource duplication, and hard-to-debug errors. Popular backends include AWS S3 with DynamoDB, Azure Storage with blob lease, GCS, and Terraform Cloud. For locking, ensure your backend supports it (most do). Test your locking setup by running two terraform apply<\/code> sessions at the same time\u2014the second should fail with a “state locked” message. Also, use state file encryption and restrict access with IAM policies.<\/p>\n
Tip 2: Adopt Infrastructure as Code Workflows<\/h3>\n
Treat your Terraform files as you would application code\u2014use version control (Git), code review, and CI\/CD pipelines. Store your configurations in a repository (like GitHub or GitLab) and set up a pipeline that runs terraform plan<\/code> on pull requests and terraform apply<\/code> after merge. This prevents manual drift and provides an audit trail. Use tools like Terragrunt to manage multiple environments and reduce duplication. Also, implement policy as code using Sentinel (Terraform Cloud) or Open Policy Agent to enforce compliance rules (e.g., “all S3 buckets must have encryption enabled”).<\/p>\n
Tip 3: Use Workspaces for Environment Separation<\/h3>\n
Instead of duplicating entire configurations for dev, staging, and production, use Terraform workspaces. Workspaces allow you to maintain multiple independent state files within the same configuration directory. Run terraform workspace new dev<\/code> to create a workspace, then terraform workspace select dev<\/code> to switch. Each workspace has its own state file, so you can apply different variable values per workspace using terraform.tfvars.dev<\/code> or by referencing terraform.workspace<\/code> in your config. However, for complex environments, many teams prefer a separate directory structure per environment to reduce blast radius. Choose the approach that fits your organization’s risk tolerance.<\/p>\n
FAQ: Frequently Asked Questions About Terraform<\/h2>\n
    \n
  1. Q: What is the difference between Terraform and Ansible?<\/strong>
    A: Both are Infrastructure as Code tools, but they take different approaches. Terraform is declarative and focuses on provisioning infrastructure (VMs, networks, DNS). Ansible is imperative (you write steps) and excels at configuration management (installing software, configuring services). They complement each other\u2014many teams use Terraform to provision the infrastructure and Ansible to configure it. Terraform can also call Ansible playbooks via provisioners, though this is less common.<\/li>\n
  2. Q: How do I handle secrets in Terraform?<\/strong>
    A: Never store secrets in plaintext in your configuration or state files. Use variables marked as sensitive = true<\/code> to prevent them from appearing in logs and outputs. Store secrets in a vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and retrieve them using data sources. For example, the aws_secretsmanager_secret<\/code> data source can fetch a database password at apply time. Also, enable state encryption (e.g., server-side encryption on S3 bucket) and restrict access to state files.<\/li>\n
  3. Q: Can I manage existing infrastructure with Terraform?<\/strong>
    A: Yes, you can import existing resources into Terraform state using terraform import<\/code>. For example, terraform import aws_instance.web i-1234567890abcdef0<\/code> adds an existing EC2 instance to your state without modifying it. You then need to write the configuration that matches the resource’s current attributes. Terraform will not delete the resource unless you remove its configuration and run apply. Import is the first step to managing brownfield (existing) infrastructure with IaC.<\/li>\n
  4. Q: What happens if I delete a resource from my configuration?<\/strong>
    A: When you remove a resource block from your configuration and run terraform apply<\/code>, Terraform will destroy that real-world resource. This is a powerful but dangerous feature. Always run terraform plan<\/code> first to see what will be destroyed. To prevent accidental deletion, use prevent_destroy = true<\/code> as a lifecycle argument on critical resources (e.g., databases). You can also use terraform state rm<\/code> to remove a resource from state without destroying it, if you want to manage it outside Terraform.<\/li>\n
  5. Q: How do I manage multiple environments (dev, prod) without duplicating code?<\/strong>
    A: The most common approaches are using workspaces or directory structure. With workspaces, you have the same configuration but separate state files and variable files per workspace (dev.tfvars<\/code>, prod.tfvars<\/code>). With separate directories, you copy the configuration but use different backends and variable files. Many teams prefer the directory approach because it provides clear isolation and easier blast radius control. Tools like Terragrunt can reduce duplication by generating backend configurations and variable files dynamically.<\/li>\n<\/ol>\n
    Comparison of Terraform with Other IaC Tools<\/h2>\n\n\n\n\n\n\n\n\n\n\n
    Feature \/ Tool<\/th>\nTerraform<\/th>\nAnsible<\/th>\nCloudFormation (AWS)<\/th>\n<\/tr>\n<\/thead>\n
    Approach<\/td>\nDeclarative<\/td>\nImperative<\/td>\nDeclarative<\/td>\n<\/tr>\n
    Primary Focus<\/td>\nInfrastructure provisioning<\/td>\nConfiguration management & provisioning<\/td>\nInfrastructure provisioning (AWS only)<\/td>\n<\/tr>\n
    Provider Support<\/td>\nHundreds (multi-cloud & SaaS)<\/td>\nMany (via modules\/plugins)<\/td>\nAWS only (with some cross-service via custom resources)<\/td>\n<\/tr>\n
    State Management<\/td>\nBuilt-in state (local\/remote)<\/td>\nNo state; idempotent via facts<\/td>\nManaged by AWS (no state file)<\/td>\n<\/tr>\n
    Language<\/td>\nHCL<\/td>\nYAML<\/td>\nYAML or JSON<\/td>\n<\/tr>\n
    Learning Curve<\/td>\nModerate (HCL syntax, state concepts)<\/td>\nLow (YAML is easy to read)<\/td>\nModerate (AWS-specific constructs)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Common Terraform Commands Reference Table<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n
    Command<\/th>\nPurpose<\/th>\nExample<\/th>\n<\/tr>\n<\/thead>\n
    terraform init<\/code><\/td>\nInitialize a working directory with provider plugins and backend configuration.<\/td>\nterraform init<\/code><\/td>\n<\/tr>\n
    terraform plan<\/code><\/td>\nPreview changes (create, update, destroy) without applying them.<\/td>\nterraform plan -out=tfplan<\/code><\/td>\n<\/tr>\n
    terraform apply<\/code><\/td>\nExecute the changes to reach the desired state.<\/td>\nterraform apply tfplan<\/code> (or terraform apply -auto-approve<\/code>)<\/td>\n<\/tr>\n
    terraform destroy<\/code><\/td>\nDestroy all resources managed by the current configuration.<\/td>\nterraform destroy<\/code><\/td>\n<\/tr>\n
    terraform validate<\/code><\/td>\nCheck the syntax and structure of configuration files.<\/td>\nterraform validate<\/code><\/td>\n<\/tr>\n
    terraform fmt<\/code><\/td>\nFormat all .tf<\/code> files to standard styling.<\/td>\nterraform fmt -recursive<\/code><\/td>\n<\/tr>\n
    terraform state list<\/code><\/td>\nList all resources tracked in the state file.<\/td>\nterraform state list<\/code><\/td>\n<\/tr>\n
    terraform import<\/code><\/td>\nImport existing infrastructure into state.<\/td>\nterraform import aws_instance.web i-0abcdef<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Conclusion<\/h2>\n
    Terraform has become the de facto standard for infrastructure as code, empowering teams to manage complex, multi-cloud environments with confidence and consistency. By following this comprehensive guide, you have learned how to install Terraform, write configuration files using HCL, define providers and resources, manage state with remote backends, use variables and outputs for flexibility, and organize code with modules. We also covered essential best practices such as state locking, workspace usage, and integrating Terraform into your CI\/CD pipelines. Remember that the journey to mastering Terraform is continuous\u2014the ecosystem evolves rapidly, with new providers, features like Terraform Cloud, and community modules being released regularly. Start small: automate a single resource type, then gradually expand your infrastructure definition. Always review plans before applying, and keep your state files secure. With these skills, you are now equipped to treat your infrastructure as code, enabling faster deployments, less manual error, and better collaboration across your organization. Happy terraforming!<\/p>\n","protected":false},"excerpt":{"rendered":"
    Mastering Infrastructure as Code: A Comprehensive Guide to Using Terraform for Infrastructure Management Modern infrastructure management has evolved far beyond manually logging into servers or clicking through cloud provider dashboards. The rise of Infrastructure as Code (IaC) has transformed how organizations provision, manage, and version their infrastructure. Among the most powerful and widely adopted IaC … <\/p>\n","protected":false},"author":2716,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[],"tags":[],"class_list":["post-879","post","type-post","status-publish","format-standard","hentry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts\/879","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/users\/2716"}],"replies":[{"embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/comments?post=879"}],"version-history":[{"count":0,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts\/879\/revisions"}],"wp:attachment":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/media?parent=879"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/categories?post=879"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/tags?post=879"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}