AWS Lab: Secure Access & Least Privilege for CloudNova

📖

1. Overview & Scenario

🏢 The Scenario

A small company called CloudNova is onboarding a new development team. You are the cloud administrator. Your job is to set up secure access, enforce least privilege, and verify the setup using the AWS CLI.

Two new hires — alex.dev and priya.dev — need accounts grouped together, a strong password policy, MFA, and just enough permissions to do their jobs.

🎯 Your Mission

▸ Explore AWS Regions & AZs
▸ Build IAM groups, users, and policies
▸ Enforce strong passwords + MFA
▸ Grant least-privilege access to S3
▸ Create an EC2 role + instance profile
▸ Audit everything with credential reports

"Least privilege is not a one-time task — it is a continuous discipline of granting only the permissions required to perform a task."

— AWS Well-Architected Framework, Security Pillar

🎓

2. Learning Objectives

🌍 Foundation

Explore Global Infrastructure

Use CLI to list Regions and AZs, understanding where your workloads live.

👥 IAM

Create Group, User & Password Policy

Set up the dev team structure with enforced password complexity.

📜 IAM

Write Least-Privilege JSON Policy

Craft a custom policy that grants only what the team needs — nothing more.

🔐 Security

Enable MFA for a User

Add a second authentication factor via the AWS Console.

🎭 IAM

Create EC2 Role & Instance Profile

Grant EC2 instances permissions without embedding long-term credentials.

📊 Auditing

Generate Credential Report

Audit password age, MFA status, and access key rotation across the account.

🧰

3. Prerequisites & Setup

✅ What You Need

✔ AWS account (free tier eligible)
✔ IAM user with admin permissions (not root)
✔ AWS CLI v2 installed and configured
✔ A text editor for JSON policy files
✔ An authenticator app (Google Auth, Authy, 1Password)

⚙️ Verify Your Setup

# Check AWS CLI version
aws --version

# Verify your identity
aws sts get-caller-identity

# Show configured profile
aws configure list

💡 Tip: If you see an error about missing credentials, run aws configure and enter your Access Key ID, Secret Access Key, default Region (e.g., us-east-1), and output format (json).

⚠️ Warning: Never use your root account for everyday work. If you're currently logged in as root, create an admin IAM user first and switch to it. Root should only be used for billing and account-level tasks.

📁 Create Your Working Directory

mkdir -p ~/cloudnova-lab/policies
cd ~/cloudnova-lab

# You will save JSON policies in ./policies/

🛠️

4. Step-by-Step Tasks

10 Tasks

Explore AWS Global Infrastructure

🎯 Goal

Discover which AWS Regions and Availability Zones exist, and identify the closest Region to CloudNova's headquarters.

💻 CLI Commands

# List all AWS Regions (opt-in included)
aws ec2 describe-regions \
  --all-regions \
  --query "Regions[?OptInStatus=='opt-in-not-required'].RegionName" \
  --output table

# List AZs in your default Region
aws ec2 describe-availability-zones \
  --query "AvailabilityZones[].{Name:ZoneName,State:State,ZoneId:ZoneId}" \
  --output table

# Filter to only available AZs
aws ec2 describe-availability-zones \
  --filters "Name=state,Values=available" \
  --query "AvailabilityZones[].ZoneName"

✅ Expected Output

----------------------------
|     DescribeRegions      |
+--------------------------+
|  us-east-1               |
|  us-east-2               |
|  us-west-1               |
|  eu-west-1               |
|  ap-southeast-1          |
+--------------------------+

💡 Tip: Region codes follow a pattern: us-east-1 = US East (N. Virginia). AZ codes append a letter, e.g., us-east-1a.

💡 Why It Matters

Choosing the right Region reduces latency, meets data-residency requirements, and affects service availability and cost. Understanding AZs is essential for high availability design.

Create IAM Group & Set Password Policy

🎯 Goal

Create a Developers group and enforce a strong account-wide password policy.

🖥️ Console Steps (Optional)

Go to IAM → User groups → Create group
Name it Developers
Skip attaching policies for now (we'll do that in Task 3)
Go to IAM → Account settings → Password policy → Edit

💻 CLI Commands

# Create the Developers group
aws iam create-group --group-name Developers

# Configure a strong account password policy
aws iam update-account-password-policy \
  --minimum-password-length 12 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters \
  --allow-users-to-change-password \
  --max-password-age 90 \
  --password-reuse-prevention 5

# Verify the policy
aws iam get-account-password-policy

✅ Expected Output

{
    "PasswordPolicy": {
        "MinimumPasswordLength": 12,
        "RequireSymbols": true,
        "RequireNumbers": true,
        "RequireUppercaseCharacters": true,
        "RequireLowercaseCharacters": true,
        "AllowUsersToChangePassword": true,
        "MaxPasswordAge": 90,
        "PasswordReusePrevention": 5
    }
}

⚠️ Warning: Changing the account password policy affects all IAM users. Confirm with your organization before enforcing a 90-day maximum age.

💡 Why It Matters

Groups simplify permission management at scale. A strong password policy is the first line of defense against credential-based attacks.

Write & Attach a Least-Privilege JSON Policy

🎯 Goal

Create a custom policy that lets the Developers group read/write only to a specific S3 bucket prefix — nothing else.

📝 Create the Policy File

Save this as policies/cloudnova-dev-s3-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOnlyDevBucket",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::cloudnova-dev-artifacts",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["projects/*"]
        }
      }
    },
    {
      "Sid": "ReadWriteDevPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::cloudnova-dev-artifacts/projects/*"
    }
  ]
}

💻 CLI Commands

# Create the policy in IAM
aws iam create-policy \
  --policy-name CloudNovaDevS3Access \
  --policy-document file://policies/cloudnova-dev-s3-policy.json \
  --description "Least-privilege S3 access for CloudNova developers"

# Capture the policy ARN (save it for later)
POLICY_ARN=$(aws iam list-policies \
  --query "Policies[?PolicyName=='CloudNovaDevS3Access'].Arn" \
  --output text)
echo $POLICY_ARN

# Attach the policy to the Developers group
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn $POLICY_ARN

# Verify attachment
aws iam list-attached-group-policies --group-name Developers

✅ Expected Output

{
    "AttachedPolicies": [
        {
            "PolicyName": "CloudNovaDevS3Access",
            "PolicyArn": "arn:aws:iam::123456789012:policy/CloudNovaDevS3Access"
        }
    ]
}

💡 Tip: Notice the policy grants ListBucket only when the prefix is projects/*. This is the essence of least privilege — scoping both action and resource.

💡 Why It Matters

Broad policies like s3:* on * are a common cause of data breaches. Scoped policies reduce blast radius if a credential is compromised.

Create IAM Users & Add Them to the Group

🎯 Goal

Create alex.dev and priya.dev, and add them to the Developers group.

💻 CLI Commands

# Create the two developers
aws iam create-user --user-name alex.dev \
  --tags Key=Team,Value=Developers Key=Project,Value=CloudNova

aws iam create-user --user-name priya.dev \
  --tags Key=Team,Value=Developers Key=Project,Value=CloudNova

# Add both to the Developers group
aws iam add-user-to-group \
  --group-name Developers \
  --user-name alex.dev

aws iam add-user-to-group \
  --group-name Developers \
  --user-name priya.dev

# Verify group membership
aws iam get-group --group-name Developers

✅ Expected Output

{
    "Users": [
        { "UserName": "alex.dev",  "Arn": "arn:aws:iam::123456789012:user/alex.dev" },
        { "UserName": "priya.dev", "Arn": "arn:aws:iam::123456789012:user/priya.dev" }
    ],
    "Group": {
        "GroupName": "Developers",
        "Arn": "arn:aws:iam::123456789012:group/Developers"
    }
}

💡 Why It Matters

Tags make it easy to filter, audit, and automate. Group membership ensures both users inherit the exact same permissions — no drift.

Enable MFA for a User (Console)

🎯 Goal

Add a virtual MFA device to alex.dev so login requires both password and a TOTP code.

🖥️ Console Steps

Sign in to AWS Console as admin
Go to IAM → Users → alex.dev → Security credentials
Under Multi-factor authentication (MFA), click Assign MFA device
Name it alex-dev-phone, choose Authenticator app
Scan the QR code with Google Authenticator / Authy / 1Password
Enter two consecutive 6-digit codes from the app
Click Add MFA

💻 CLI Verification

# List MFA devices attached to alex.dev
aws iam list-mfa-devices --user-name alex.dev

✅ Expected Output

{
    "MFADevices": [
        {
            "UserName": "alex.dev",
            "SerialNumber": "arn:aws:iam::123456789012:mfa/alex-dev-phone",
            "EnableDate": "2025-01-15T10:30:00+00:00"
        }
    ]
}

⚠️ Warning: Save backup codes or set up a secondary MFA device. If the phone is lost, account recovery requires contacting AWS Support or another admin with permissions to deactivate MFA.

💡 Why It Matters

MFA blocks the vast majority of account takeover attempts, even when passwords are leaked or reused. It is one of the highest-ROI security controls you can enable.

Create an IAM Role for EC2 & Instance Profile

🎯 Goal

Create a role that EC2 instances can assume to read from the CloudNova S3 bucket — no hard-coded access keys required.

📝 Trust Policy File

Save as policies/ec2-trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

💻 CLI Commands

# 1. Create the role
aws iam create-role \
  --role-name CloudNovaEC2S3ReadRole \
  --assume-role-policy-document file://policies/ec2-trust-policy.json \
  --description "Allows EC2 to read CloudNova S3 artifacts"

# 2. Attach a read-only S3 managed policy (scoped, but we'll tighten later)
aws iam attach-role-policy \
  --role-name CloudNovaEC2S3ReadRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# 3. Create the instance profile (container for the role)
aws iam create-instance-profile \
  --instance-profile-name CloudNovaEC2InstanceProfile

# 4. Add the role to the instance profile
aws iam add-role-to-instance-profile \
  --instance-profile-name CloudNovaEC2InstanceProfile \
  --role-name CloudNovaEC2S3ReadRole

# 5. Verify
aws iam get-instance-profile \
  --instance-profile-name CloudNovaEC2InstanceProfile

✅ Expected Output

{
    "InstanceProfile": {
        "InstanceProfileName": "CloudNovaEC2InstanceProfile",
        "Roles": [
            {
                "RoleName": "CloudNovaEC2S3ReadRole",
                "Arn": "arn:aws:iam::123456789012:role/CloudNovaEC2S3ReadRole"
            }
        ]
    }
}

💡 Tip: An instance profile is the container EC2 actually uses. You can only have one role per instance profile, but a profile can be reused across many instances.

💡 Why It Matters

Roles eliminate the need to store long-term access keys on EC2 instances. Credentials are rotated automatically by AWS, drastically reducing leak risk.

Attach the Role to a Stopped EC2 Instance

🎯 Goal

Demonstrate role attachment using a stopped instance (no compute charges while stopped).

⚠️ Warning: You can only attach or replace an instance profile while the instance is stopped. Attaching to a running instance will fail. Terminate the instance after this task to avoid storage charges (EBS volumes persist).

💻 CLI Commands

# List instances (any state)
aws ec2 describe-instances \
  --query "Reservations[].Instances[].{ID:InstanceId,State:State.Name,Name:Tags[?Key=='Name']|[0].Value}" \
  --output table

# If needed, launch a tiny free-tier instance
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t2.micro \
  --count 1 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cloudnova-lab}]'

# Stop the instance (required before attaching a profile)
aws ec2 stop-instances --instance-ids i-0abcdef1234567890
aws ec2 wait instance-stopped --instance-ids i-0abcdef1234567890

# Attach the instance profile
aws ec2 associate-iam-instance-profile \
  --instance-id i-0abcdef1234567890 \
  --iam-instance-profile Name=CloudNovaEC2InstanceProfile

# Verify attachment
aws ec2 describe-iam-instance-profile-associations \
  --query "IamInstanceProfileAssociations[].{Instance:InstanceId,Arn:IamInstanceProfile.Arn,State:State}"

✅ Expected Output

{
    "IamInstanceProfileAssociations": [
        {
            "InstanceId": "i-0abcdef1234567890",
            "IamInstanceProfile": {
                "Arn": "arn:aws:iam::123456789012:instance-profile/CloudNovaEC2InstanceProfile",
                "Id": "AIPAJY2PE5XUZ4EXAMPLE"
            },
            "State": "associated"
        }
    ]
}

💡 Why It Matters

This is the real-world pattern: applications running on EC2 use temporary role credentials via IMDS, not static keys. No secrets to rotate, no secrets to leak.

Create an S3 Bucket & Test Access Boundaries

🎯 Goal

Create the cloudnova-dev-artifacts bucket and verify the least-privilege policy behaves as intended.

💻 CLI Commands

# Create the bucket (must be globally unique)
aws s3api create-bucket \
  --bucket cloudnova-dev-artifacts \
  --region us-east-1

# Enable default encryption (best practice)
aws s3api put-bucket-encryption \
  --bucket cloudnova-dev-artifacts \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

# Block all public access (critical for a dev bucket)
aws s3api put-public-access-block \
  --bucket cloudnova-dev-artifacts \
  --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# Seed a sample object in the allowed prefix
echo "hello cloudnova" > sample.txt
aws s3 cp sample.txt s3://cloudnova-dev-artifacts/projects/sample.txt

# Verify object exists
aws s3 ls s3://cloudnova-dev-artifacts/projects/

✅ Expected Output

2025-01-15 10:45:12 17 sample.txt

💡 Tip: The developers group can only access projects/*. Try creating an object at the bucket root as alex.dev — it should fail with AccessDenied. That is the policy working as designed.

💡 Why It Matters

Encryption and public-access blocks are baseline hygiene. Verifying both allowed and denied operations proves your least-privilege policy actually works.

Generate & Interpret a Credential Report

🎯 Goal

Audit every IAM user's password age, MFA status, access key rotation, and console access.

💻 CLI Commands

# Request a fresh credential report
aws iam generate-credential-report

# Wait a few seconds, then fetch and decode
aws iam get-credential-report \
  --query "Content" \
  --output text | base64 --decode > credential-report.csv

# View the first few rows
head -n 3 credential-report.csv

# Filter: users without MFA
awk -F, 'NR==1 || $8=="false"' credential-report.csv

📊 Key Columns to Inspect

Column	What It Means	Healthy Value
user	IAM user name	—
password_enabled	Console login enabled	as needed
password_last_used	Last console login	recent if active
mfa_active	MFA enabled	true
access_key_1_active	Long-term key exists	prefer false

💡 Tip: Automate this audit weekly. Any user with mfa_active=false and password_enabled=true is a priority finding.

💡 Why It Matters

You can't secure what you can't see. Credential reports surface stale passwords, unused keys, and missing MFA — all common audit findings.

Simulate Least-Privilege with IAM Policy Simulator

🎯 Goal

Prove that your policy grants exactly the intended permissions and denies everything else — without affecting real users.

💻 CLI Commands

# Should return "allowed"
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/alex.dev \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::cloudnova-dev-artifacts/projects/app.zip

# Should return "implicitDeny"
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/alex.dev \
  --action-names s3:DeleteBucket \
  --resource-arns arn:aws:s3:::cloudnova-dev-artifacts

# Should return "implicitDeny" (outside allowed prefix)
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/alex.dev \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::cloudnova-dev-artifacts/private/secret.txt

✅ Expected Output

{
    "EvaluationResults": [
        {
            "EvalActionName": "s3:PutObject",
            "EvalResourceName": "arn:aws:s3:::cloudnova-dev-artifacts/projects/app.zip",
            "EvalDecision": "allowed"
        }
    ]
}

💡 Why It Matters

The Policy Simulator lets you validate changes safely before deployment. It's the fastest way to catch overly permissive policies without waiting for an incident.

✅

5. Checkpoints / Self-Check Questions

🔎 Checkpoint 1 — Group Membership

Run a command that shows exactly which users belong to the Developers group. What is the ARN of the group?

🔎 Checkpoint 2 — Password Policy

What is the minimum password length, and how many previous passwords cannot be reused?

🔎 Checkpoint 3 — Least Privilege

Which S3 prefix can Developers read/write? What happens if they try to write to /private/?

🔎 Checkpoint 4 — MFA Status

Which user has MFA enabled? What command shows this?

🔎 Checkpoint 5 — Instance Profile

Which role is inside the CloudNovaEC2InstanceProfile? Which instance is it attached to?

🔎 Checkpoint 6 — Credential Report

List all users with mfa_active=false and password_enabled=true. Are any of them a risk?

🚑

6. Troubleshooting Common Errors

❌ AccessDenied when creating policies or users

Your IAM user lacks iam:* permissions. Confirm you're using an admin user with AdministratorAccess, not a restricted one. Run aws sts get-caller-identity to confirm who you are.

❌ InvalidClientTokenId or SignatureDoesNotMatch

Your Access Key ID or Secret Access Key is incorrect, expired, or contains a typo. Re-run aws configure and paste the keys carefully. Also check the system clock — signature mismatches occur when the local time is skewed by more than 5 minutes.

❌ MalformedPolicyDocument

Your JSON has a syntax error — often a trailing comma, missing quote, or wrong bracket. Validate with python -m json.tool policies/cloudnova-dev-s3-policy.json before submitting.

❌ BucketAlreadyExists

S3 bucket names are globally unique. Add a suffix such as your account ID or initials: cloudnova-dev-artifacts-12345. Remember to update your JSON policy ARNs too.

❌ IncorrectState when attaching an instance profile

The EC2 instance is still running. Stop it first with aws ec2 stop-instances and wait for the stopped state using aws ec2 wait instance-stopped. Only then run associate-iam-instance-profile.

❌ Credential report shows "not_supported" for the root user

This is normal — root-level MFA and access key status are reported differently. Focus your audit on non-root IAM users.

❌ MFA codes rejected during setup

Enter two consecutive codes, and make sure your phone's time is set to automatic. TOTP codes rotate every 30 seconds; if the window closes while typing, wait for the next one.

🧹

7. Cleanup Instructions

⚠️ Warning: Run cleanup in the exact order below. IAM will refuse to delete groups or roles that still have policies or users attached. S3 buckets must be empty before deletion.

🗑️ Step 1 — Remove users from the group & delete them

aws iam remove-user-from-group --group-name Developers --user-name alex.dev
aws iam remove-user-from-group --group-name Developers --user-name priya.dev

# Deactivate and delete any MFA devices first (if applicable)
aws iam deactivate-mfa-device \
  --user-name alex.dev \
  --serial-number arn:aws:iam::123456789012:mfa/alex-dev-phone

aws iam delete-login-profile --user-name alex.dev # if console access was enabled
aws iam delete-login-profile --user-name priya.dev # if applicable

aws iam delete-user --user-name alex.dev
aws iam delete-user --user-name priya.dev

🗑️ Step 2 — Detach policy & delete the group

aws iam detach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::123456789012:policy/CloudNovaDevS3Access

aws iam delete-group --group-name Developers

🗑️ Step 3 — Delete the custom policy

aws iam delete-policy \
  --policy-arn arn:aws:iam::123456789012:policy/CloudNovaDevS3Access

🗑️ Step 4 — Remove role from instance profile & clean up EC2

# Disassociate the profile from the instance (if still attached)
aws ec2 disassociate-iam-instance-profile \
  --association-id iip-assoc-0abcdef1234567890

# Terminate the lab EC2 instance
aws ec2 terminate-instances --instance-ids i-0abcdef1234567890

# Remove role from instance profile
aws iam remove-role-from-instance-profile \
  --instance-profile-name CloudNovaEC2InstanceProfile \
  --role-name CloudNovaEC2S3ReadRole

# Delete the instance profile
aws iam delete-instance-profile \
  --instance-profile-name CloudNovaEC2InstanceProfile

🗑️ Step 5 — Detach & delete the role

aws iam detach-role-policy \
  --role-name CloudNovaEC2S3ReadRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

aws iam delete-role --role-name CloudNovaEC2S3ReadRole

🗑️ Step 6 — Empty & delete the S3 bucket

# Delete all objects (including versions)
aws s3 rm s3://cloudnova-dev-artifacts --recursive

# Delete the bucket
aws s3api delete-bucket --bucket cloudnova-dev-artifacts

# Remove the local lab directory
rm -rf ~/cloudnova-lab credential-report.csv sample.txt

💡 Tip: After cleanup, run aws iam list-users, aws iam list-roles, and aws s3 ls to confirm nothing is left behind.

🧠

8. Knowledge Check

7 Questions

Q1. What is the difference between an IAM group and an IAM role?

Q2. Why should you avoid storing long-term access keys on an EC2 instance?

Q3. What is an instance profile and why is it required?

Q4. In the policy you wrote, why is s3:ListBucket applied to the bucket ARN while s3:GetObject is applied to the object ARN?

Q5. What is the difference between an Availability Zone and a Region?

Q6. What information can you extract from a credential report?

Q7. Why does least privilege matter even within a single AWS account?

🔑

Instructor Answer Key

A1. Groups are containers of users that share permissions; you assign policies to the group and users inherit them. Roles are temporary identities assumed by users, services, or applications — they use short-lived credentials via STS and have a trust policy defining who can assume them. Users/groups cannot assume a role to get permissions the way an EC2 instance does.

A2. Long-term keys are static, often committed to code, and never rotate automatically. If leaked, they provide indefinite access. Roles provide temporary credentials rotated by AWS (typically every few hours), shrinking the blast radius of any compromise.

A3. An instance profile is the wrapper that carries a single IAM role to an EC2 instance. EC2 APIs require an instance profile name, not a role name, when associating permissions with an instance. You create the role, then add it to a profile, then attach the profile.

A4. ListBucket is a bucket-level action — it operates on the bucket as a whole, so the ARN is the bucket. GetObject is an object-level action — it operates on individual objects, so the ARN includes /*. Mixing these up is a very common mistake.

A5. A Region is a geographic cluster (e.g., us-east-1) containing multiple isolated Availability Zones. An AZ is one or more discrete data centers within a Region, with independent power, cooling, and networking. AZs within a Region are connected by low-latency links.

A6. Password age, password last used, MFA status per user, access key 1 & 2 active status and last rotated/used, console access, and root account usage. It is the standard source of truth for IAM hygiene audits.

A7. A compromised low-privilege user should not be able to escalate to admin. If alex.dev can only write to projects/*, a leaked credential cannot delete production buckets or tamper with IAM. Least privilege limits lateral movement and blast radius.

📚

9. Further Reading & References

📘 AWS IAM Best Practices

Official guidance on users, groups, roles, MFA, and least privilege.

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

📘 IAM Policy Simulator

Test policies safely before deploying them.

https://policysim.aws.amazon.com/

📘 EC2 IAM Roles for Instances

How instance profiles and temporary credentials work.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html

📘 Credential Reports

Generate, download, and interpret account credential reports.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html

📘 AWS Global Infrastructure

Regions, AZs, edge locations, and Local Zones.

https://aws.amazon.com/about-aws/global-infrastructure/

📘 Well-Architected — Security Pillar

Design principles for identity, detection, and least privilege.

https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/