Let's think about this for a second
You configure a provider block like `provider "aws" { region = "us-east-1" }` — each provider has its own authentication method (for AWS: access key/secret key, environment variables, or an IAM role). Resource type names (`aws_instance`, `aws_s3_bucket`, `azurerm_virtual_machine`) include the provider name as a prefix — you can look up every argument for a given resource type in the provider's documentation on the Terraform Registry. You should constrain the provider version in the `required_providers` block, to guard against a version update suddenly breaking your config.
Let's connect this to a real scenario
If you open the Terraform Registry (registry.terraform.io) and look up the `aws_instance` resource's documentation, you can read every argument (ami, instance_type, tags) — whenever you want to use a new resource, it's worth checking the Registry for its argument list. Writing a provider version as `~> 5.0` means 'any 5.x minor version is fine.'
Let's look at an example
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.micro"
tags = {
Name = "tutorial-web-server"
}
}$ terraform plan
+ resource "aws_instance" "web" {
+ ami = "ami-0abcdef1234567890"
+ instance_type = "t3.micro"
...
}
Plan: 1 to add, 0 to change, 0 to destroy.5-minute try-it
Open the Terraform Registry website and look up the documentation for `aws_s3_bucket` (or a provider of your choice) — note down which arguments are required.
A quick word of caution
A resource type's arguments (required vs optional) can change between provider versions — always check the Registry documentation for the exact provider version you're using.