Assignment

When establishing infrastructure on the AWS cloud, Identity and Access Management (IAM) is among the first and most critical services to configure. IAM facilitates the creation and management of user accounts, groups, roles, policies, and other access controls. The Nautilus DevOps team is currently in the process of configuring these resources and has outlined the following requirements:

For this task, create an IAM user named iamuser_james using terraform. The Terraform working directory is /home/bob/terraform. Create the main.tf file (do not create a different .tf file) to accomplish this task.

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

Solution

IAM User — `iamuser_james`

Terraform solution to create a single IAM user named iamuser_james.

`main.tf`

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

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

resource "aws_iam_user" "james" {
  name = "iamuser_james"
}

How to run

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

How it works

`aws_iam_user`

This single resource is all the task needs. The name argument sets the IAM user's login/identifier to iamuser_james exactly as required.

A few things worth knowing about what's happening under the hood:

IAM is global, not regional. IAM resources live in the aws partition, not in any one region. The region in the provider block is still required for the provider to initialize and authenticate, but it has no bearing on where the user is created — an IAM user is visible account-wide regardless of region.
The iamuser_ prefix is not cosmetic. In these locked-down sandbox environments, IAM user names must begin with iamuser_. The task-supplied name already satisfies that, so the create call stays within the login user's permission scope and won't get denied.
No path, policy, or login profile is set. The task asks only for the user to exist, so we deliberately don't attach policies, create access keys, or set a console password. That keeps the resource minimal and avoids the inline-policy / custom-policy restrictions that these sandboxes enforce — attaching a policy the login user can't grant would fail with AccessDenied.

Why nothing else is needed

An IAM user with no attached permissions is perfectly valid — it simply can't do anything yet. Groups, policies, access keys, and login profiles are all separate resources you'd add later as requirements dictate. For "create a user named X," one aws_iam_user block is the complete and correct answer.

Verify

aws iam get-user --user-name iamuser_james \
  --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_james.

2.9 KiB Raw Blame History

Assignment

Solution

IAM User — iamuser_james

main.tf