Learn how the public cloud works: service models, regions, shared responsibility, compute, storage, networking, IAM, secrets and cost control, using free tiers only.

Cloud Fundamentals

Confirm your budget alert exists and that you are signed in as a non-root user or through IAM Identity Center (create an admin user with MFA for yourself if you have only root).

Pick the task: "A reporting job uploads files to `s3://<yourname>-reports/daily/` and must not read, list or delete anything." Write down the single action it needs and the exact resource ARN.

Write the policy JSON by hand, like the lesson's final example. Do not use any wildcard in Action.

Write a second, wider policy that a beginner might use (for example `s3:*` on `*`) and list three bad things it would allow.

In the IAM console, open Policies, Create policy, JSON editor, paste your least-privilege policy, and check the editor shows no errors. Name it `practice-report-writer`.

Open the IAM policy simulator (policysim.aws.amazon.com), choose your policy, and simulate `s3:PutObject` on `arn:aws:s3:::<yourname>-reports/daily/test.csv` (expect allowed) and on `arn:aws:s3:::<yourname>-reports/other/test.csv` (expect denied).

Simulate `s3:DeleteObject` and `s3:GetObject` on the daily prefix and confirm both are denied.

Cleanup: delete the `practice-report-writer` policy (and any test role or user you created). Leave your own admin user with MFA in place.

## Why it matters

In the cloud, identity is the new perimeter. Anyone holding valid credentials with broad permissions can delete servers, read data or run up a huge bill, from anywhere in the world. Leaked access keys in public Git repositories are found by automated scanners within minutes. Identity and Access Management (IAM) is how you decide exactly who can do what, and it is the most important security control you own under the shared responsibility model.

## The core idea

Every request to a cloud API is checked: **who** is asking (the principal), **what** they want to do (the action), **on which** resource, and under what **conditions**. On AWS the building blocks are:

- **Root user:** the account owner. Use it only for a handful of account tasks; protect it with MFA and never create access keys for it.
- **Users and groups:** for people. Today most organisations sign people in through a central identity provider (AWS IAM Identity Center, Microsoft Entra ID, Google Workspace) instead of creating many IAM users.
- **Roles:** identities that people or services **assume** to get temporary credentials. An EC2 instance, a Lambda function or a CI pipeline should use a role, never a hard-coded access key.
- **Policies:** JSON documents that allow or deny actions.

Azure uses role assignments (RBAC) at a scope, and Google Cloud uses IAM roles bound to principals on a resource; the ideas are the same.

## Reading a policy

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-reports-2026/reports/*"
    },
    {
      "Sid": "ListReportsPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::acme-reports-2026",
      "Condition": { "StringLike": { "s3:prefix": "reports/*" } }
    }
  ]
}
```

- `Effect` is `Allow` or `Deny`.
- `Action` names API operations, `service:Operation`.
- `Resource` is an ARN (Amazon Resource Name). Note that listing applies to the bucket ARN, while reading applies to object ARNs ending in `/*`.
- `Condition` narrows when the statement applies.

The evaluation rules: everything is **denied by default**; an explicit `Allow` grants access; an explicit `Deny` anywhere always wins.

## Least privilege, worked through

A nightly job copies a CSV export into `s3://acme-reports-2026/reports/`. A beginner might attach the managed policy `AmazonS3FullAccess`. That lets the job delete every bucket in the account. Least privilege asks: what is the smallest set of actions on the smallest set of resources that still lets the job work?

```json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::acme-reports-2026/reports/*"
  }]
}
```

That is the whole policy: the job can add files to one prefix in one bucket and nothing else. Attach it to a **role** that the job's compute (EC2, Lambda or a container task) assumes, so there are no keys to leak.

How to find the minimum: start from what the task needs, test, and add only what fails. AWS also offers IAM Access Analyzer, which can suggest policies based on recorded activity, and "last accessed" information that shows permissions nobody uses.

## Good habits

- MFA on every human login, especially root and administrators.
- Humans sign in through single sign-on and get temporary credentials; services use roles.
- Grant permissions to groups or roles, not to individuals one by one.
- Review and remove unused users, keys and permissions regularly.
- Use wildcards (`*`) sparingly and never as `"Action": "*", "Resource": "*"` outside a break-glass admin role.

## Common mistakes

- Daily work as the root user.
- Long-lived access keys pasted into code, scripts or `.env` files that get committed.
- `*FullAccess` policies attached "just to make it work".
- Forgetting that `s3:ListBucket` needs the bucket ARN, not the object ARN, and then widening everything to `*` out of frustration.

## Quick recap

- Every API call is checked against principal, action, resource and conditions; default deny, explicit deny wins.
- People use SSO and MFA; workloads use roles with temporary credentials.
- Least privilege means the smallest actions on the smallest resources; start small and add what is proven necessary.

## Try it

In the Do tab you write a least-privilege policy for a real task and test it with the IAM policy simulator.


Write a least-privilege IAM policy and use roles instead of long-lived keys.

UPDATED - AWS Identity and Access Management (IAM) Basics | AWS Tutorials For Beginners

How to Use AWS IAM Policies

## Why it matters

A secret is any value that grants access: database passwords, API keys, cloud access keys, private TLS keys, signing keys, webhook tokens. Once a secret is committed to a Git repository, you should assume it is public: forks, clones, CI logs and backups keep copies even after you delete the line. Attackers run bots that scan public repositories for cloud keys and start using them within minutes, often to mine cryptocurrency on your bill.

## The core idea

Code should say **which** secret it needs, never **what** the secret is. The value is supplied at runtime from a place designed to protect it, and access to that place is controlled by IAM.

A ladder from worst to best:

1. **Hard-coded in source.** Never.
2. **In a config file committed to Git.** Never.
3. **In environment variables** set by the deployment platform. Acceptable for many apps, as long as the values themselves are stored securely by the platform and not echoed into logs.
4. **In a secrets manager** (AWS Secrets Manager or Systems Manager Parameter Store SecureString, Azure Key Vault, Google Secret Manager), fetched at runtime by a role. Best for production: central storage, encryption with a managed key, access logging and rotation.
5. **No long-lived secret at all.** Use roles and short-lived tokens wherever the service supports it, for example a VM role instead of an access key, or a CI system using OpenID Connect to assume a cloud role.

## Worked example: from hard-coded to managed

The anti-pattern:

```python
# app.py  (do not do this)
DB_PASSWORD = "S3cretPassw0rd!"
```

Step one, read it from the environment and fail loudly if it is missing:

```python
import os

DB_PASSWORD = os.environ["DB_PASSWORD"]   # KeyError at start-up if not set
```

For local development, keep values in a `.env` file that is listed in `.gitignore`, and commit a `.env.example` with names but no values:

```bash
# .gitignore
.env

# .env.example (committed)
DB_PASSWORD=
PAYMENTS_API_KEY=
```

Step two, in production fetch the secret from a manager using the compute's role, so no secret ever sits in the deployment configuration:

```python
import json
import boto3

def get_db_password():
    client = boto3.client("secretsmanager")
    resp = client.get_secret_value(SecretId="prod/shop/db")
    return json.loads(resp["SecretString"])["password"]
```

The role's policy allows `secretsmanager:GetSecretValue` on that one secret only, which is least privilege applied to secrets.

## Keys and encryption

Encryption keys are a special kind of secret. Cloud key management services (AWS KMS, Azure Key Vault keys, Google Cloud KMS) keep the key material inside the service; you ask the service to encrypt or decrypt, and IAM controls who may do so. Most storage and database services can encrypt at rest with a managed key at the tick of a box. **Rotation** means replacing a key or password on a schedule, or immediately if it may have leaked. Secrets managers can rotate some database passwords automatically.

## If a secret leaks

Act in this order:

1. **Revoke or rotate it immediately** in the system that issued it. Deleting the commit is not enough.
2. Check access logs (for example AWS CloudTrail) for use of the leaked credential.
3. Remove it from the repository history if needed, and add scanning to stop a repeat.

Secret scanning tools (GitHub secret scanning and push protection, gitleaks, trufflehog) catch many leaks before or just after they happen.

## Common mistakes

- Printing configuration (including secrets) to logs at start-up.
- Sharing one powerful key across many apps and people, so it can never be rotated safely.
- Committing `.env` "just once" for a teammate.
- Putting secrets in container images or front-end JavaScript, where anyone can read them.
- Rotating a leaked key days later "after the release".

## Quick recap

- Code names the secret; the runtime supplies the value from environment variables or, better, a secrets manager.
- Prefer roles and short-lived tokens so there is no long-lived secret to leak.
- Keep `.env` out of Git, scan for secrets, and rotate immediately on any leak.


Keep passwords, API keys and other secrets out of code and fetch them safely at runtime.

Secrets and keys

What is Secrets Management?

Back to Basics: Secrets Management

Open Billing and Cost Management, Budgets, and confirm the budget from the first module exists. Edit it to add a second alert at 80% of forecast spend if it has none.

Open Cost Explorer (it can take up to a day to activate on a new account) and group spend by service for this month. Note any service with a non-zero cost.

Launch a free-tier VM exactly as in the Compute lesson (SSH from My IP only) and add a tag `project=practice`.

In CloudWatch, create an alarm on the instance's `StatusCheckFailed` metric: Maximum, 1 minute, >= 1 for 2 datapoints. For the action, create an SNS topic that emails you, and confirm the subscription email.

In the alarm list, check its state becomes OK after a few minutes. Write a two-line runbook for what you would do when it fires.

Optional: in the VM, run `sudo apt-get install -y nginx` and add a `/healthz` page in `/var/www/html` to see what a health endpoint returns (keep port 80 closed in the security group; test with `curl localhost/healthz` from the VM).

Cleanup: terminate the VM, delete the CloudWatch alarm and the SNS topic, and check EC2 Volumes and Elastic IPs for leftovers. Keep your budget.

Use the Resource Groups and Tag Editor to search all regions for `project=practice` and confirm nothing remains.

## Why it matters

If you cannot see what your system is doing, you find out about problems from angry users or a bill. Monitoring tells you when something is broken, slow or expensive, ideally before anyone else notices. In the cloud you also monitor money: cost is a metric like CPU, and it needs alerts just as much.

## The core idea: metrics, logs, traces, alarms

- **Metrics** are numbers over time: CPU percentage, requests per minute, error count, estimated charges. Cloud services publish many metrics automatically. On AWS they go to **Amazon CloudWatch**; Azure has **Azure Monitor**; Google has **Cloud Monitoring**.
- **Logs** are timestamped records of events: application output, web server access logs, and the audit log of who called which API (**AWS CloudTrail**, Azure Activity Log, Google Cloud Audit Logs).
- **Traces** follow one request across several services (covered in the DevOps & Cloud Delivery course).
- **Alarms** watch a metric and act when it crosses a threshold for a period: send an email or chat message, or trigger an automatic action.

## Health checks

A health check asks "is this working?" on a schedule.

- **Status checks:** EC2 runs system and instance status checks on every VM and publishes the `StatusCheckFailed` metric.
- **Load balancer health checks:** the load balancer calls a path such as `/healthz` on each server every few seconds and stops sending traffic to servers that fail.
- **External checks:** a probe outside your network loads your public URL, as a user would. This catches problems (DNS, certificates, a whole region) that internal checks miss.

A good health endpoint is cheap and honest:

```python
# Flask example
@app.get("/healthz")
def healthz():
    db_ok = ping_database(timeout_seconds=1)
    return ({"ok": db_ok}, 200 if db_ok else 503)
```

## Writing alarms people trust

An alarm should mean "a human needs to act". For each one decide:

```text
Metric:     StatusCheckFailed for instance practice-vm
Statistic:  Maximum over 1 minute
Threshold:  >= 1 for 2 consecutive periods
Action:     email the on-call address (via an SNS topic)
Runbook:    "Check the console, reboot, check system log, replace from image"
```

Alarm on symptoms users feel (errors, latency, health checks failing) before causes (CPU at 80%). Too many noisy alarms train people to ignore them.

## Billing alerts, revisited

In the first module you created a budget. Now make cost monitoring a habit:

- **Budgets** alert on actual or forecast spend for the month, for the whole account or filtered by service or tag.
- **Cost anomaly detection** (AWS Cost Anomaly Detection, and similar tools on other clouds) flags unusual spend patterns, such as a service that suddenly costs ten times more than usual.
- **Tags** such as `project=practice` and `owner=you` let you see which project is costing what and find forgotten resources.
- **Cost Explorer** (or Azure Cost Management, Google Billing reports) shows spend by service and day. Open it weekly.

Remember: a budget alert notifies, it does not stop resources. The cleanup habit is still yours.

## Worked example: a forgotten resource

You get a budget email: forecast spend is 14 US dollars against a 1-dollar budget. In Cost Explorer, grouped by service, "EC2 - Other" stands out. Grouped by usage type, it shows NAT gateway hours. You left a NAT gateway from a networking tutorial in another region. You delete it, then add a habit: tag everything with `project` and check all regions in the console after each session. Without the alert, that would have run all month.

## Common mistakes

- Alarms with no action, or sending to an inbox nobody reads.
- Only internal checks, so a DNS or certificate failure goes unnoticed.
- Logging secrets or personal data.
- Keeping debug-level logs forever and paying to store them; set retention periods.
- Treating a budget alert as a spending cap.

## Quick recap

- Metrics, logs, traces and alarms answer "what is happening and when must a human act?"
- Health checks run at three levels: status checks, load balancer checks and external probes.
- Budgets, anomaly detection, tags and a weekly cost review catch forgotten resources early.

## Try it

The Do tab has you add an alarm and a cost check to your account, then clean up.


Set a budget alert and a health-check alarm, and know where to look when something breaks.

Monitoring and billing alerts

AWS Budgets Tutorial - Setup Alerts for AWS Billing | Amazon Web Services

Basics of Amazon CloudWatch and CloudWatch Metrics | AWS Tutorials for Beginners

Search a job site for "cloud engineer" or "machine learning engineer" roles in your area. Read ten adverts and tally mentions of AWS, Azure and Google Cloud.

Open the official pages for AWS Certified Cloud Practitioner, Azure Fundamentals (AZ-900) and Google Cloud Digital Leader. For each, note the exam format, the domains and the current price. Write "Checked on" with today's date next to your notes.

Choose one certification and write one sentence explaining why.

Download or open its official exam guide. Make a table mapping each domain to the lessons in this course that cover it, and mark any gaps.

Find the provider's free official learning path and practice questions and bookmark them.

Write a four-week plan (or longer if you have less time) with specific sessions in your calendar, including at least two hands-on free-tier sessions, each ending with cleanup.

Pick a target exam week and write it at the top of your plan.

## Why it matters

Certifications do not replace hands-on skill, but for an entry-level cloud engineer they do two useful things: they give your study a clear syllabus, and they get your CV past filters that look for a recognised credential. Employers hiring cloud engineers usually look for associate-level certifications (for example AWS Solutions Architect Associate or Azure Administrator) plus real projects. A fundamentals certification is the common first step.

## The three foundational certifications

| Certification | Provider | Focus |
|---|---|---|
| [AWS Certified Cloud Practitioner](https://aws.amazon.com/certification/certified-cloud-practitioner/) | AWS | Cloud concepts, security and compliance, core AWS services, billing and pricing |
| [Microsoft Certified: Azure Fundamentals (AZ-900)](https://learn.microsoft.com/en-us/credentials/certifications/azure-fundamentals/) | Microsoft | Cloud concepts, Azure architecture and services, management and governance |
| [Google Cloud Digital Leader](https://cloud.google.com/learn/certification/cloud-digital-leader) | Google Cloud | Digital transformation with Google Cloud, data and AI, infrastructure, security and operations |

Checked on 2026-10-23. Exam codes, domains, prices, languages and validity periods change, so read the official exam guide on each page before you book. Do not rely on numbers in videos or blog posts, including this one.

All three are multiple-choice exams aimed at people new to the platform, and none require a degree or prior certification. They test whether you understand the concepts in this course: service models, regions and zones, shared responsibility, core compute, storage and networking services, IAM, and pricing. Microsoft Learn and AWS Skill Builder offer free official learning paths; Google Cloud Skills Boost has free introductory content.

## Which one first?

- **Look at job adverts** in your area for cloud or ML engineering roles. Count which provider appears most. That is usually your answer.
- If your school or employer already uses one provider, start there: you will get practice for free.
- If you are unsure, AWS has the largest market share, Azure dominates in organisations built on Microsoft 365 and Windows, and Google Cloud is strong in data and machine learning.
- For machine learning engineers, the fundamentals exam is a stepping stone toward the providers' ML or data certifications later.

Doing one fundamentals exam is enough. The concepts transfer, and your next step should be an associate-level certification plus projects, not a second fundamentals badge.

## Building a study plan

A realistic plan for someone who has completed this course is a few weeks of steady study. A sample four-week plan for the AWS exam:

```text
Week 1  Read the official exam guide; map each domain to lessons in this course.
        Work through the free official learning path, domain 1 (cloud concepts).
Week 2  Security and compliance: shared responsibility, IAM, MFA, encryption, audit logs.
        Redo the IAM and Secrets lessons' tasks.
Week 3  Technology and services: compute, storage, databases, networking, global infrastructure.
        Redo the Compute and Storage tasks on the free tier; clean up each time.
Week 4  Billing, pricing and support plans. Take the official practice question set.
        Review every wrong answer until you can explain why the right one is right.
```

Study habits that work:

- **Explain, do not memorise.** If you can explain why multi-AZ survives a zone failure, you can answer any question about it.
- **Keep an "I got this wrong" list** and revisit it every few days.
- **Use official practice questions first**, then reputable free resources. Avoid "exam dumps": using leaked questions breaks the providers' exam agreements and can lead to a revoked certification.
- **Book the exam** once practice scores are consistently comfortable. A date on the calendar focuses study.

## What employers also want

Pair the certificate with evidence. A small public portfolio project, built with infrastructure as code, with a README that explains the architecture, the costs and how you secured it, says far more than a badge. Combine it with the Linux and networking skills from earlier courses, which interviewers test directly.

## Common mistakes

- Collecting several fundamentals certifications instead of moving to associate level.
- Studying only from videos without doing hands-on tasks.
- Leaving free-tier resources running while studying.
- Trusting third-party claims about exam content instead of the official guide.

## Quick recap

- AWS Cloud Practitioner, Azure Fundamentals (AZ-900) and Google Cloud Digital Leader are the entry-level options; pick one based on local job adverts.
- Use the official exam guide and free official training; check details on the provider's page.
- A few focused weeks, hands-on practice and a portfolio project beat memorising questions.

## Try it

In the Do tab you compare the official pages and write your own study plan.


Compare the entry-level cloud certifications and make a realistic study plan for one.

Cloud practitioner exam prep

AZ-900 | Microsoft Azure Fundamentals Full Course, Free Practice Tests, Website and Study Guides

AWS Certified Cloud Practitioner Review and Passing Advice!

Least-privilege IAM, secrets handling, monitoring and billing alerts, and a plan for a cloud fundamentals certification.