Terraform on AWS: IAM (Users, Roles, Policies, Instance Profiles) & S3 (Buckets, Policies, Encryption, Versioning)

Two questions decide whether anything you build on AWS is secure: who is allowed to do this? and is the data locked down? The first is IAM — the identity and permission engine that gates every single API call in the account. The second, for the most common data store on the planet, is S3 — and the difference between a private, encrypted, versioned bucket and the next headline breach is about fifteen lines of Terraform that most people never write. This lesson teaches both halves and the place they meet: an EC2 workload that assumes an IAM role, carries it via an instance profile, and reads objects from a KMS-encrypted bucket whose own policy and Block Public Access settings lock everyone else out.

We treat IAM and S3 as one story because in real infrastructure they are inseparable. An IAM role with s3:GetObject is useless if the bucket denies it; a perfectly hardened bucket is useless if the role can’t reach it; and an object encrypted with a customer KMS key stays unreadable until the caller also holds kms:Decrypt — the single most-missed permission in all of AWS. You will learn to reason about the whole chain: identity-based policy on the role, resource-based policy on the bucket, the KMS key policy behind the encryption, and the trust policy that lets EC2 become the role in the first place. Then you will build every piece with Terraform and prove it works with the aws CLI.

This is a relentlessly hands-on lesson. It assumes you already know core Terraform — HCL, resources, variables, for_each, state, the plan/apply loop — from the course’s foundation tier, and that you can already authenticate the AWS provider and point Terraform at a remote S3/DynamoDB backend, which the Terraform on AWS: getting started, provider authentication & the S3/DynamoDB backend lesson sets up. Here we take that starting point and build the identity-and-storage core that almost every later AWS lesson reuses.

What you’ll build

The scenario is the one every application team hits in week one: you have an EC2-hosted service that needs to read configuration files, model artifacts, or user uploads from S3, and you must do it without baking an access key into the AMI, without making the bucket public, and without granting the box more than the one read it actually needs. That is the canonical AWS pattern — workload identity via an instance profile, least-privilege via a scoped IAM policy, and a bucket hardened by default — and getting it right once gives you a template you will copy into every service afterwards.

Concretely, by the end you will have produced a small root module — versions.tf, providers.tf, variables.tf, main.tf, outputs.tf — that creates, in one terraform apply: a customer-managed KMS key (with rotation) for encryption; a private S3 bucket whose name is globally unique, with versioning on, SSE-KMS default encryption, all four Block Public Access flags on, ACLs disabled (BucketOwnerEnforced), a lifecycle rule that tiers objects to Infrequent Access then Glacier and expires old versions, and a bucket policy that denies any non-TLS request and explicitly allows just the app role; an IAM role whose trust policy lets EC2 assume it; a least-privilege identity policy — built with aws_iam_policy_document — granting exactly s3:GetObject, s3:ListBucket, and kms:Decrypt; and an instance profile that hands that role to an EC2 instance. Then you will init, plan, apply, verify each control with the aws CLI, and destroy cleanly — with the two destroy traps (a non-empty versioned bucket, and a KMS key that only schedules deletion) called out.

Why Terraform for identity and storage rather than the console, a pile of aws commands, or CloudFormation? Because IAM and S3 are exactly where click-ops rots: a bucket made “temporarily” public in the console three years ago is still public; an IAM policy pasted by hand drifts from its twin in the next account; nobody can diff what’s live against what was intended. Terraform gives you a declarative, reviewed, plan-before-apply description of every policy statement and every bucket flag, with a state file that detects drift and a module system that makes the pattern reusable across accounts. Here is the honest comparison for this task — provisioning and continuously governing IAM identities and S3 buckets:

The architecture you are wiring has five stages left to right — Terraform authors the policy, the role carries it, EC2 wears the role, S3 stores the data, and KMS encrypts it — and the diagram below is the mental model to keep open for the rest of the lesson.

Reading it left to right: Terraform renders a least-privilege JSON with aws_iam_policy_document, attaches it to an IAM role whose trust policy admits the EC2 service, wraps the role in an instance profile handed to an EC2 instance, which then reads a private, versioned, Block-Public-Access-locked S3 bucket — every object encrypted with a KMS CMK and every request forced onto TLS by the bucket policy. The six badges mark the decisions that trip people up: building policies with the data source instead of raw JSON, the role’s trust policy, the instance-profile-to-EC2 hop, Block Public Access as the default, SSE-KMS plus versioning, and least privilege spelled out (including the kms:Decrypt that everyone forgets). Each is a section below.

The IAM model: identities, policies and how a request is evaluated

Before any HCL, you have to be able to reason about IAM the way AWS’s authorization engine does, because every “AccessDenied” you will ever debug is the engine telling you it followed its rules and you didn’t. IAM has exactly two kinds of thing — principals (who is calling) and policies (what is allowed) — and a small, deterministic algorithm that combines them.

A principal is an identity that makes a request: an IAM user, an IAM role session (the temporary credentials you get after assuming a role), the account root, or an AWS service acting on your behalf (like ec2.amazonaws.com). A policy is a JSON document of statements, each of which says Allow or Deny some Actions on some Resources, optionally for some Principals and under some Conditions. The crucial split is where the policy is attached, because that determines its type:

The whole IAM surface, expressed as Terraform resources, is worth pinning up front — this is the IAM resource map you will reach for constantly:

How a request is actually evaluated

When a principal calls an API, AWS gathers every policy that could apply — the identity-based policies on the caller, any resource-based policy on the target, the permissions boundary, any session policy, and any SCP — and runs a fixed decision:

Two consequences shape every policy you write. First, everything is denied by default — IAM is deny-by-default, so a policy only ever adds permissions; you never need to “allow everything then subtract.” Second, an explicit Deny is absolute — you cannot override it with an Allow anywhere, which is exactly why the aws:SecureTransport deny in a bucket policy is bulletproof. There is one important asymmetry between identity- and resource-based policies for same-account access: if the caller and the resource are in the same account, an Allow in either the identity policy or the resource policy is sufficient. For cross-account access, you need an Allow in both — the identity policy in the caller’s account and the resource policy in the resource’s account. That single rule explains most cross-account S3 and KMS puzzles.

Writing policies the idiomatic way: aws_iam_policy_document

An IAM policy is JSON, and you can produce that JSON three ways in Terraform. Only one of them is the right default. Here they are, worst to best:

# 1) Heredoc raw JSON — brittle: no validation, manual escaping, string interpolation
resource "aws_iam_policy" "bad" {
  name   = "read-bucket"
  policy = <<-EOT
    {
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Action": "s3:GetObject",
        "Resource": "${aws_s3_bucket.app.arn}/*"
      }]
    }
  EOT
}

# 2) jsonencode() — HCL-native, no escaping, but still a hand-built object you must get right
resource "aws_iam_policy" "ok" {
  name = "read-bucket"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "s3:GetObject"
      Resource = "${aws_s3_bucket.app.arn}/*"
    }]
  })
}

# 3) aws_iam_policy_document data source — validated, typed, composable (the idiomatic way)
data "aws_iam_policy_document" "good" {
  statement {
    sid       = "ReadObjects"
    effect    = "Allow"
    actions   = ["s3:GetObject"]
    resources = ["${aws_s3_bucket.app.arn}/*"]
  }
}
resource "aws_iam_policy" "good" {
  name   = "read-bucket"
  policy = data.aws_iam_policy_document.good.json
}

The three approaches, weighed:

Why the data source wins in practice: it lets Terraform interpolate real ARNs and account IDs as first-class values (no string-concatenation bugs), it can merge documents (source_policy_documents to layer a base policy, override_policy_documents to patch statements by sid), and you can generate statements with dynamic "statement" blocks. The document’s arguments map one-to-one onto IAM’s JSON, which is exactly why it’s easy to read:

Conditions are where least-privilege gets surgical, and a handful of operators cover most real policies:

IAM roles, trust policies and instance profiles

A role is an identity nobody logs into — it has no password and no long-lived keys. Instead it has a trust policy (assume_role_policy) that names who may assume it, and when they do, AWS STS hands them temporary credentials that expire in an hour or so. This is the beating heart of secure AWS: EC2 instances, Lambda functions, EKS pods, CI pipelines, and cross-account access all work by assuming a role and getting short-lived creds — no secrets at rest.

The trust policy is separate from and orthogonal to the permission policies. A role has exactly one trust policy answering who can become me, and zero-or-more permission policies (managed and/or inline) answering what I can do once assumed. The trust policy’s principals block is what varies by use case:

Two of those — GitHub-Actions OIDC and EKS IRSA (IAM Roles for Service Accounts) — deserve a note because they are the modern way to give CI and Kubernetes AWS access without any secret at rest: an external OIDC identity provider issues a short-lived token, and the trust policy accepts it if a Condition matches the token’s sub claim. IRSA in particular is a whole topic of its own — the OIDC provider, the ServiceAccount annotation, the pod-identity webhook — and this course covers it in a dedicated EKS lesson; here we focus on the EC2 case, which is the simplest trust policy of all.

Here is the EC2 trust policy, built with the data source and wired to a role:

data "aws_iam_policy_document" "ec2_trust" {
  statement {
    sid     = "EC2AssumeRole"
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "app" {
  name               = "kloudvin-dev-app"
  assume_role_policy = data.aws_iam_policy_document.ec2_trust.json  # the TRUST policy
}

Attaching permissions: managed vs inline

Once the role exists, you grant it permissions. There are two shapes, and choosing correctly matters for reuse and for drift:

The rule of thumb: customer-managed policy + attachment for anything reusable or reviewed on its own; inline only for a grant so specific it should die with the role. Reach for AWS-managed policies (arn:aws:iam::aws:policy/...) sparingly — AmazonS3FullAccess is the opposite of least privilege.

Instance profiles: how EC2 wears a role

Here is the subtlety that confuses everyone: EC2 cannot reference an IAM role directly. It references an instance profile, which is a thin container holding exactly one role. Terraform makes the profile explicit (the console hides it by auto-creating one behind the scenes):

resource "aws_iam_instance_profile" "app" {
  name = "kloudvin-dev-app"
  role = aws_iam_role.app.name   # wraps exactly one role
}

# ... and the EC2 instance references the PROFILE, not the role:
# resource "aws_instance" "app" {
#   iam_instance_profile = aws_iam_instance_profile.app.name
#   ...
# }

Once the profile is attached, any AWS SDK on that instance discovers the role’s temporary credentials via the Instance Metadata Service and refreshes them automatically. No access key ever touches the box — which is the entire point.

Users, groups, access keys — and why to avoid them

You can create aws_iam_user + aws_iam_access_key, but for workloads you almost never should. Long-lived access keys are the number-one source of AWS credential leaks (committed to git, baked into images, pasted into Slack). The modern posture:

And a permissions boundary is the guardrail that lets you delegate safely: it is a managed policy set as a ceiling on a role or user, so even if someone attaches AdministratorAccess, the effective permission is the intersection of the identity policy and the boundary. You attach one with the permissions_boundary argument on aws_iam_role/aws_iam_user, and it is how platform teams let application teams create their own roles without being able to escalate.

S3 buckets and the modern split resources

Now the storage half. The single most important thing to know about S3 in Terraform is that the aws_s3_bucket resource changed shape in AWS provider v4 (2022), and every tutorial written before then is wrong today. The old resource was a monolith: versioning, encryption, lifecycle, logging, ACLs, CORS, and website config were all arguments inside aws_s3_bucket. The new model splits every one of those into its own resource. This is the change that breaks people migrating old code, and the thing to internalize before writing a single bucket.

Why the split is actually better, once you get past the surprise: each concern is now independently planned, import-able, and for_each-able; teams can own different resources; and a change to a lifecycle rule no longer re-reads the entire bucket. The bucket resource itself becomes almost empty — just the name and a couple of top-level settings:

resource "aws_s3_bucket" "app" {
  bucket        = local.bucket_name  # globally unique across ALL of AWS
  force_destroy = true               # ⚠️ dev-only: lets destroy empty the bucket
}

Two arguments carry weight here. bucket must be globally unique across every AWS account on earth and DNS-compatible (3–63 chars, lowercase, no underscores) — pick a naming scheme that won’t collide (we suffix with the account ID below). force_destroy controls whether terraform destroy will empty the bucket first; leave it false in production so Terraform refuses to nuke data, set it true in throwaway demos so you can tear down cleanly. The split resources you attach to it, each doing one job:

Encryption: SSE-S3 vs SSE-KMS

S3 can encrypt every object at rest, and it always should. The choice is which key:

We use SSE-KMS with a customer-managed key because it gives an auditable kms:Decrypt trail in CloudTrail and lets you revoke access by editing the key policy — powerful, but it introduces the trap the whole lesson circles back to: reading a KMS-encrypted object requires kms:Decrypt on the key in addition to s3:GetObject. Two gates, not one. And always set bucket_key_enabled = true: an S3 Bucket Key caches a data key so S3 doesn’t call KMS on every single object, cutting KMS request costs by up to 99% on hot buckets.

Lifecycle: tier cold data down, expire old versions

A lifecycle configuration moves objects to cheaper storage classes as they age and deletes them when they’re spent. On a versioned bucket you also manage the noncurrent (old) versions, or they accumulate forever and quietly cost money:

The lifecycle resource maps those into rules. Note the two footguns baked into the resource: each rule requires a filter {} (empty means “whole bucket”) in provider v5, and if you set noncurrent_version_* actions you should add a depends_on on the versioning resource so ordering is deterministic:

resource "aws_s3_bucket_lifecycle_configuration" "app" {
  bucket     = aws_s3_bucket.app.id
  depends_on = [aws_s3_bucket_versioning.app]

  rule {
    id     = "archive-and-expire"
    status = "Enabled"
    filter {}                                   # whole bucket; a required block in v5

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 90
      storage_class = "GLACIER"
    }
    expiration {
      days = 365                                # expire current versions after a year
    }

    noncurrent_version_transition {
      noncurrent_days = 30
      storage_class   = "STANDARD_IA"
    }
    noncurrent_version_expiration {
      noncurrent_days = 90                      # purge old versions after 90 days
    }
  }
}

Block Public Access and disabling ACLs

Block Public Access (BPA) is the seatbelt. It is four independent booleans that, when all true, make it impossible for any ACL or bucket policy to expose the bucket — even if someone later writes a public policy by mistake, BPA overrides it:

Set all four to true on every bucket unless you are deliberately hosting a public website (and even then, front it with CloudFront + OAC instead). Pair BPA with aws_s3_bucket_ownership_controls set to BucketOwnerEnforced, which disables ACLs entirely — the modern default — so access is governed only by IAM and bucket policies, never by the legacy per-object ACL system that caused a decade of leaks.

Bucket policy vs IAM policy — which governs access?

Both can grant access to a bucket, and knowing which to use is a senior-level distinction:

Our demo uses both, deliberately: the identity policy on the role grants the read (sufficient for same-account), and the bucket policy adds two defense-in-depth statements — a blanket Deny on any non-TLS request, and an explicit Allow naming just the app role (which becomes load-bearing the day another account needs in). That layering is the pattern you want in production.

Hands-on: build it with Terraform

Time to build the whole thing end to end. Create a directory and these five files. ⚠️ This provisions real resources. KMS keys and S3 have costs (small here — see the cost section) and you will destroy at the end. Authenticate the AWS provider first (the getting-started lesson covers aws configure, SSO, and the remote backend).

Here is what each file owns:

versions.tf

terraform {
  required_version = ">= 1.6"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"   # allow 5.x, refuse 6.0; pin tighter in prod
    }
  }

  # In a real project, state lives in S3 with a DynamoDB lock (see the getting-started lesson):
  # backend "s3" {
  #   bucket         = "kloudvin-tfstate"
  #   key            = "aws/iam-s3/terraform.tfstate"
  #   region         = "ap-south-1"
  #   dynamodb_table = "kloudvin-tflock"
  #   encrypt        = true
  # }
}

providers.tf

provider "aws" {
  region = var.region

  default_tags {
    tags = {
      Project     = var.project
      Environment = var.environment
      ManagedBy   = "Terraform"
    }
  }
}

variables.tf

variable "region" {
  type        = string
  description = "AWS region to deploy into."
  default     = "ap-south-1"
}

variable "project" {
  type        = string
  description = "Project prefix for names and tags."
  default     = "kloudvin"
}

variable "environment" {
  type        = string
  description = "Environment (dev/stg/prod)."
  default     = "dev"
}

variable "permissions_boundary_arn" {
  type        = string
  description = "Optional permissions-boundary policy ARN to cap the role."
  default     = null
}

main.tf

data "aws_caller_identity" "current" {}
data "aws_partition" "current" {}

locals {
  name        = "${var.project}-${var.environment}"
  # Bucket names are GLOBAL: suffix with the account id for uniqueness.
  bucket_name = "${var.project}-${var.environment}-${data.aws_caller_identity.current.account_id}"
  account_arn = "arn:${data.aws_partition.current.partition}:iam::${data.aws_caller_identity.current.account_id}:root"
}

# ─────────────────────────── KMS key for SSE-KMS ───────────────────────────
# Default key policy: give the account root full control so IAM policies can
# delegate. Restricting this too far is the #1 way to lock yourself out of a key.
data "aws_iam_policy_document" "kms" {
  statement {
    sid       = "EnableIAMUserPermissions"
    effect    = "Allow"
    actions   = ["kms:*"]
    resources = ["*"]
    principals {
      type        = "AWS"
      identifiers = [local.account_arn]
    }
  }
}

resource "aws_kms_key" "s3" {
  description             = "SSE-KMS CMK for ${local.bucket_name}"
  deletion_window_in_days = 7      # ⚠️ deletion is SCHEDULED, min 7 days
  enable_key_rotation     = true   # annual automatic rotation
  policy                  = data.aws_iam_policy_document.kms.json
}

resource "aws_kms_alias" "s3" {
  name          = "alias/${local.name}-s3"
  target_key_id = aws_kms_key.s3.key_id
}

# ─────────────────────────── S3 bucket + hardening ─────────────────────────
resource "aws_s3_bucket" "app" {
  bucket        = local.bucket_name
  force_destroy = true   # ⚠️ dev-only: empties the (versioned) bucket on destroy
}

resource "aws_s3_bucket_ownership_controls" "app" {
  bucket = aws_s3_bucket.app.id
  rule { object_ownership = "BucketOwnerEnforced" }  # ACLs off — modern default
}

resource "aws_s3_bucket_public_access_block" "app" {
  bucket                  = aws_s3_bucket.app.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_versioning" "app" {
  bucket = aws_s3_bucket.app.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "app" {
  bucket = aws_s3_bucket.app.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3.arn
    }
    bucket_key_enabled = true   # cache data key → far fewer KMS calls
  }
}

resource "aws_s3_bucket_lifecycle_configuration" "app" {
  bucket     = aws_s3_bucket.app.id
  depends_on = [aws_s3_bucket_versioning.app]

  rule {
    id     = "archive-and-expire"
    status = "Enabled"
    filter {}

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 90
      storage_class = "GLACIER"
    }
    expiration {
      days = 365
    }
    noncurrent_version_transition {
      noncurrent_days = 30
      storage_class   = "STANDARD_IA"
    }
    noncurrent_version_expiration {
      noncurrent_days = 90
    }
  }
}

# ─────────────────────────── IAM role (EC2 trust) ──────────────────────────
data "aws_iam_policy_document" "ec2_trust" {
  statement {
    sid     = "EC2AssumeRole"
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "app" {
  name                 = "${local.name}-app"
  assume_role_policy   = data.aws_iam_policy_document.ec2_trust.json
  permissions_boundary = var.permissions_boundary_arn
}

# ──────────────────── Least-privilege identity policy ──────────────────────
data "aws_iam_policy_document" "app_s3_read" {
  statement {
    sid       = "ReadObjects"
    effect    = "Allow"
    actions   = ["s3:GetObject"]
    resources = ["${aws_s3_bucket.app.arn}/*"]   # objects → /* suffix
  }
  statement {
    sid       = "ListBucketOnly"
    effect    = "Allow"
    actions   = ["s3:ListBucket"]
    resources = [aws_s3_bucket.app.arn]          # the bucket itself, no /*
  }
  statement {
    sid       = "DecryptWithCMK"
    effect    = "Allow"
    actions   = ["kms:Decrypt"]
    resources = [aws_kms_key.s3.arn]             # the MOST-forgotten statement
  }
}

resource "aws_iam_policy" "app_s3_read" {
  name   = "${local.name}-s3-read"
  policy = data.aws_iam_policy_document.app_s3_read.json
}

resource "aws_iam_role_policy_attachment" "app_s3_read" {
  role       = aws_iam_role.app.name
  policy_arn = aws_iam_policy.app_s3_read.arn
}

# ─────────────────────────── Instance profile ──────────────────────────────
resource "aws_iam_instance_profile" "app" {
  name = "${local.name}-app"
  role = aws_iam_role.app.name
}

# ─────────────── Bucket policy: TLS-only + explicit role allow ──────────────
data "aws_iam_policy_document" "bucket" {
  statement {
    sid       = "DenyInsecureTransport"
    effect    = "Deny"
    actions   = ["s3:*"]
    resources = [aws_s3_bucket.app.arn, "${aws_s3_bucket.app.arn}/*"]
    principals {
      type        = "AWS"
      identifiers = ["*"]
    }
    condition {
      test     = "Bool"
      variable = "aws:SecureTransport"
      values   = ["false"]
    }
  }

  statement {
    sid       = "AllowAppRoleRead"
    effect    = "Allow"
    actions   = ["s3:GetObject", "s3:ListBucket"]
    resources = [aws_s3_bucket.app.arn, "${aws_s3_bucket.app.arn}/*"]
    principals {
      type        = "AWS"
      identifiers = [aws_iam_role.app.arn]
    }
  }
}

resource "aws_s3_bucket_policy" "app" {
  bucket     = aws_s3_bucket.app.id
  policy     = data.aws_iam_policy_document.bucket.json
  depends_on = [aws_s3_bucket_public_access_block.app]  # BPA must land first
}

outputs.tf

output "bucket_name" {
  description = "The globally unique bucket name."
  value       = aws_s3_bucket.app.id
}

output "bucket_arn" {
  value = aws_s3_bucket.app.arn
}

output "role_arn" {
  value = aws_iam_role.app.arn
}

output "instance_profile_name" {
  description = "Attach this to an EC2 instance via iam_instance_profile."
  value       = aws_iam_instance_profile.app.name
}

output "kms_key_arn" {
  value = aws_kms_key.s3.arn
}

Step 1 — terraform init

terraform init

You should see the AWS provider download and Terraform has been successfully initialized! If you uncommented the S3 backend, you’ll also see it configure remote state.

Step 2 — terraform plan

terraform plan

Terraform prints a diff. Read the summary line — you should see 13 resources to add (the KMS key + alias, the bucket + six split resources, the role + policy + attachment + instance profile, and the bucket policy) and nothing to change or destroy:

Plan: 13 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + bucket_arn            = (known after apply)
  + bucket_name           = "kloudvin-dev-123456789012"
  + instance_profile_name = "kloudvin-dev-app"
  + kms_key_arn           = (known after apply)
  + role_arn              = (known after apply)

Notice bucket_name is known now (we built it from the account id) while ARNs are (known after apply). Read the plan for the bucket policy and confirm the Deny on aws:SecureTransport is present.

Step 3 — terraform apply

terraform apply    # review, then type: yes

⚠️ This creates billable resources. Watch the ordering Terraform derives from the dependency graph: the KMS key first (the encryption config needs its ARN), the bucket, then the split resources, the role and its policy in parallel, and finally the bucket policy (after BPA). On success:

Apply complete! Resources: 13 added, 0 changed, 0 destroyed.

Outputs:
bucket_arn            = "arn:aws:s3:::kloudvin-dev-123456789012"
bucket_name           = "kloudvin-dev-123456789012"
instance_profile_name = "kloudvin-dev-app"
kms_key_arn           = "arn:aws:kms:ap-south-1:123456789012:key/8f1c…"
role_arn              = "arn:aws:iam::123456789012:role/kloudvin-dev-app"

Step 4 — verify every control with the aws CLI

Don’t trust; verify. Each command below confirms one of the controls you declared:

BUCKET=$(terraform output -raw bucket_name)

# Versioning is Enabled
aws s3api get-bucket-versioning --bucket "$BUCKET"
# → { "Status": "Enabled" }

# Default encryption is SSE-KMS with our key
aws s3api get-bucket-encryption --bucket "$BUCKET" \
  --query 'ServerSideEncryptionConfiguration.Rules[0].ApplyServerSideEncryptionByDefault'
# → { "SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "arn:aws:kms:...:key/8f1c..." }

# All four Block Public Access flags are true
aws s3api get-public-access-block --bucket "$BUCKET" \
  --query 'PublicAccessBlockConfiguration'
# → all four true

# The lifecycle rule exists
aws s3api get-bucket-lifecycle-configuration --bucket "$BUCKET" \
  --query 'Rules[0].[ID,Status]'
# → [ "archive-and-expire", "Enabled" ]

# The instance profile wraps the role
aws iam get-instance-profile --instance-profile-name "$(terraform output -raw instance_profile_name)" \
  --query 'InstanceProfile.Roles[0].RoleName'
# → "kloudvin-dev-app"

Now prove the encryption is real by round-tripping an object (your own admin creds can write; the app role only reads):

echo "hello kloudvin" > demo.txt
aws s3 cp demo.txt "s3://$BUCKET/demo.txt"

aws s3api head-object --bucket "$BUCKET" --key demo.txt \
  --query '[ServerSideEncryption, SSEKMSKeyId]'
# → [ "aws:kms", "arn:aws:kms:...:key/8f1c..." ]   ← encrypted with our CMK

Finally, prove least privilege without launching an instance, using the policy simulator — the app role may GetObject but not PutObject or DeleteObject:

ROLE=$(terraform output -raw role_arn)
aws iam simulate-principal-policy --policy-source-arn "$ROLE" \
  --action-names s3:GetObject s3:PutObject s3:DeleteObject \
  --resource-arns "$(terraform output -raw bucket_arn)/demo.txt" \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' --output table
# → GetObject   allowed
#   PutObject   implicitDeny
#   DeleteObject implicitDeny

That is the whole thesis in one command: the role can do exactly the one thing it needs, and nothing else. On a real EC2 instance carrying this instance profile, the AWS SDK would find these credentials via IMDS automatically and the same GetObject would succeed with no keys anywhere on the box — launching that instance (with a security group and key pair) is the subject of the Terraform on AWS: security groups, EC2 & key pairs lesson.

Step 5 — terraform destroy (⚠️ empty the bucket first)

terraform destroy    # review, then type: yes

Because we set force_destroy = true, Terraform empties the (versioned) bucket — deleting every object version and delete marker — before removing it. Without force_destroy, destroy fails with BucketNotEmpty and you must purge it manually first:

# Manual purge for a versioned bucket when force_destroy = false:
aws s3api delete-objects --bucket "$BUCKET" --delete "$(aws s3api list-object-versions \
  --bucket "$BUCKET" --query '{Objects: Versions[].{Key:Key,VersionId:VersionId}}' --output json)"
# repeat the same for DeleteMarkers[]  →  then re-run terraform destroy

One more surprise in the output: the KMS key is not deleted immediately — it enters pending deletion for deletion_window_in_days (7 here; 7–30 allowed). This is a safety feature so you can’t instantly destroy data you can no longer decrypt. If you tore down by mistake, aws kms cancel-key-deletion --key-id <id> brings it back within the window.

Variables, outputs and making it reusable

The demo is already parameterised by region, project, and environment. The natural next step is to turn “one bucket + one role” into a repeatable pattern — either many buckets in one config with for_each, or a reusable module.

To manage several buckets from one map, drive aws_s3_bucket (and each split resource) with for_each:

variable "buckets" {
  description = "Map of logical name → settings."
  type = map(object({
    versioning = bool
    expire_days = number
  }))
  default = {
    uploads  = { versioning = true,  expire_days = 365 }
    logs     = { versioning = false, expire_days = 90 }
  }
}

resource "aws_s3_bucket" "this" {
  for_each = var.buckets
  bucket   = "${var.project}-${var.environment}-${each.key}-${data.aws_caller_identity.current.account_id}"
}

resource "aws_s3_bucket_versioning" "this" {
  for_each = { for k, v in var.buckets : k => v if v.versioning }
  bucket   = aws_s3_bucket.this[each.key].id
  versioning_configuration { status = "Enabled" }
}

Two idioms to notice: you reference the parent by key (aws_s3_bucket.this[each.key].id), and you can filter the map (if v.versioning) so the versioning resource only exists for buckets that want it. The same for_each pattern extends to encryption, BPA, and lifecycle.

For production, you often shouldn’t roll your own at all — the community modules are battle-tested and encode exactly the hardening we did by hand:

When to use a module vs roll your own:

The honest guidance: build it by hand once (which you just did) so you understand every knob, then adopt terraform-aws-modules/s3-bucket for real fleets so you’re not re-deriving Block Public Access in twenty repos.

Common mistakes and troubleshooting

IAM and S3 generate a specific, recognizable set of failures. This table is the one to keep open mid-incident:

The nastiest three deserve prose. The kms:Decrypt trap is the single most common S3 support puzzle: the object is encrypted with a customer key, s3:GetObject succeeds at the S3 layer, but S3 then calls KMS on the caller’s behalf to unwrap the data key, and that call is denied because the role’s policy never mentioned the key. The symptom is a confusing AccessDenied on GetObject even though your S3 permissions are obviously correct. Always grant kms:Decrypt (and kms:GenerateDataKey if the workload writes encrypted objects) on the exact key ARN. The trust-vs-permission confusion is next: people put their s3:GetObject grant in the assume_role_policy and wonder why nothing works — the trust policy only answers who may assume the role and only ever contains sts:AssumeRole* with principals; permissions go in attached policies. The KMS lockout is the scariest: a well-meaning “least privilege” edit to a key policy that removes the account-root kms:* statement can make the key unmanageable and its data unrecoverable, because the key policy is the root of trust for the key — always keep the EnableIAMUserPermissions statement granting the account root kms:*.

Cost, cleanup and production notes

Left running, this stack costs very little, but the pieces are worth knowing so nothing surprises you:

The dominant cost is the KMS key (~$1/month) and, over time, accumulated object versions on a versioned bucket — which is exactly why the lifecycle rule’s noncurrent_version_expiration matters. To clean up completely: terraform destroy (with force_destroy = true the bucket empties itself), then remember the KMS key sits in pending-deletion for the window — that’s expected and free.

Five production-hardening notes to carry forward:

Cheat-sheet

The resources for this topic, at a glance:

Commands you’ll live in:

Interview and exam questions

1. What is the difference between an identity-based and a resource-based policy? An identity-based policy is attached to a principal (user/group/role) and says what that identity can do; a resource-based policy is attached to the resource (bucket, KMS key, queue) and says who may touch it. For same-account access, an Allow in either is enough; for cross-account you need both.

2. Walk through IAM’s evaluation logic. Gather all applicable policies (identity, resource, boundary, session, SCP). An explicit Deny anywhere wins. Otherwise the action must be allowed by any SCP and the permissions boundary, and there must be an explicit Allow — with no Allow, the implicit deny applies. Deny-by-default; explicit-deny-always-wins.

3. Why use aws_iam_policy_document instead of a heredoc or jsonencode()? It validates structure, interpolates real ARNs/account-ids as typed values (no string-concat bugs), adds Version automatically, and composes documents via source_policy_documents/override_policy_documents and dynamic statements. Heredoc has no validation; jsonencode is fine for tiny docs but doesn’t compose.

4. What is a trust policy and how does it differ from a permission policy? The trust policy (assume_role_policy) answers who may assume this role — it contains sts:AssumeRole* and principals, never a Resource. Permission policies (attached separately) answer what the role can do once assumed. They are orthogonal.

5. Why can’t EC2 use an IAM role directly, and what bridges the gap? EC2 attaches an instance profile, a container that holds exactly one role. The console hides it by auto-creating one; in Terraform you create aws_iam_instance_profile explicitly and set iam_instance_profile on the instance. IMDS then vends the role’s temporary credentials.

6. A role has s3:GetObject but gets AccessDenied reading an object. Why? The bucket uses SSE-KMS with a customer key and the role lacks kms:Decrypt on that key. S3 must call KMS to unwrap the data key; that call is denied. Add kms:Decrypt (and kms:GenerateDataKey for writes) on the key ARN.

7. What are the four Block Public Access flags and why does BPA override a bucket policy? block_public_acls, ignore_public_acls, block_public_policy, restrict_public_buckets. BPA is evaluated as an overriding control: even a public-granting bucket policy or ACL is neutralized when the flags are on, which is why it’s the definitive S3 safety net.

8. Explain the S3 “split resources” change and why it matters for Terraform. Since AWS provider v4, configuration that used to be arguments inside aws_s3_bucket (versioning, encryption, lifecycle, ACL, logging, CORS, website, replication) moved into separate resources (aws_s3_bucket_versioning, etc.). Old tutorials break on v4+; you must use the split resources, which also plan and import independently.

9. How do you safely let a delegated team create roles without privilege escalation? Attach a permissions boundary — a managed policy set as a ceiling via permissions_boundary. Effective permissions become the intersection of the identity policy and the boundary, so even attaching AdministratorAccess can’t exceed the boundary.

10. (Terraform Associate 003) You add aws_s3_bucket_versioning to a bucket already managed by aws_s3_bucket and plan shows the bucket unchanged. Is that expected? Yes — in the split model the versioning is a distinct resource that references the bucket by id; adding it plans one new resource and leaves the bucket resource itself untouched. (On very old code you’d instead be removing an inline versioning block.)

11. (Terraform Associate 003) terraform destroy fails with BucketNotEmpty. What are your options? Either set force_destroy = true on the aws_s3_bucket so Terraform empties it (including all versions and delete markers) before deletion, or manually purge objects, versions, and delete markers with aws s3api delete-objects and re-run destroy.

12. Why does destroying a KMS key not delete it immediately? KMS schedules key deletion for a mandatory 7–30 day window (deletion_window_in_days) so you can’t instantly and irreversibly lose the ability to decrypt data. Within the window, aws kms cancel-key-deletion reverses it.

Key takeaways

• IAM is deny-by-default and explicit-deny-always-wins. Every AccessDenied is the engine following that rule; a policy only ever adds Allows, and a Deny (like the TLS-only bucket statement) is absolute.
• Build policies with aws_iam_policy_document. It validates, interpolates real ARNs, composes, and adds Version — the idiomatic default over heredoc JSON or jsonencode().
• Roles carry permissions; trust policies decide who may assume them; instance profiles hand a role to EC2. Keep the three concepts distinct and most IAM confusion evaporates.
• Reading an SSE-KMS object needs kms:Decrypt as well as s3:GetObject. Two gates — the bucket and the key — and the KMS one is the most-forgotten permission in AWS.
• Use S3’s split resources and harden by default: versioning on, SSE-KMS with bucket_key_enabled, all four Block Public Access flags true, BucketOwnerEnforced (ACLs off), a lifecycle rule that expires old versions, and a bucket policy that denies non-TLS traffic.
• force_destroy for demos, not production; production buckets should refuse to delete data, and KMS keys only ever schedule deletion behind a 7–30 day window.
• Verify, don’t trust: aws s3api get-bucket-* for the controls and aws iam simulate-principal-policy to prove the role can do exactly one thing and nothing more.