The right key.
The smallest door.

1. Four keys that are not interchangeable

Your apartment key does not let you redesign the whole building. Your building manager's badge does not automatically log them into your computer. Cloud infrastructure has different keys too.

The source-IP firewall rule decides which traffic can reach SSH, not who can log in. SSH keys decide OS authentication, not cloud management permission. The sudo access in our disposable Ubuntu labs is intentionally administrative; it is not a production user-role design.

2. Check the active identity before every change

Use Ubuntu/WSL and the cloud login established in the server lesson. These commands read local/session information; they do not grant roles. Their output can reveal account IDs, names and project details—keep it private.

aws sts get-caller-identity
aws configure list

Check Account and Arn, plus the configured profile/region. The caller ARN can represent an assumed role, not a permanent IAM user. A successful identity lookup does not prove permission to create an instance.

az account show --query '{subscription:name,id:id,tenant:tenantId,user:user.name}' --output table

Confirm the intended subscription and tenant. Azure CLI's selected subscription and Terraform's subscription_id variable must agree with your intended lab.

gcloud auth list
gcloud config get-value project

Google CLI and Terraform ADC can be different identities. These commands identify the CLI account, not the ADC account. Review how you established ADC in the server guide; when uncertain, renew ADC interactively with the authorized account. Never print an access token just to “check” it.

AWS identity queryAzure account contextGoogle ADC

3. Confirm the demo server has no unnecessary cloud key

Our server recipes do not need a workload identity. Inspect the code-managed VM using the commands below, replacing each placeholder. Ask an administrator if read permission is denied; do not grant yourself a broader role.

aws ec2 describe-instances --region us-east-1 \
  --instance-ids YOUR-INSTANCE-ID \
  --query 'Reservations[].Instances[].{Id:InstanceId,Profile:IamInstanceProfile.Arn}'

Profile should be absent/null in the original lab. An attached profile is a container for an IAM role; do not assume its absence means the OS cannot reach external services.

az vm show --resource-group contoso-infra-code --name contoso-infra-code \
  --query identity --output json

Expect no managed identity in the original lab. Run this only in the intended subscription.

gcloud compute instances describe contoso-infra-code \
  --project YOUR-PROJECT-ID --zone us-central1-a \
  --format='json(serviceAccounts)'

Expect no attached service account in the original lab. An unexpected identity is an investigation point, not something to detach from a real workload blindly. Check the Terraform recipe, manual changes and actual application requirements first.

AWS instance rolesAzure managed identitiesGoogle VM service accounts

4. Least privilege is action plus scope plus time

• Action: can this identity inspect, upload, restart, delete or grant access? Those are different capabilities.
• Scope: one bucket, one resource group, one project, or the whole account? Prefer the smallest useful boundary.
• Time: prefer short-lived sessions and temporary approved assignments over permanent credentials.
• Effective access: direct assignments are not the entire story. Inheritance, groups, resource policies, conditions and organization restrictions can affect the outcome.

There is no universal copy/paste “least privilege” policy for all three clouds. Creating a resource can involve related network/disk actions, and some operations cannot be scoped to a resource that does not exist yet. Test a deliberately scoped design in a sandbox and review denies with an administrator.

Our beginner deployment roles are broad within a dedicated learning boundary. They are a teaching shortcut, not permission templates for production.

AWS least-privilege guidanceAzure RBAC evaluationGoogle IAM overview

5. Perform a read-only access review

1. Write down your human identity, deployment identity, workload identity and Linux user for one lab.
2. In AWS, inspect the deployment role's policies and any relevant boundaries/organization controls. Do not inspect the entire account if you only have permission for the lab.
3. In Azure, open the lab resource group's Access control (IAM) → Check access. Include inherited assignments when reviewing. Management-plane permissions and data-plane permissions are not interchangeable.
4. In Google Cloud, inspect project IAM and any relevant resource policies. A displayed project policy may not include all permissions inherited from folders/organization or granted through groups.
5. For every broad assignment, record why the lab needs it and what narrower scope could work. Give the proposal to the authorized administrator; this exercise does not make role changes.

6. Keep keys and state out of the website

Keep SSH private keys, ADC files, cloud tokens, Terraform state/plans and real backups outside the public site. A .gitignore prevents routine commits—it does not remove a secret already committed or revoke a leaked key.

If a credential was exposed, revoke/rotate it through the provider's authorized process and assess its use. Do not merely delete the visible file. Keep sanitized learning notes instead of raw logs or identity output.

At the end, log out of temporary cloud sessions and ask the administrator to remove temporary assignments only when they are no longer needed. Do not remove your last recovery/admin path before a replacement is tested.