Assignment

The Nautilus DevOps team is automating IAM user creation using Terraform for better identity management.

For this task, create an AWS IAM User using Terraform with the following requirements:

The IAM User name iamuser_mark should be stored in a variable named KKE_user. Note:

The configuration values should be stored in a variables.tf file.
The Terraform script should be structured with a main.tf file referencing variables.tf. The Terraform working directory is /home/bob/terraform.

Right-click under the EXPLORER section in VS Code and select Open in Integrated Terminal to launch the terminal.

Solution

IAM User with Variables — `iamuser_mark` (`KKE_user`)

Two-file structure: variables.tf holds the config, main.tf references it. The IAM User name must be stored in a variable named exactly KKE_user.

`variables.tf`

variable "KKE_user" {
  description = "Name of the IAM user"
  type        = string
  default     = "iamuser_mark"
}

`main.tf`

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

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

resource "aws_iam_user" "mark" {
  name = var.KKE_user

  tags = {
    Name = var.KKE_user
  }
}

How to run

cd /home/bob/terraform
terraform init
terraform apply -auto-approve

How it works

Splitting config from logic

Terraform merges every .tf file in the directory into one configuration, so variables.tf and main.tf act as a single unit — no imports needed. variables.tf declares inputs; main.tf declares resources that consume them via var.<name>.

The variable

variable "KKE_user" — holds the IAM user name, exactly as required. The default of iamuser_mark lets terraform apply run without prompting.
type = string validates the input type at plan time.

The IAM user

name = var.KKE_user — resolves to iamuser_mark. The var. prefix interpolates the variable's value.
iamuser_ prefix matters. These locked-down sandboxes require IAM user names to start with iamuser_. The variable's value already satisfies that, so the create stays inside the login user's permission scope and won't be denied.
IAM is global. The region in the provider is needed to initialize and authenticate, but IAM resources aren't regional — the user is visible account-wide.
No policies, keys, or login profile. The task asks only for the user to exist, so nothing is attached. This keeps the config minimal and avoids the custom-policy / attach restrictions these sandboxes enforce (attaching permissions broader than the login user has would fail with AccessDenied).

Verify

aws iam get-user --user-name iamuser_mark \
  --query 'User.{Name:UserName,Id:UserId,Arn:Arn}'

Expected — the user's name, a unique ID, and an ARN of the form arn:aws:iam::<account-id>:user/iamuser_mark.

2.9 KiB Raw Blame History