Courses / Hands-on Cloud for Freshers

Session 1 of 8

A safe first AWS account

Overview

Unit 1 — A Safe First AWS Account

Course: Hands-on Cloud for Freshers

Prerequisites: You can use a web browser, receive email and SMS on your own phone, and install an authenticator app on that phone. You have a payment card you are allowed to use for an identity check. No cloud experience is assumed: this is the first unit, and every term it uses is defined in the notes.

What the reader can do after this unit:

  • Create an AWS account on the Free account plan and state, from the plan’s own rules, the two events that end it and what happens to the account afterwards.
  • Lock down the root user with multi-factor authentication and decide, for a given task, whether it needs the root user or the everyday administrator identity.
  • Set a budget alert and find the credit balance, so that a forgotten resource is noticed before it quietly uses up the credits.

Core question this unit answers: Before you build anything in a brand-new AWS account, what do you set up so that a mistake cannot cost you the account, and how will you find out if something starts using your credits?

Connections:

  • Builds on: nothing earlier in this course. It assumes only that you can sign up for an online service and keep a password safe.
  • Leads into: Unit 2, which uses the everyday administrator identity you create here to sign in to the AWS command line with short-lived credentials, and then teaches how permissions decide what any identity is allowed to do.

Your answers are scored

This unit is assessed. The quiz is marked against a key held separately from your materials. Questions 1–8 are multiple choice and are marked by comparing your letter with the key. Questions 9–10 ask you to write a short answer in an exact format, and each one is marked by a rule printed with the question: the accepted forms are stated, so you can check your own answer completely before you submit it.

  • Nothing is judged by reading it for style. An answer either matches the printed rule or it does not.
  • The project is not scored by the quiz. It is how you build the account you will use for the rest of the course, and each task states the output you should be holding at the end of it.

Notes

Hands-on Cloud for Freshers — Unit 1: A Safe First AWS Account

Before you start

Have these ready before you open the sign-up page:

  • An email address you will keep for years and that only you can read. It becomes the sign-in name of the most powerful identity in your account.
  • Your own phone, able to receive an SMS or a call, with an authenticator app installed (any app that produces six-digit codes that change every 30 seconds).
  • A payment card. AWS asks for one during sign-up to verify you; how that check works depends on your country, and the project quotes what AWS says for addresses in India.
  • A password manager, or at least a private place to store two strong passwords.

Every statement in these notes about how AWS behaves is taken from the AWS documentation pages listed under Sources at the end, retrieved on 2026-10-02. AWS changes its sign-up and Free Tier rules from time to time; when a screen you see differs from the description here, the current documentation wins.

Summary

A new AWS account is not dangerous because the cloud is complicated; it is dangerous because the first identity you get can do anything, and because resources keep running whether or not you are looking at them. This unit sets up three guards before you build anything: the all-powerful root user is locked behind a second factor and put away, an everyday administrator identity is created for normal work, and a budget alert watches spending so that a forgotten resource announces itself. You will also learn exactly how the Free account plan works today, because the rules that decide when it ends are different from the older free tier many tutorials still describe. Each later unit builds something real and then deletes it; this unit builds the safety net those builds depend on.

Key concepts

Term Definition
AWS account A container for everything you create in AWS — servers, storage, identities — and the unit AWS bills. One sign-up creates one account
Root user The identity created at sign-up from your email address and password. It has complete access to every service and resource in the account. The permission policies you write in a standalone account cannot restrict it
IAM AWS Identity and Access Management: the service that creates identities (users, groups, roles) and the policies that say what they may do
IAM user An identity inside your account for one person or program, with its own password and, optionally, access keys. It can do only what its policies allow
User group A collection of IAM users. A policy attached to the group applies to every user in it
MFA Multi-factor authentication: a second proof of identity, such as a six-digit code from an authenticator app, required in addition to the password
Free account plan The sign-up option that cannot incur charges. It gives credits, limits which services you can use, and ends after six months or when the credits are used up, whichever comes first
Paid account plan The sign-up option with access to all services. The same credits apply first; usage beyond them is charged at normal rates
Credits A balance in US dollars that AWS applies to your usage. New customers receive USD 100 at sign-up and can earn up to USD 100 more by completing activities
Always Free Over 30 services with a monthly free usage allowance that applies on both plans
AWS Budgets A cost-management tool that emails you when cost or usage crosses, or is forecast to cross, a threshold you set
Region A geographic area containing AWS data centres, such as ap-south-1, Asia Pacific (Mumbai). Most resources live in exactly one Region
Tag A key–value label you attach to a resource, such as project = hands-on-cloud, so that you can find it again

Explanations

The failure, before the explanation

Picture two learners who open AWS accounts on the same day.

The first follows a video, launches a server, gets a web page to show, closes the laptop and forgets about it. The server keeps running. Nothing on the screen says so, because the learner never opens that page of the console again. The cost is taken from the credit balance, day after day, until the credits are gone — and on the Free account plan, AWS documents that the account then closes automatically, and the learner loses access to everything in it.

The second learner types the root user password into a shared computer at a cyber café. A week later someone else signs in as root. Root can change the account email address, change the password and close the account; no permission the learner wrote can stop it, because in a standalone account AWS evaluates every request from the root user as allowed (“all requests are implicitly denied with the exception of the AWS account root user, which has full access”).

Neither learner made a technical mistake. Both skipped the setup that this unit is about: a lock on the most powerful identity, and an alarm that rings when money starts moving.

Which plan you are on, and what ends it

Start with a prepaid phone card. You load it once, it cannot run up a bill, and it stops working either when the balance reaches zero or when its validity date passes — whichever comes first. The Free account plan behaves the same way, and seeing it as a card with two expiry conditions is most of what you need to remember about it.

At sign-up you choose between two plans. The differences that matter for this course are in this table, taken from the AWS Billing documentation:

Free account plan Paid account plan
Sign-up credit USD 100, plus up to USD 100 more from activities The same
Services Select services only All services
Charges None while on the plan Charged for usage beyond the credit balance
When credits run out The account closes The account stays open and starts charging

Two phrases from the documentation are worth reading slowly:

“Your free account plan ends after six months or when your credits are fully used — whichever occurs first.”

“After your free account plan expires, your account closes automatically, and you lose access to your resources and data. AWS retains your content for 90 days before permanently deleting your account and all associated resources. To maintain your account access, you can upgrade to a Paid account plan … within 90 days.”

So “free” here does not mean “unlimited”. It means a fixed budget, and a fixed end — the prepaid card again: you cannot be billed past the balance, but when the balance or the validity runs out, the line stops working. A forgotten server does not send you a bill on this plan — it spends your card down faster, and shortens the life of your learning account.

A second way to see it: the Free account plan turns every mistake into lost time rather than lost money. That is a good trade for a learner, which is why this course uses it, but only if you can see the balance moving.

Some things silently move you to the Paid plan. The documentation lists actions that upgrade a Free plan account automatically, including joining AWS Organizations. Keep that in mind: it is the reason the next section creates an IAM user rather than following a recommendation that would create an organization.

Older tutorials describe a different free tier — a set of services free for twelve months from sign-up. That is not how accounts created under the current plans work. If a guide tells you a service “is free for the first year”, check the current Free Tier page before relying on it.

The root user: lock it, then put it away

Think of the master key to a building, the kind that also opens the room where the locks are changed. You do not carry it around to open your own office door. You put it in a safe, and you take it out only for the few jobs that need it.

The root user is that master key: the email address and password you used to sign up. AWS describes it as having “complete access to all AWS resources in your account”, and its documentation repeats one instruction in several places: do not use it for everyday tasks. A second way to see it is the second learner in the failure above — whoever holds the root password owns the account, and nothing you write later can take that back.

What “lock it” means, in AWS’s own list of root user best practices:

  • A strong, unique password. AWS requires 8–128 characters with at least three of: uppercase, lowercase, numbers and symbols, and it must not equal your account name or email address.
  • MFA on the root user. AWS documents that MFA is required for root users, and that you must register a device within 35 days of your first sign-in attempt if it is not already enabled. You can register up to eight MFA devices on the root user; registering more than one means losing your phone does not lock you out.
  • No access keys for the root user. Access keys are long-term credentials for the command line. AWS “strongly recommends” not creating them for root, because root has full access to everything, including billing.

What “put it away” means: you sign in as root only for the tasks that require it. AWS publishes the list. The ones a learner is likely to meet are:

Needs the root user Does not need the root user
Changing the root user’s email address or password Changing the account name or contact information
Closing the account Creating IAM users, groups and policies
Turning on IAM access to the Billing and Cost Management console Creating and deleting resources such as storage buckets or servers
Restoring permissions if the only IAM administrator has locked themselves out Creating a budget, once billing access for IAM is turned on

That last row of the left column is the reason you keep the root user working, with its MFA device, rather than throwing the password away: it is how you recover from a mistake in IAM.

The everyday administrator: why an IAM user here

A bank manager does not open the vault to hand a customer a deposit slip; they use their own staff card, which opens the doors their job needs and leaves a record of who opened them. Your everyday work in AWS needs the same thing: a named identity, separate from the master key, that you can lock, audit and, if it is ever stolen, delete without losing the account.

So for normal work you need a second identity that can do almost everything but is not root. AWS’s general recommendation for people is IAM Identity Center, which gives temporary credentials through a sign-in portal. On a Free account plan, there is a catch, and it is stated in the IAM Identity Center documentation:

  • The recommended organization instance of IAM Identity Center, enabled from a standalone account, “creates a new organization with your account as the management account”. And: “If you use a free tier account, creating an AWS organization automatically upgrades your account to a paid plan with pay-as-you-go pricing. Your free tier credits expire immediately.”
  • The other kind, an account instance, does not help either: “Account instances do not support permission sets and therefore do not support access to AWS accounts.”

So for a single learning account on the Free plan, this course uses the option AWS documents for a standalone account: an IAM user with a console password and MFA, placed in a user group that has the AWS managed policy AdministratorAccess. That policy is short enough to read in full:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "*", "Resource": "*" }
  ]
}

Every action, on every resource. That is why the user gets MFA too, and why it never gets access keys in this course — Unit 2 signs it in to the command line with short-lived credentials instead.

An IAM user signs in at an address that contains your 12-digit account ID:

https://111122223333.signin.aws.amazon.com/console

(111122223333 is the placeholder AWS uses in its own examples; yours is shown in the console.) You can also go to https://console.aws.amazon.com/ and type the account ID or alias yourself. Bookmark the full address by typing it in, because AWS notes that redirects can hide it if you bookmark the page you land on.

If your sign-up looked different. AWS is releasing a second sign-up path, Sign up for AWS (new), to a limited number of customers. It uses a Google, GitHub, Apple or Amazon login, organises resources into “projects”, creates no root user, and does not allow IAM users with console access. This course follows the classic path, which AWS now calls Sign up for AWS (advanced). If you were put on the new path, the root-user and IAM-user steps below do not apply to you; your account starts inside a managed organization instead, and the cost and Region guards still do.

Two ways to hear about spending

Picture a water tank on a roof with two signals: a float that rings a bell when the tank is nearly empty, and a meter you read yourself whenever you like. The first tells you without being asked; the second only tells you if you look. AWS gives you one of each for your credits, and you want both.

There are two alarms, and they do different jobs.

Automatic Free Tier usage alerts. AWS emails the root user’s address when your usage of a service passes 85 percent of its Free Tier limit. You do not have to set these up for an individual account; they are on by default. You can change the address they go to under Billing preferences → Alert preferences.

A budget you create. AWS Budgets has a one-page Use a template (simplified) workflow in the Billing and Cost Management console. Two templates matter here:

  • Zero spend budget — “notifies you after your spending exceeds AWS Free Tier limits”.
  • Monthly cost budget — notifies you if you exceed, or are forecast to exceed, an amount you set.

Why bother on a plan that “cannot charge you”? Because the Free Tier documentation says that when you go beyond a service’s free monthly allowance, “your AWS Free Tier credits automatically apply to cover the eligible cost”. Spending above the free allowance is exactly the moment your credits start to drain, and a zero spend budget is the alarm for that moment.

Then know where to look: AWS documents that you can see the Free plan’s credit balance, days remaining and expiry date on the AWS Management Console home and in the Billing and Cost Management console, and that it sends periodic emails about the credit balance and the approaching end of the plan.

A useful habit, borrowed from people who run real systems: an alarm is only as good as the inbox it reaches. Use the email address you actually read.

One Region, one tag

Imagine you park a scooter in one of two identical car parks, then search for it in the other. It is not missing — you are looking in the wrong place — but until you realise that, it looks gone, and the parking meter keeps running. AWS Regions behave like those car parks.

Most AWS resources live in one Region. The console has a Region selector in the navigation bar, and AWS warns that if you create something and then cannot see it, “the console might be displaying resources from a different Region”. A server created in Mumbai does not appear on the screen while the selector says Singapore — but it still runs, and it still uses credits.

This course’s examples use ap-south-1, Asia Pacific (Mumbai), which is enabled by default in every standard account. You may pick a Region nearer to you instead; AWS suggests choosing one close to your users and offering the services you need. Whichever you pick, use only that one for the whole course. That single rule makes the teardown at the end of every project something you can actually check. IAM itself has no Region: users, groups and policies are global to the account.

The second rule is a tag. Every resource you create in this course that accepts tags gets:

project = hands-on-cloud

A tag works like the name sticker on a lunch box in a shared fridge: when it is time to clear the fridge, you take out every box with your name on it and nothing else. Later units use this tag to find everything that must be deleted. Not everything can be tagged — IAM user groups, for example, cannot — so the teardown checklists also name what to look for by name.

Flashcards

Say the answer aloud before revealing it. Speaking it is what exposes the gaps that reading past a written answer hides.

What two events end the Free account plan?

Using up the credits, or reaching the end of the plan’s fixed period from sign-up, whichever happens first.

What happens to a Free plan account when the plan ends?

It closes automatically and you lose access. AWS keeps the content for 90 days and then deletes the account; upgrading to the Paid plan within those 90 days keeps it.

Why does this course not use IAM Identity Center for the everyday administrator?

Enabling the recommended organization instance from a standalone account creates an AWS organization, and creating an organization upgrades a Free plan account to Paid and expires its credits immediately. The account instance cannot grant access to AWS accounts at all.

Name three protections AWS recommends for the root user.

A strong unique password, MFA (ideally more than one device), and no access keys. Then use it only for root-only tasks.

Give two tasks that need the root user and one that does not.

Changing the root email or password, closing the account, turning on IAM access to billing and restoring a locked-out administrator need root. Creating IAM users or changing the account’s contact information does not.

Why can't a permission policy protect you from a stolen root password?

In a standalone account the root user has full access and the policies you write do not restrict it. Only the second factor and keeping the password secret stand in the way.

What does the AdministratorAccess policy allow?

"Action": "*" on "Resource": "*": every action on every resource. That is why the user holding it also needs MFA.

Where does an IAM user sign in?

At https://<account-id>.signin.aws.amazon.com/console, or at https://console.aws.amazon.com/ by entering the account ID or alias by hand.

On the Free plan, what does a zero spend budget warn you about?

That usage has gone past a free allowance, which is the point where credits start being applied — and so start draining.

Why choose one Region and stay in it?

Most resources exist in one Region and the console shows one Region at a time, so a resource in another Region is invisible on screen while still running. One Region makes teardown checkable.

What is the course's tag, and why does every resource get it?

project = hands-on-cloud. It lets you find every resource that has to be deleted, instead of trusting memory.

What is "Sign up for AWS (new)", and how does it differ?

A newer sign-up path being released to some customers: you sign in with an existing login, there is no root user, IAM users cannot have console access, and resources are grouped into projects inside a managed organization.

Model answer

The question: “You have just created an AWS account to learn on. Before you launch anything, what do you set up, and why?”

A good answer covers five beats, in this order: plan, root, everyday identity, alarm, scope. Missing a beat is a failure, not a stylistic gap: each beat closes a different way of losing the account. Spoken, it sounds like this:

“First, the plan. My account is on the Free account plan, so it cannot charge me, but it ends when the credits are used up or when its fixed period runs out, whichever comes first — and then the account closes, so every resource I forget is shortening its life. Second, the root user. I give it a long unique password and MFA, I create no access keys for it, and I put it away, because in a standalone account no policy I write can restrict it; I sign in as root only for root-only jobs such as closing the account or recovering a locked-out administrator. Third, my everyday identity. I create an IAM user with its own password and MFA, in a group that has AdministratorAccess, and I do all daily work as that user. I do not enable IAM Identity Center here, because on this plan it would create an organization and move the account to the Paid plan. Fourth, an alarm. I create a zero spend budget so I hear the moment usage passes a free allowance, and I know where the console shows my credit balance and the plan’s end date. Fifth, scope. I pick one Region and tag everything project = hands-on-cloud, so that after every project I can prove nothing is left running.”

Beat five is the one most answers drop, because nothing has been built yet. It is the beat that makes every later teardown possible.

Why this matters

  • A student’s demo that disappears before the interview. A project deployed to a Free plan account that ran out of credits is gone, along with its data, and the link on the CV returns an error. Knowing what ends the plan lets you plan the demo’s life.
  • A leaked root password. A password typed on a shared computer or reused from another site can end up in someone else’s hands. With MFA on root, a leaked password alone is not enough to sign in.
  • A server found later in another Region. If you create something while the console points at one Region and later look from another, the resource is not on screen but keeps running. One Region and one tag turn finding it into a check you can run.
  • Your first shared account at work. When you are given access to someone else’s AWS account, the same questions come back: which identity am I using, what can it do, and where is spending watched. Answering them in your own account first means you can answer them there.

After this unit

The project for this unit is Your Safe Learning Account (project.md). You will create the account, lock down the root user, create the everyday administrator user with MFA, set a budget alert, and then practise creating and deleting a throw-away IAM user so that you finish holding a clean account with nothing in it except its guards.

Unit 2 starts from that administrator user: it installs the AWS command-line tool, signs it in with short-lived credentials using the administrator’s console password, and then teaches how a permission policy decides whether any request is allowed.

Sources

All retrieved 2026-10-02.

Project

Hands-on Project — Your Safe Learning Account

Objective

Create the AWS account you will use for the rest of this course, put its three guards in place — a locked-down root user, an everyday administrator with MFA, and a budget alert — and then practise the build-and-delete cycle on something small, so that you finish holding a clean account that contains nothing except its guards.

What this project needs: a browser, your own phone with an authenticator app (any app that shows a six-digit code that keeps changing), an email address that only you can read, and a payment card for AWS’s identity check. No command-line tools are needed. The project creates no servers, storage or databases. IAM is documented as a feature of your account “offered at no additional charge” (IAM user guide, What is IAM? — see Sources).

One sign-up path for everyone. AWS has two ways to sign up. Sign up for AWS (new) is being released to a limited number of customers; it creates no root user and does not allow IAM users with console access, so it cannot be used for this project. Sign up for AWS (advanced) creates a root user and lets you create IAM users, and AWS’s procedure for it starts from a direct link, given in Task 1. Every learner follows that link, so every learner does every task below.

Your evidence file. Keep one plain-text file, unit1-evidence.txt. Each task tells you which lines to add to it. Every line has the form key: value, one per line, with the key in lower case exactly as printed, and the rule for the shape of each value is printed next to it, so you can check your own file before you hand it in. Write what the screen shows, not what you expected it to show. Never put a password, an MFA code or an access key in this file.

How each task is checked. Every task ends with a Check — what you should see if the task worked — and a If the check fails list of the usual causes and what to do. Do not start the next task until the current task’s check passes.

Two conventions apply from here on:

  • Choose one Region and stay in it. The examples use ap-south-1, Asia Pacific (Mumbai). Write your choice down now: My Region: ____________.
  • Every resource that accepts tags gets the tag key project with the value hands-on-cloud.

Task 1 — Create the account and lock the root user

Scope: one account, one root MFA device minimum, billing access turned on. Stop there; do not open any other service yet.

  1. Open the Sign up for AWS (advanced) page directly: https://signin.aws.amazon.com/signup?request_type=register. The first page asks for a root user email address and an AWS account name.
  2. Enter the root user email address and an account name, choose Verify email address, enter the code from your inbox, and choose Verify. A personal naming pattern AWS suggests is first name-last name-purpose, for example asha-rao-learning.
  3. Set a strong root password: 8–128 characters, at least three of uppercase, lowercase, numbers and symbols, and not the same as your account name or email. Store it in your password manager, then choose Continue.
  4. When asked to choose your account plan, choose the Free plan.
  5. Enter your contact information and accept the customer agreement, then your billing information. If your contact and billing address is in India, AWS documents that the agreement is with Amazon Web Services India Private Limited, that you must give your card’s CVV, that you might also have to enter a one-time password depending on your bank, and that a charge of 2 INR is made and refunded as part of verification.
  6. Complete the phone check (Send SMS, then enter the code and choose Continue), choose one of the available Support plans, and choose Complete sign up.
  7. Wait for the activation email. AWS says activation usually takes a few minutes but can sometimes take much longer.
  8. Sign in to https://console.aws.amazon.com/ as Root user. Open your account name at the top right and choose Security credentials. Under Account details, the 12-digit number next to AWS account ID is your account ID; copy it.
  9. On the same page, under Multi-Factor Authentication (MFA), choose Assign MFA device. Type a device name, choose Authenticator app, then Next. In your app, add a new account and scan the QR code (Show QR code), or type the key shown by Show secret key. Type the code the app shows into MFA code 1, wait for the next code and type it into MFA code 2, and choose Add MFA straight away. If you have a second device, register it too — AWS allows up to eight.
  10. Still as root: open your account name → Account, find IAM User and Role Access to Billing Information, choose Edit, tick Activate IAM Access, and choose Update. Without this, the administrator you create next cannot open the billing pages, even with full permissions.
  11. Back on Security credentials, look at the Access keys section. Do not create one.

Check: sign out, then sign in again as Root user. After the password, you are asked for an MFA code, and the code from your app lets you in. Security credentials lists at least one MFA device and no access keys, and the Account page shows IAM access to billing as activated.

If the check fails:

  • The first page of step 1 asks you to choose a Google, GitHub, Apple or Amazon login instead of a root user email address — you are on the new sign-up path. Close the tab and open the direct link in step 1 again, typing it by hand.
  • Sign-up does not accept your email address — use a different address that only you can read and will keep for years.
  • No activation email — check your spam folder, and wait; AWS says activation can sometimes take much longer than a few minutes.
  • The MFA code is rejected at sign-in — the device is out of sync, which happens when codes are typed in too slowly while adding the device. On the MFA sign-in page choose Having problems with your authentication device? Click here (it may read Troubleshoot your authentication device), type two consecutive codes into MFA code 1 and MFA code 2 in the Re-Sync With Our Servers section, and choose Re-sync authentication device.
  • AWS asks you to register an MFA device as soon as you sign in as root — AWS enforces root MFA and may prompt for it at sign-in. Register it there, following the app part of step 9, then open Security credentials to confirm the device is listed and carry on from step 10.
  • An access key is listed — you created one by mistake. Delete it from the same page before going on.

Output: add these lines to unit1-evidence.txt:

Line Rule for the value
account-id: <value> exactly 12 digits, no spaces or hyphens, copied from step 8
region: <value> the code of the Region you wrote down: lower-case words joined by hyphens, ending in a hyphen and a single digit, as in ap-south-1
root-mfa-devices: <value> a whole number written in digits: how many MFA devices root’s Security credentials page lists
root-access-keys: <value> a whole number written in digits: how many access keys the same page lists
iam-billing-access: <value> activated or not activated, as the Account page shows the setting

Task 2 — Create the everyday administrator, then stop using root

Scope: one group, one user, one MFA device. No access keys.

  1. As root, open the IAM console (https://console.aws.amazon.com/iam/). Choose Users → Create user.
  2. User name: hoc-admin. Tick Provide user access to the AWS Management Console and choose I want to create an IAM user. Choose a Custom password and store it in your password manager. Clear User must create a new password at next sign-in — you are this user, and you have just chosen the password.
  3. On Set permissions, choose Add user to group → Create group. Group name hoc-admins; under permission policies, select AdministratorAccess; choose Create user group, then select the new group.
  4. If the wizard offers a tags step, add the tag key project with the value hands-on-cloud. (User groups cannot be tagged; that is expected.)
  5. Review and choose Create user.
  6. Your IAM sign-in address is https://<your-account-id>.signin.aws.amazon.com/console, with your 12 digits from Task 1 in place of <your-account-id>. Type it into a new browser bookmark by hand — AWS notes that redirects can hide the address if you bookmark the page you land on.
  7. Sign out of root. Open your bookmark and sign in as hoc-admin with its password. Then open IAM → Users → hoc-admin → Security credentials, and under Multi-factor authentication (MFA) choose Assign MFA device. Add it exactly as you did for root in Task 1 step 9, as a new account in your app (so the app now holds two entries).
  8. Sign out and sign back in at your bookmark as hoc-admin.

From this point on, sign in as root only for a job that needs it: changing the root email address or password, closing the account, changing the billing-access setting, or restoring access if hoc-admin ever loses its own permissions.

Check: step 8’s sign-in asks for an MFA code after the password, and the hoc-admin code from your app lets you in. IAM → Users lists hoc-admin, and IAM → User groups → hoc-admins lists hoc-admin as a member.

If the check fails:

  • The bookmark opens the root sign-in page, or a different user name is filled in — the sign-in page remembers the last account in a browser cookie. Choose Sign in to a different account near the bottom of the page, or type your account ID at https://console.aws.amazon.com/.
  • Step 8 did not ask for an MFA code — step 7 did not finish. Sign in as hoc-admin, open its Security credentials tab, and assign the device again.
  • The MFA code is rejected — the device is out of sync. Sign in as root, open IAM → Users → hoc-admin → Security credentials, select the device, choose Resync, type two consecutive codes into MFA code 1 and MFA code 2 straight away, and choose Resync.
  • hoc-admin is not in hoc-admins — as root, open IAM → User groups → hoc-admins and add hoc-admin to the group.

Output: add these lines to unit1-evidence.txt:

Line Rule for the value
sign-in-url: <value> https:// + the same 12 digits as account-id + .signin.aws.amazon.com/console (a final / is allowed)
admin-user: <value> the user name exactly as IAM → Users lists it
admin-group: <value> the group name exactly as IAM → User groups lists it
admin-mfa-prompted: <value> yes or no: whether step 8’s sign-in asked you for an MFA code

Task 3 — Set the alarm and find the gauge

Scope: one budget from a template, plus one look at the credit balance. Signed in as hoc-admin.

  1. In the navigation bar, open the Region selector and choose the Region you wrote down.
  2. Open the Billing and Cost Management console (https://console.aws.amazon.com/cost-management/) and, in the navigation pane, choose Budgets → Create budget.
  3. Under Budget setup, choose Use a template (simplified). Under Templates, choose Zero spend budget. Enter the email address you actually read as the recipient, and choose Create budget.
  4. Open Console Home (https://console.aws.amazon.com/) and find the Free plan information: the credit balance, the days remaining and the plan’s end date. Write them down for yourself.
  5. Open the Billing console (https://console.aws.amazon.com/billing/). Under Preferences in the navigation pane, choose Billing preferences. Under Alert preferences, check which email address receives the automatic Free Tier usage alerts. If it is not one you read, choose Edit, enter one you read, and choose Update.

If the console offers an Explore AWS activity for setting up a cost budget, AWS documents that completing such activities can earn additional credits. It is optional.

Check: the Budgets page lists a budget made from the zero spend template, Console Home shows a Free plan end date, and Alert preferences shows an email address you read.

If the check fails:

  • The Budgets or Billing pages say you do not have access — IAM access to billing was not activated. Sign out, sign in as root, do Task 1 step 10, sign out again, and return to this task as hoc-admin.
  • The budget is not listed — step 3’s Create budget was not chosen. Repeat steps 2–3.
  • Console Home shows no Free plan information — check that you chose the Free plan in Task 1 step 4; the Billing console’s credits information is where a Paid plan account’s balance appears. Record what you see; do not create a second account.

Output: add these lines to unit1-evidence.txt:

Line Rule for the value
budget-template: <value> the template you chose, written exactly as one of: zero spend, monthly cost, daily savings plans coverage, daily reservation utilization
budgets-listed: <value> a whole number written in digits: how many budgets the Budgets page lists after step 3
plan-end-date-shown: <value> yes or no: whether Console Home showed a Free plan end date in step 4
alert-email-checked: <value> yes or no: whether you opened Alert preferences in step 5

Task 4 — Build something, then delete it (the habit)

Scope: one throw-away IAM user, created and deleted. It uses no credits; the point is to practise the cycle every later unit ends with.

  1. As hoc-admin, open IAM → Users → Create user. User name hoc-practice; tick Provide user access to the AWS Management Console, choose I want to create an IAM user, choose a Custom password, and clear User must create a new password at next sign-in. On Set permissions, add it to no group and attach no policies. If the wizard offers a tags step, add the tag key project with the value hands-on-cloud. Choose Create user.
  2. Open a private (incognito) browser window, so that the sign-in page does not reuse hoc-admin’s session. Go to your sign-in address and sign in as hoc-practice. Open the IAM console and choose Users. Note whether the page shows the list of users, and copy any message it shows instead into a separate file, unit1-message.txt.
  3. Close the private window. As hoc-admin, delete hoc-practice: IAM → Users, select the checkbox next to it, choose Delete, type the user name in the confirmation box, and choose Delete. The console shows a notification that the user was deleted.

Check — the teardown checklist. Tick each line only after you have looked, not from memory:

  • Searching IAM → Users for hoc-practice finds no user, and hoc-admin is listed.
  • IAM → User groups lists hoc-admins, and its members include hoc-admin.
  • The Budgets page lists your zero spend budget.
  • You are signed in as hoc-admin, not root, and on Console Home the Region selector shows the Region you wrote down.

If the check fails:

  • Step 2’s sign-in asks hoc-practice to set a new password — the checkbox in step 1 was left ticked, and AWS documents that this option gives the user the permissions it needs to change its password. Close the window, delete hoc-practice as in step 3, and create it again with the box cleared.
  • Step 2 lands you in as hoc-admin — the window was not private. Close it, open a private window, and choose Sign in to a different account if the page fills in hoc-admin.
  • hoc-practice is still listed after step 3 — the confirmation box did not match the user name. Repeat step 3, typing the name exactly.
  • The Region selector shows another Region — open the selector and choose your Region again.

Output: add these lines to unit1-evidence.txt, and keep unit1-message.txt for Unit 2:

Line Rule for the value
practice-user-saw-user-list: <value> yes or no: whether hoc-practice saw the list of users in step 2
practice-user-exists: <value> yes or no: whether a search for hoc-practice in IAM → Users finds it after step 3
admin-in-group: <value> yes or no: whether IAM → User groups → hoc-admins lists hoc-admin as a member

Before you hand in: unit1-evidence.txt has 16 lines — five from Task 1, four from Task 2, four from Task 3 and three from Task 4 — each key exactly once, each value in the shape its table states.


What this feeds

Unit 2 starts signed in as hoc-admin. It installs the AWS command-line tool and runs aws login, which signs the tool in through the browser with your hoc-admin console sign-in. AWS documents that this works for an IAM user and gives the tool temporary credentials, so no long-term access key is ever created (source: Login for AWS local development using console credentials, listed below). What hoc-practice saw in Task 4 is the first thing Unit 2 explains, so keep unit1-evidence.txt and unit1-message.txt.


Sources

Every AWS behaviour this project relies on comes from these pages, all fetched 2026-10-02:

Quiz

Online marking is not open yet. Work through the questions and check the written ones against the criteria printed with each question. The answer key is kept back for now.

Quiz — Unit 1: A Safe First AWS Account

Instructions: Ten questions in two parts, and both parts are scored.

  • Questions 1–8 are multiple choice. Pick one option per question. They are marked by comparing your letter against the key.
  • Questions 9–10 ask you to write a short answer in an exact format. The format is stated with each question, so you can check that your answer has the right shape before you submit it. The format tells you the shape of the answer, not the answer.

Work closed-book. The answer key, which holds the marking rules, is held separately.


1. A learner on the Free account plan uses up all of the account’s credits during a few weeks of experiments. According to AWS, what happens next?

a) The account moves to pay-as-you-go pricing and the card on file is charged for later usage b) The account closes; AWS keeps its content for 90 days, and upgrading within that window keeps it c) Only the services outside the Always Free list stop working, and the rest of the account stays open d) Nothing changes until the plan’s fixed period from sign-up ends, because credits are tracked separately


2. Which of these tasks requires signing in as the root user?

a) Creating an IAM user group and attaching the AdministratorAccess policy b) Changing the account’s primary contact phone number and postal address c) Creating a budget from the zero spend template in the Billing console d) Turning on IAM user and role access to the Billing and Cost Management console


3. You want an everyday administrator identity in a standalone account on the Free account plan, and you do not want the account’s plan to change. Which option gives you that?

a) An IAM user with a console password and MFA, in a group with AdministratorAccess b) An organization instance of IAM Identity Center with an administrator permission set c) An account instance of IAM Identity Center with an administrator permission set d) Root user access keys stored in a password manager on your own laptop


4. Which statement about MFA for the root user matches the AWS documentation?

a) MFA on the root user is optional and is recommended only for accounts used by a business b) Only one MFA device can be registered to the root user, and adding a second replaces the first c) Up to eight MFA devices can be registered, so losing one phone need not lock you out d) Root user MFA stops being needed once an administrator IAM user with its own MFA exists


5. You launch a server with the console Region selector set to Asia Pacific (Mumbai). Later the selector shows Asia Pacific (Singapore), and the server list is empty. What is true?

a) The server was deleted when the selector changed, so it is no longer using any credits b) The server was moved to Singapore, because a Region is only a display preference of the console c) It is still running in Mumbai and using credits; the console lists one Region at a time d) The server is paused until the selector returns to Mumbai, which also pauses what it costs


6. What does a budget created from the Zero spend budget template notify you about?

a) Spending that has gone past the AWS Free Tier limits b) Every sign-in to the console by the root user c) The date on which the Free account plan will end d) Usage reaching 85 percent of a free allowance


7. Your administrator IAM user is in a group with AdministratorAccess. Why does it still need MFA?

a) IAM users cannot sign in to the console at all until an MFA device is registered for them b) MFA is the setting that gives an IAM user access to the Billing and Cost Management console c) The AdministratorAccess policy denies every request that arrives without an MFA code d) A stolen password alone would give full control, because the policy allows every action


8. A video tutorial says an AWS server “is free for the first twelve months after you sign up”. You create an account today on the Free account plan. What should you do with that claim?

a) Rely on it, because a twelve-month offer is attached to every newly created account b) Check it against the current Free Tier page, because current plans work on credits instead c) Rely on it, but only in Regions that are enabled by default, such as Asia Pacific (Mumbai) d) Rely on it only after upgrading, because the offer belongs to the Paid account plan


Part 2 — Short answers in an exact format

Each answer below is a single line of text in the format the question states.


9. For each task below, write R if it can be done only by signing in as the root user, or E if the everyday administrator IAM user from this unit can do it. Write six letters in the order of the tasks, with no separators — for example EERREE (that example is the format, not the answer).

  1. Changing the email address the root user signs in with
  2. Creating a new IAM user for a friend who wants to watch you work
  3. Closing the AWS account for good
  4. Changing the account’s contact information
  5. Restoring permissions after the only administrator IAM user removed their own access
  6. Deleting a storage bucket that the administrator user created

10. Each line describes an account. For each, write which event decides what happens to it, using exactly one of these three words:

  • credits — the plan ends because the credits are used up
  • time — the plan ends because its fixed period from sign-up has run out
  • continues — the account stays open and usage beyond the credits is charged

Write three words separated by commas, in the order A, B, C — for example time,time,credits (that example is the format, not the answer).

  • A. A Free account plan account whose credits reach zero before its fixed period is over.
  • B. A Free account plan account that still has USD 60 of credits when its fixed period is over.
  • C. A Paid account plan account whose credits reach zero.

Sources

All retrieved 2026-10-02:

Blog posts from this chapter

TechEazy Consulting training material — not affiliated with or endorsed by Amazon Web Services (AWS).