Terraform

Terraform: "HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features."

• Full automation: In the past, resource creation, modification and removal were handled manually or by using a set of tooling. With Terraform or other IaC technologies, you manage the full lifecycle in an automated fashion.

• Modular and Reusable: Code that you write for certain purposes can be used and assembled in different ways. You can write code to create resources on a public cloud and it can be shared with other teams who can also use it in their account on the same (or different) cloud>

• Improved testing: Concepts like CI can be easily applied on IaC based projects and code snippets. This allow you to test and verify operations beforehand

For learning a platform when first starting out

Manual processes for creating infrastructure are slow because they require human intervention for each step, which delays deployment. They are error-prone since manual configuration increases the risk of mistakes and inconsistencies. Additionally, these processes are not easily repeatable, making it difficult to ensure the same infrastructure setup across different environments—unlike Infrastructure as Code (IaC), which automates and standardizes deployments.

• Declarative: Terraform uses the declarative approach (rather than the procedural one) in order to define end-status of the resources
• No agents: as opposed to other technologies (e.g. Puppet) where you use a model of agent and server, with Terraform you use the different APIs (of clouds, services, etc.) to perform the operations
• Community: Terraform has strong community who constantly publishes modules and fixes when needed. This ensures there is good modules maintenance and users can get support quite quickly at any point

A DSL called "HCL" (Hashicorp Configuration Language). A declarative language for defining infrastructure.

1. Write Terraform definitions: .tf files written in HCL that described the desired infrastructure state (and run terraform init at the very beginning)
2. Review: With command such as terraform plan you can get a glance at what Terraform will perform with the written definitions
3. Apply definitions: With the command terraform apply Terraform will apply the given definitions, by adding, modifying or removing the resources

This is a manual process. Most of the time this is automated so user submits a PR/MR to propose terraform changes, there is a process to test these changes and once merged they are applied (terraform apply).

• Infra provisioning and management: You need to automated or code your infra so you are able to test it easily, apply it and make any changes necessary.
• Multi-cloud environment: You manage infrastructure on different clouds, but looking for a consistent way to do it across the clouds
• Consistent environments: You manage environments such as test, production, staging, ... and looking for a way to have them consistent so any modification in one of them, applies to other environments as well

Terraform is considered to be an IaC technology. It's used for provisioning resources, for managing infrastructure on different platforms.

Ansible, Puppet and Chef are Configuration Management technologies. They are used once there is an instance running and you would like to apply some configuration on it like installing an application, applying security policy, etc.

To be clear, CM tools can be used to provision resources so in the end goal of having infrastructure, both Terraform and something like Ansible, can achieve the same result. The difference is in the how. Ansible doesn't saves the state of resources, it doesn't know how many instances there are in your environment as opposed to Terraform. At the same time while Terraform can perform configuration management tasks, it has less modules support for that specific goal and it doesn't track the task execution state as Ansible. The differences are there and it's most of the time recommended to mix the technologies, so Terraform used for managing infrastructure and CM technologies used for configuration on top of that infrastructure.

It's a resource of type "aws_instance" used to provision an instance. The name of the resource (NOT INSTANCE) is "some-instance".

The instance itself will be provisioned with type "t2.micro" and using an image of the AMI "ami-201720221991yay".

Run terraform init. This will scan the code in the directory to figure out which providers are used (in this case AWS provider) and will download them.

Execute terraform plan. That will provide a detailed information on what Terraform will do once you apply the changes.

Run terraform apply. That will apply the changes described in your .tf files.

• '+' - The resource or attribute is going to be added
• '-' - the resource or attribute is going to be removed
• '-/+' - the resource or attribute is going to be replaced

terraform destroy will cleanup all the resources tracked by Terraform.

A user should be careful with this command because there is no way to revert it. Sure, you can always run again "apply" but that can take time, generates completely new resources, etc.

Why: because resources are sometimes connected or need to be connected. For example, you create an AWS instance with "aws_instance" resource but, at the same time you would like also to allow some traffic to it (because by default traffic is not allowed). For that you'll create a "aws_security_group" resource and then, in your aws_instance resource, you'll reference it.

How:

Using the syntax ..

In your AWS instance it would like that:

resource "aws_instance" "some-instance" {

  ami           = "some-ami"
  instance_type = "t2.micro"
  vpc_security_group_ids = [aws_security_group.instance.id]

}

Yes, when there is a dependency between different Terraform resources, you want the resources to be created in the right order and this is exactly what Terraform does.

To make it ever more clear, if you have a resource X that references the ID of resource Y, it doesn't makes sense to create first resource X because it won't have any ID to get from a resource that wasn't created yet.

Yes, with terraform graph

The output is in DOT - A graph description language.

terraform.io: "Terraform relies on plugins called "providers" to interact with cloud providers, SaaS providers, and other APIs...Each provider adds a set of resource types and/or data sources that Terraform can manage. Every resource type is implemented by a provider; without providers, Terraform can't manage any kind of infrastructure."

In the Terraform Registry

azurerm and aws

You write a provider block like the following one and run terraform init

provider "aws" {
  region = "us-west-1"
}

False. It will look for "aws" provider in the public Terraform registry and will take the latest version.

AWS is one of the most popular providers in Terraform. Here is an example of how to configure it to use one specific region and specifying a specific version of the provider

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
  }
}

# Configure the AWS Provider
provider "aws" {
  region = "us-west-2"
}

By default Terraform providers are installed from Terraform Registry

The Terraform Registry provides a centralized location for official and community-managed providers and modules.

.terraform directory.

1. Terraform checks if there is an aws provider in this address: registry.terraform.io/hashicorp/aws
2. Installs latest version of aws provider (assuming the URL exists and valid)

False. You can specify any provider from any URL, not only those from hashicorp.

Variables allow you define piece of data in one location instead of repeating the hardcoded value of it in multiple different locations. Then when you need to modify the variable's value, you do it in one location instead of changing each one of the hardcoded values.

string
number
bool
list()
set()
map()
object({ = , ... })
tuple([, ...])

any

• Using -var option in the CLI
• Using a file by using the -var-file option in the CLI
• Environment variable that starts with TF_VAR_

If no value given, user will be prompted to provide one.

Using the syntax var.

It doesn't show its value when you run terraform apply or terraform plan but eventually it's still recorded in the state file.

True

Terraform loads variables in the following order, with later sources taking precedence over earlier ones:

• Environment variable
• The file terraform.tfvars
• Using -var or -var-file

While removing the variable is theoretically a correct answer, it will probably fail the execution.

You can use something like the -var option to provide the value and avoid being prompted to insert a value. Another option is to run export TF_VAR_=.

Output variable allow you to display/print certain piece of data as part of Terraform execution.

The most common use case for it is probably to print the IP address of an instance. Imagine you provision an instance and you would like to know what the IP address to connect to it. Instead of looking for it for the console/OS, you can use the output variable and print that piece of information to the screen

When set to "true", Terraform will avoid logging output variable's data. The use case for it is sensitive data such as password or private keys.

It is used to set explicitly dependency between the output variable and any other resource. Use case: some piece of information is available only once another resource is ready.

Similarly to variables they serve as placeholders for data and values. Differently from variables, users can't override them by passing different values.

You have multiple hardcoded values that repeat themselves in different sections, but at the same time you don't want to expose them as in, allow users to override values.

variable "app_id" {
  type        = string
  description = "The id of application"
  default     = "some_value"
}

Unrelated note: variables are usually defined in their own file (vars.tf for example).

variable "car_model" {
  description = "Car model object"
  type        = object({
    model   = string
    color   = string
    year    = number
  })
}

Note: you can also define a default for it.

Variable are referenced with var.VARIABLE_NAME syntax. Let's have a look at an example:

vars.tf:

variable "memory" {
  type = string
  default "8192"
}

variable "cpu" {
  type = string
  default = "4"
}

main.tf:

resource "libvirt_domain" "vm1" {
   name = "vm1"
   memory = var.memory
   cpu = var.cpu
}

Using the syntax: "${var.VAR_NAME}". It's called "interpolation".

Very common to see it used in user_data attribute related to instances.

user_data = <<-EOF
            This is some fabulos string
            It demonstrates how to use interpolation
            Yes, it's truly ${var.awesome_or_meh}
            EOF

terraform output will list all outputs without applying any changes

Yes, with terraform output .

Very useful for scripts :)

locals {
  x = 2
  y = "o"
  z = 2.2
}

if we defined something like this

locals {
  x = 2
}

then to use it, you have to use something like this: local.x

• Data sources used to get data from providers or in general from external resources to Terraform (e.g. public clouds like AWS, GCP, Azure).
• Data sources used for reading. They are not modifying or creating anything
• Many providers expose multiple data sources

data "aws_vpc" "default {
  default = true
}

The general syntax is data...

So if you defined the following data source

data "aws_vpc" "default {
  default = true
}

You can retrieve the ID attribute this way: data.aws_vpc.default.id

Yes, you can define a data source while using another data source as a filter for example.

Let's say we want to get AWS subnets but only from our default VPC:

data "aws_subnets" "default" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.default.id]
  }
}

By default the current resource is deleted, a new one is created and any references pointing the old resource are updated to point the new resource

Yes, it's possible. There are different lifecycles one can choose from. For example "create_before_destroy" which inverts the order and first creates the new resource, updates all the references from old resource to the new resource and then removes the old resource.

How to use it:

lifecycle {
  create_before_destroy = true
}

Why to use it in the first place: you might have resources that have dependency where they dependency itself is immutable (= you can't modify it hence you have to create a new one), in such case the default lifecycle won't work because you won't be able to remove the resource that has the dependency as it still references an old resource. AWS ASG + launch configurations is a good example of such use case.

Provisioners

Provisioners can be described as plugin to use with Terraform, usually focusing on the aspect of service configuration and make it operational.

Few example of provisioners:

• Run configuration management on a provisioned instance using technology like Ansible, Chef or Puppet.
• Copying files
• Executing remote scripts

Since a provisioner can run a variety of actions, it's not always feasible to plan and understand what will happen when running a certain provisioner. For this reason, it's usually recommended to use Terraform built-in option, whenever's possible.

local-exec provisioners run commands on the machine where Terraform is executed, while remote-exec provisioners run commands on the remote resource.

It's a resource which was successfully created but failed during provisioning. Terraform will fail and mark this resource as "tainted".

terraform taint resource.id manually marks the resource as tainted in the state file. So when you run terraform apply the next time, the resource will be destroyed and recreated.

Data sources lookup or compute values that can be used elsewhere in terraform configuration.

There are quite a few cases you might need to use them:

• you want to reference resources not managed through terraform
• you want to reference resources managed by a different terraform module
• you want to cleanly compute a value with typechecking, such as with aws_iam_policy_document

Output variables are named values that are sourced from the attributes of a module. They are stored in terraform state, and can be used by other modules through remote_state

Terraform generates a terraform.tfstate json file that describes components/service provisioned on the specified provider. Remote State stores this file in a remote storage media to enable collaboration amongst team.

State locking is a mechanism that blocks an operations against a specific state file from multiple callers so as to avoid conflicting operations from different team members. Once the first caller's operation's lock is released the other team member may go ahead to carryout his own operation. Nevertheless Terraform will first check the state file to see if the desired resource already exist and if not it goes ahead to create it.

The built-in terraform way would be to use remote-state to lookup the outputs from other modules. It is also common in the community to use a tool called terragrunt to explicitly inject variables between modules.

1. Identify which resource you want to import.
2. Write terraform code matching configuration of that resource.
3. Run terraform command terraform import RESOURCE ID

eg. Let's say you want to import an aws instance. Then you'll perform following:

1. Identify that aws instance in console
2. Refer to it's configuration and write Terraform code which will look something like:

resource "aws_instance" "tf_aws_instance" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  tags = {
    Name = "import-me"
  }
}

3. Run terraform command terraform import aws_instance.tf_aws_instance i-12345678

• The representation of resources - JSON format of the resources, their attributes, IDs, ... everything that required to identify the resource and also anything that was included in the .tf files on these resources
• Terraform version
• Outputs

Terraform stores state to map real infrastructure objects to the resources declared in code, keep track of dependencies, detect drift, and speed up planning by caching attribute data.

• Local state is stored in a terraform.tfstate file on disk and is suitable for quick experiments or single-operator workflows.

• Remote state lives in a backend (such as S3, GCS, Terraform Cloud) that can enforce locking, access controls, and versioning so teams share a single source of truth.

  Always choose a remote backend once there is more than one operator or automation pipeline touching the configuration.

• tfstate contains credentials in plain text. You don't want to put it in publicly shared location.

• tfstate shouldn't be modified concurrently so putting it in a shared location available for everyone with "write" permissions might lead to issues. (Terraform remote state doesn't has this problem).

• tfstate is an important file. As such, it might be better to put it in a location that has regular backups and good security.

  As such, tfstate shouldn't be stored in git repositories. secured storage such as secured buckets, is a better option.

False. You should avoid as much possible to edit Terraform state files directly by hand. Prefer supported commands such as terraform state mv, terraform state rm, or terraform state replace-provider so the CLI keeps metadata consistent.

In general, storing state file on your computer isn't a problem. It starts to be a problem when you are part of a team that uses Terraform and then you would like to make sure it's shared. In addition to being shared, you want to be able to handle the fact that different teams members can edit the file and can do it at the same time, so locking is quite an important aspect as well.

• Don't edit it manually. tfstate was designed to be manipulated by terraform and not by users directly.

• Store it in secured location (since it can include credentials and sensitive data in general).

• Backup it regularly so you can roll-back easily when needed.

• Store it in remote shared storage. This is especially needed when working in a team and the state can be updated by any of the team members.

• Enabled versioning if the storage where you store the state file, supports it. Versioning is great for backups and roll-backs in case of an issue.

• Designate "state owners" who review access, rotate credentials, and execute migrations.

• Keep .tfstate files and the .terraform/ directory out of version control (.gitignore) and encrypt any ad-hoc backups.

If there are two users or processes concurrently editing the state file it can result in invalid state file that doesn't actually represents the state of resources.

To avoid that, Terraform can apply state locking if the backend supports that. For example, AWS s3 supports state locking and consistency via DynamoDB. Often, if the backend supports it, Terraform will make use of state locking automatically so nothing is required from the user to activate it. Automation pipelines should wait for locks to clear instead of forcing unlocks.

Probably no right or wrong answer here, but it seems, based on different source, that the overall preferred way is to have a dedicated state file per environment.

Common patterns:

• Separate backend configurations per environment (different S3 prefixes or even different buckets and DynamoDB tables).

• Distinct workspaces or directories when you need isolated state plus different credentials.

• Terraform Cloud organizations/workspaces mapped to environments with role-based access control.

• Sensitive data: some resources may specify sensitive data (like passwords and tokens) and everything in a state file is stored in plain text.

• Prone to errors: when working with Git repos, you mayo often find yourself switch branches, checkout specific commits, perform rebases, ... all these operations may end up in you eventually performing terraform apply on non-latest version of your Terraform code. Keeping state outside Git eliminates that risk.

• Lack of locking and audit trails compared to managed backends.

Terraform backend determines how the Terraform state is stored and loaded. By default the state is local, but it's possible to set a remote backend.

Use a remote backend when you need a shared, durable source of truth. A minimal configuration looks like:

terraform {
  required_version = ">= 1.6.0"

  backend "s3" {
    bucket         = "my-tfstate-bucket"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tf-locks"
    encrypt        = true
  }
}

• Create the S3 bucket with versioning, default encryption, and block public access before enabling the backend.

• Provision a DynamoDB table with the primary key LockID so Terraform can acquire locks.

• Use IAM least privilege policies that allow only state operations on the bucket and table to reduce blast radius.

terraform init -migrate-state
terraform plan -refresh-only
terraform state list
terraform show -json | jq '.values.root_module.resources[].address' | head
terraform state mv module.vpc.aws_subnet.public[0] module.vpc.aws_subnet.public_a

• terraform init -migrate-state: moves an existing local state file into the configured backend with locking.

• terraform plan -refresh-only: detects drift by refreshing remote object attributes without proposing changes.

• terraform state list: confirms which objects are tracked in the state after migrations or imports.

• terraform show -json: enables scripted inspections (paired here with jq) so you can audit addresses or metadata.

• terraform state mv: renames or relocates resources/modules without recreation, useful during refactors.

• Encrypt and version your remote backend (for example aws_s3_bucket_versioning plus SSE-KMS on S3).

• Enforce locking (DynamoDB, GCS locking, or Terraform Cloud workspaces) and monitor stuck locks.

• Grant IAM minimum privileges and rotate access keys; automation should assume roles with short-lived credentials.

• Schedule automated backups of the backend (S3 replication, DynamoDB PITR) and periodically test restores.

• Document "state owner" responsibility, incident response, and break-glass steps for unlocks or manual edits (should be last resort).

1. Provision backend resources (for example an S3 bucket with versioning and a DynamoDB table) from a separate bootstrap configuration.

2. Add the backend block to your Terraform configuration and run terraform init -migrate-state.

3. Verify the migration with terraform state list or terraform state pull and keep a secure backup of the previous file.

4. Remove or archive the local terraform.tfstate only after confirming new plans operate against the remote backend.

It starts with acquiring a state lock so others can't modify the state at the same time. The apply will also download the latest state snapshot before planning and upload the updated state atomically after the run completes.

1. You remove the backend code and perform terraform init to switch back to local backend.

2. You remove the resources that are the remote backend itself.

3. Archive the latest remote state file so you can recover if the local copy gets corrupted.

That's true and quite a limitation as it means you'll have to go to the resources of the remote backend and copy some values to the backend configuration.

One way to deal with it is using partial configurations in a completely separate file from the backend itself and then load them with terraform init -backend-config=some_backend_partial_conf.hcl.

Yes, using the concept of data sources. There is a data source for a remote state called "terraform_remote_state".

You can use it the following syntax data.terraform_remote_state..outputs.

By storing the state file in a shared location enabling multiple people or processes to work with the same state. A remote state backend improves collaboration on Terraform projects by addressing the core challenge of sharing infrastructure state. When a team works on infrastructure, everyone needs access to the current state to safely make changes, and locking prevents clashing applies.

developer.hashicorp.com: "The persistent data stored in the backend belongs to a workspace. The backend initially has only one workspace containing one Terraform state associated with that configuration. Some backends support multiple named workspaces, allowing multiple states to be associated with a single configuration."

True

One reason is that all the workspaces are stored in one location (as in one backend) and usually you don't want to use the same access control and authentication for both staging and production for obvious reasons. Also working in workspaces is quite prone to human errors as you might accidentally think you are in one workspace, while you are working a completely different one.

terraform apply

terraform show

terraform state list

terraform state mv

terraform workspace new

terraform workspace show

variable "list_of_nums" {
  type = list(number)
  description = "An example of list of numbers"
  default = [2, 0, 1, 7]
}

resource "some_resource" "some_name" {
  count = length(var.some_list)
}

users[1].name

users[*].name

The most common use case is when you need to create multiple resources with only a slight difference (like different name). Instead of defining multiple separate resources, you can define it once and create multiple instances of it using loops.

resource "aws_instance" "server" {
  count = 15
}

The above configuration will create 15 aws instances.

resource "aws_instance" "server" {
  count = 6

  tags = {
    Name = "instance-${count.index}"
  }
}

The above configuration will create 6 instances, each with a different name.

resource "aws_iam_user" "user" {
  count = length(var.users)

  name = var.users[count.index]
}

• count isn't supported within an inline block
• It's quite limited when it comes to lists.You'll notice that modifying items in lists or even operations like removal sometimes interpreted in a way you didn't expect. For example, removing an item from a list, may shift other items to a new position and since each position represents a resource with count, that may lead to a result where wrong resources are being modified and removed. There are ways to do deal it, but still using count with lists is not always straightforward

• for_each can applied only on collections like maps or sets (as opposed to count that can be applied on lists)
• for_each helps to deal with the limitation of count which isn't optimal for use cases of modifying lists
• for_each supports inline blocks as opposed to count

resource “google_compute_instance” “instances” {

  for_each = var.names_map
  name = each.value
}

for_each can applied only on collections like maps or sets so the list should be converted to a set like this: for_each = toset(var.names)

resource "some_instance" "instance" {

dynamic "tag" {
  for_each = var.tags

  content {
    key   = tag.key
    value = tag.value
    }
  }
}

output "users" {
  value = [for name in var.user_names : upper(name)]
}

The above code will fail as it's not possible to reference resource outputs with count, because Terraform has to compute count before any resources are created (or modified).

output "users" {
  value = "%{ for name in var.values }${name}, %{ endfor }"
}

output "users" {
  value = [for name in var.user_names : upper(name) if length(name) > 3]
}

• Using the values built-in function: values(instances)
• values(instances)[*].name

output "name_and_age" {
  value = [for name, age in var.users : "my name is ${name} and my age is ${age}"]
}

output "name_and_age" {
  value = {for name, age in var.users : upper(name) => floor(age)
}

some_condition ? "value_if_true" : "value_if_false"

If x evaluated to true, the result is 1, otherwise (if false) the result is 0.

If x is an empty string the result is "yay", otherwise it's the value of x variable

Yes, for example the "count" meta-argument:

resource "aws_instance" "server" {
  count = var.amount ? 1 : 0
  ...
}

Yes, for example:

dynamic "tag" {
  for_each = {
    for key, value in var.tags:
    key => value
    if key != ""
  }
}

Arguments that affect the lifecycle of a resources (its creation, modification, ...) and supported by Terraform regardless to the type of resource in which they are used.

Some examples:

• count: how many resources to create out of one definition of a resource
• lifecycle: how to treat resource creation or removal

• count: how many resources to create out of one definition of a resource
• lifecycle: how to treat resource creation or removal
• depends_on: create a dependency between resources

Renders a template file and returns the result as string.

Switch relative paths with what is known as path references. These are fixes: paths like module root path, module expression file path, etc.

A valid answer could be "I write Terraform configuration and try to execute it" but this makes testing cumbersome and quite complex in general.

There is terraform console command which allows you to easily execute terraform functions and experiment with general syntax.

False. terraform console is ready-only.

templatefile function.

depends_on used to create an explicit dependency between resources in Terraform. For example, there is an application you would like to deploy in a cluster. If the cluster isn't ready (and also managed by Terraform of course) then you can't deploy the app. In this case, you will define "depends_on" in the app configuration and its value will be the cluster resource.

Terraform.io: "A module is a container for multiple resources that are used together. Modules can be used to create lightweight abstractions, so that you can describe your infrastructure in terms of its architecture, rather than directly in terms of physical objects."

In addition, modules are great for creating reusable Terraform code that can be shared and used not only between different repositories but even within the same repo, between different environments (like staging and production). Well-designed modules also expose a small, opinionated surface and hide implementation details.

Basically any file or files in a directory is a module in Terraform. There is no special syntax to use in order to define a module. The root configuration is itself a module, and any module that is called from it is considered a child module.

• You need to reuse infrastructure patterns across environments, teams, or regions without copy-paste.

• You want to codify best practices (naming, tagging, security controls) behind a stable interface.

• You need to version and promote infrastructure changes using semantic releases and CI pipelines.

• You want to limit blast radius by updating one module and rolling it out gradually.

modules/vpc/
  main.tf
  variables.tf
  outputs.tf
  versions.tf
  README.md
  examples/
    basic/
      main.tf

• main.tf defines resources, data sources, and locals.

• variables.tf contains typed inputs with descriptions and validations.

• outputs.tf exposes the minimal set of outputs downstream stacks need.

• versions.tf pins compatible Terraform and provider versions.

• examples/ hosts runnable samples for documentation and testing, usually referenced by CI.

module "vpc" {
  source  = "git::https://github.com/org/infra-modules.git//vpc?ref=v1.2.3"
  cidr    = "10.0.0.0/16"
  azs     = ["us-east-1a", "us-east-1b"]
}

• For registry modules, use version constraints (for example version = ">= 1.2.0, < 2.0.0").

• Always pin module versions to keep plans reproducible and review upstream releases before upgrading.

• Prefer tags or immutable SHAs for VCS sources to guarantee repeatable builds.

• Define typed variables with defaults and validation blocks to guard against invalid CIDRs, AZ counts, or empty strings.

• Use locals to transform data or derive names, and combine with for_each/count for deterministic resource creation.

• Document outputs in outputs.tf, mark sensitive ones, and keep outputs minimal to reduce coupling.

• Surface module metadata (like version or tags) through outputs for downstream modules or automation.

• Embedding provider blocks inside the module which makes reuse across accounts harder.

• Accepting overly generic map(any) inputs that hide required structure instead of typed objects.

• Outputting secrets or credentials without sensitive = true or secret stores.

• Creating "god" root modules that mix networking, compute, and application concerns instead of composing smaller modules.

• Copying and pasting modules without versioning, documentation, or automated tests.

terraform -chdir=examples/vpc init
terraform -chdir=examples/vpc validate
terraform -chdir=examples/vpc plan
tflint --module

• terraform validate catches syntax errors and missing providers.

• Running plan against an example stack surfaces integration issues before promotion.

• tflint --module adds provider-specific linting; tools like Terratest can provision ephemeral infra for assertions.

• Include these commands in CI so every module change is exercised automatically.

There are multiple answers, but the most common answer would likely to be using the tool terratest, and to test that a module can be initialized, can create resources, and can destroy those resources cleanly. You can also rely on terraform validate, terraform plan with sample configurations, and linting tools such as tflint.

No right or wrong here.

Personally, I prefer to use only separate resources in modules as it makes modules more flexible. So if a resource includes inline blocks, that may limit you at some point.

False. It can be a Git URL, HTTP URL, ... for example:

module "some_module" {

  source = "github.com/foo/modules/bar?ref=v0.1"
}

Terraform modules can be found at the Terrafrom registry

Relative paths usually work fine in your own environment as you are familiar with the layout and paths used, but when sharing a module and making it reusable, you may bump into issues as it runs on different environments where the relative paths may no longer be relevant.

A better approach would be to use path reference like one of the following:

• path.module: the path of the module where the expression is used
• path.cwd: the path of the current working directory
• path.root: the path of the root module

The general syntax is:

module "" {
  source  = ""
  version = ">= 1.2.0, < 2.0.0"

  # module inputs
}

The critical part is the source which you use to tell Terraform where the module can be found. When the module comes from the registry, you can pin the version; for local paths omit that attribute.

module "amazing_module" {
  source = "../modules/amazing-module"
}

Run terraform init -upgrade (or terraform get -update on older versions) so Terraform downloads the new version of the module and updates the .terraform/modules directory.

The general syntax is module..

script = templatefile("${path.module}/user-data.sh", { ... })

starting with Terraform 0.13, the count meta-argument can be used with modules. So you could use something like this:

module "instances" {
  source = "/some/module/path"

  count = 3
}

You can also use it in outputs vars: value = module.instances[*]

module "subnet" {
  source   = "../modules/subnet"
  for_each = toset(var.azs)

  name = "subnet-${each.key}"
  az   = each.value
}

for_each keeps addresses stable and lets you add or remove AZs without re-creating the entire module.

terraform import is a CLI command used for importing an existing infrastructure into Terraform's state.

It's does NOT create the definitions/configuration for creating such infrastructure.

1. You have existing resources in one of the providers and they are not managed by Terraform (as in not included in the state)
2. You lost your tfstate file and need to rebuild it

**/.terraform/*
*.tfstate
*.tfstate.*
*.tfvars
*.tfvars.json

You don't want to store state file nor any downloaded providers in .terraform directory. It also doesn't makes sense to share/store the state backup files.

Nothing, because user_data is executed on boot so if an instance is already running, it won't change anything.

To make it effective you'll have to use user_data_replace_on_change = true.

Add the following to "aws_launch_configuration" resource

lifecycle {
  create_before_destroy = true
}

This will change the order of how Terraform works. First it will create the new resource (launch configuration). then it will update other resources to reference the new launch configuration and finally, it will remove old resources

provider "aws" {
  region = "us-west-1"
  alias = "west_region"
}

provider "aws" {
  region = "us-east-1"
  alias = "east_region"
}

data "aws_region" "west_region" {
  provider = aws.west_region
}

data "aws_region" "east_region" {
  provider = aws.east_region
}

To use it:

resource "aws_instance" "west_region_instance" {
  provider = aws.west_region
  instance_type = "t2.micro"
  ...
}

module "some_module" {
  source = "..."

  providers = {
    aws = aws.some_region
  }

  ...
}

One way is to define multiple different provider blocks, each with its own "assume_role"

provider "aws" {
  region = "us-west-1"
  alias = "some-region"

  assume_role {
    role_arn = "arn:aws:iam:::role/"
  }
}

Using validation block

variable "some_var" {
  type = number

  validation {
    condition = var.some_var > 1
    error_message = "you have to specify a number greater than 1"
  }

}

It's not secure! you should never store credentials in plain text this way.

1. Use environment variables
2. Use password CLIs (like 1Password which is generic but there also specific provider options like aws-vault)

That very much depends on the CI/CD system/platform you are using.

• GitHub Actions: Use Open ID Connect (OIDC) to establish connection with your provider. You then can specify in your GitHub Actions workflow the following:

- uses: aws-actions/configure-aws-credentials@v1
with:
 role-to-assume: arn:aws:iam::someIamRole
 aws-region: ...

• Jenkins: If Jenkins runs on the provider, you can use the provider access entities (like roles, policies, ...) to grant the instance, on which Jenkins is running, access control
• CircleCI: you can use CircleCI Context and then specify it in your CircleCI config file

context:
- some-context

Pros:

• You avoid using secrets directly in configurations in plain text
• free (no need to pay for secret management platforms/solutions)
• Straightforward to use

Cons:

• Configurations might not be usable without the environment variables which may make impact the user experience as the user has to know what environment variables he should pass for everything to work properly
• Mostly managed outside of Terraform mechanisms which makes it hard to enforce, track, ... anything that is related to secrets when it depends on the user to pass environment variables

False. State files include sensitive data as it is. Which means it's very important that wherever you store your state file, it's encrypted and accessible only to those who should be able to access it.

False. It doesn't matter where your secrets store (file, environment variables, centralized secrets store), they will be visible in both state file and plan output.

There is no right or wrong answer, just what you personally adopted or your team, and being able to explain why.

One common approach is to have a separate directory for each environment.

terraform_project/
  staging/
  production/

Each environment has its own backend (as you don't want to use the same authentication and access controls for all environments)

Going further, under each environment you'll separate between components, applications and services

terraform_project/
  staging/
    applications/
      some-app-service-1/
      some-app-service-2/
    databases/
      mongo/
      postgres/
    networking/

Again, no right or wrong answer. Just your personal experience.

main.tf providers.tf outputs.tf variables.tf dependencies.tf

Each one of these files can be divided to smaller parts if needed (no reason to maintain VERY long files)

Suggest to use Terraform modules.

There are multiple ways to deal with it:

1. Write scripts that perform some commands recursively with different conditions
2. Use tools like Terragrunt where you commands like "run-all" that can run in parallel on multiple different paths

A good solution for not including shell scripts inline (as in inside terraform configuration files) is to keep them in a separate file and then use the terraform templatefile function to render and get them as a string

Using Terraform modules can help greatly with duplicated code and so different environments for example (staging and production) can reuse the same code by using the same modules.

Using variables might not be a good solution because some things shouldn't be exposed and accidentally overridden. In such case you might want to use the concept of locals

Instead of defining tags at resource level, consider using default_tags as part of the provider configuration.

If it's a matter of changing a resource name, you could make use of terraform state mv

Use the meta-argument depends_on in the app resource definition. This way the app will depend on the cluster resource and order will be maintained in creation of the resources.