Lab: make your sandbox account safe to learn in

Step 1: protect the root user

The root user is the email address you signed up with. It can do anything, including closing the account, and no policy in the account can restrict it.

1. Sign in to the console as the root user.
2. Open the account menu (top right) and choose Security credentials.
3. Under Multi-factor authentication (MFA), choose Assign MFA device. A passkey or security key is strongest; an authenticator app is fine. Since June 2025 AWS requires MFA for root users in every account type, so you may already have registered one at first sign-in.
4. On the same page, check Access keys. If any exist for the root user, delete them.
5. Sign out. From now on use the root user only for the few tasks that require it, such as closing the account.

Step 2: an everyday identity with IAM Identity Center

IAM Identity Center gives you single sign-on to the console and temporary credentials for the CLI.

1. In the console, open IAM Identity Center and choose Enable. Choose the option that enables it with AWS Organizations (an organization instance). If the account is not yet in an organization, AWS creates one with this account as the management account. That is fine for a sandbox. An account instance cannot give access to AWS accounts, so it will not work for this course.
2. Under Users, add a user for yourself and accept the email invitation. Set up MFA for this user when prompted.
3. Under Permission sets, create one from the predefined AdministratorAccess policy. In a sandbox you need broad rights to build things; in real accounts you would scope this down.
4. Under AWS accounts, select this account, choose Assign users or groups, and assign your user with that permission set.
5. Copy the AWS access portal URL from the Identity Center dashboard.

Now connect the CLI:

aws configure sso
# SSO session name: sandbox
# SSO start URL: <your AWS access portal URL>
# SSO region: <the Region where you enabled Identity Center>
# SSO registration scopes: sso:account:access  (the default)
# Then pick the account and the AdministratorAccess role,
# default client Region: us-east-1, output format: json,
# and profile name: sandbox

Sign in and check who you are:

aws sso login --profile sandbox
export AWS_PROFILE=sandbox
aws sts get-caller-identity

The Arn ends in assumed-role/AWSReservedSSO_AdministratorAccess_.../you. That is a role session, not an IAM user, and its credentials expire. When they do, run aws sso login --profile sandbox again.

Fallback: if you cannot use Identity Center, create an IAM user with console access and MFA, give it access keys, and run aws configure --profile sandbox. Delete those keys when the course ends.

Step 3: a budget alert

Set the variables the rest of the lab uses:

export AWS_PROFILE=sandbox
export AWS_REGION=${AWS_REGION:-us-east-1}
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
ALERT_EMAIL="you@example.com"   # your address

Write the budget. Pick a monthly limit you are comfortable with; 10 here is only an example:

cat > budget.json <<'EOF'
{
  "BudgetName": "sandbox-monthly",
  "BudgetLimit": { "Amount": "10", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}
EOF

cat > notifications.json <<EOF
[
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{ "SubscriptionType": "EMAIL", "Address": "${ALERT_EMAIL}" }]
  },
  {
    "Notification": {
      "NotificationType": "FORECASTED",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 100,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{ "SubscriptionType": "EMAIL", "Address": "${ALERT_EMAIL}" }]
  }
]
EOF

aws budgets create-budget \
  --account-id "$ACCOUNT_ID" \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

aws budgets describe-budgets --account-id "$ACCOUNT_ID" \
  --query 'Budgets[].[BudgetName,BudgetLimit.Amount,TimeUnit]' --output table

The first alert fires when actual spend passes 80% of the limit; the second when AWS forecasts the month will end above it. Keep this budget for the whole course.

Step 4: find yourself in CloudTrail

CloudTrail event history records management events for 90 days with no setup. Global services such as IAM and AWS Budgets record their events in us-east-1:

aws cloudtrail lookup-events --region us-east-1 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateBudget \
  --max-results 5 \
  --query 'Events[].[EventTime,Username,EventName]' --output table

New events can take several minutes to appear. You should see your own CreateBudget call, with your Identity Center user as the username. If the table is empty after ten minutes, list the most recent events of any kind:

aws cloudtrail lookup-events --region us-east-1 --max-results 10 \
  --query 'Events[].[EventTime,EventSource,EventName,Username]' --output table

Every API call you make in this course, from the console or the CLI, ends up here. That is what “audit who did what” means in an exam question.

rm -f budget.json notifications.json