Cloud · free · no signup

Learn cloud, with practice after every lesson

8 lessons, about 125 minutes of reading, and 24 multiple-choice questions. Each lesson names the mistake that most often costs people the interview, because that is where the hours actually go. Part of the free coding course.

What the cloud actually is

Basics Cloud · 12 min · 10 XP

The cloud is somebody else's computer, rented by the minute. That sounds glib but it is the whole idea: instead of buying a server, waiting six weeks for it to arrive and running it in a room, you ask Amazon or Microsoft or Google for one and have it thirty seconds later. When you stop paying, it disappears.

This matters for a job search because AWS appears in 70% of the DevOps and platform postings we measured, and it shows up constantly in backend and data roles too. You are not expected to have run production infrastructure to get a first cloud role. You are expected to know what the pieces are called and which one you would reach for, which is a much smaller thing to learn than it appears.

Four services carry most of it. Compute is a virtual machine you rent (EC2, Compute Engine). Storage is a bucket of files addressed by URL (S3, Cloud Storage). Database is a managed Postgres or MySQL (RDS, Cloud SQL). Networking is the private network they all sit in (VPC). Every provider has these under different names, so learning the concepts once means the second provider takes a weekend rather than a term.

Syntax

# The four services almost every posting assumes you know:
#
#  COMPUTE   EC2 / Compute Engine      a virtual machine you rent
#  STORAGE   S3  / Cloud Storage       a bucket of files, addressed by URL
#  DATABASE  RDS / Cloud SQL           a managed Postgres or MySQL
#  NETWORK   VPC                       the private network they all sit in
#
# Renting a small Linux machine on AWS, from a terminal:
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key

# Copying a file into object storage:
aws s3 cp report.csv s3://my-company-reports/2026/report.csv

Key points

  • Every provider has the same four building blocks under different names. Learn the concepts once and the second provider takes a weekend.
  • 'Managed' means the provider handles backups, patching and failover. You pay more per hour and save far more in your own time.
  • Nothing is free forever. A machine you forget to shut down bills every hour it exists, which is how people get a surprise invoice in month one.
The mistake that costs people the interview: Assuming you need to learn all three providers. Postings almost always name one. Pick the one your target companies use — AWS in most of India and the US, Azure in enterprise and government — and go deep rather than wide.

Practice challenge

Name the four servicesBasics
Task

A startup needs to host a web API, store user-uploaded images, keep customer records, and put all of it on a private network. Name the AWS service for each of the four, and the GCP equivalent.

Expected answer
COMPUTE: EC2 / Compute Engine
STORAGE: S3 / Cloud Storage
DATABASE: RDS / Cloud SQL
NETWORK: VPC / VPC
Answer template
COMPUTE:  AWS ______  /  GCP ______
STORAGE:  AWS ______  /  GCP ______
DATABASE: AWS ______  /  GCP ______
NETWORK:  AWS ______  /  GCP ______
Show a hint
  1. Compute is a virtual machine you rent by the minute
  2. Storage here means objects addressed by URL, not a disk
  3. The database one is 'managed' — the provider patches and backs it up

Open this exercise in the app →

Check yourself

1. What is S3 used for?

  1. Running virtual machines
  2. Storing files as objects
  3. Managing networks
  4. Sending email
Show answer

B. Storing files as objects

2. What does a 'managed' database give you?

  1. Lower hourly cost
  2. The provider handles backups and patching
  3. Unlimited storage
  4. Automatic code deployment
Show answer

B. The provider handles backups and patching

3. Why does an idle cloud machine still cost money?

  1. It does not
  2. You are billed for the time it exists, not the work it does
  3. Only storage is billed
  4. Billing starts after 30 days
Show answer

B. You are billed for the time it exists, not the work it does

Back to the syllabus ↑

Regions, availability and why it matters

Working level Cloud · 14 min · 15 XP

A region is a physical place — Mumbai, Frankfurt, Oregon. Inside each region are availability zones, which are separate buildings with separate power and network. Choosing a region decides three things at once: how fast your users are served, which laws apply to the data, and what it costs, because the same instance is priced differently in different regions.

This is the most common real interview question at the junior end, because it is where beginners make expensive mistakes. Putting an Indian product's database in Virginia adds roughly 200 milliseconds to every query — not once, but on every round trip — and may put personal data under a jurisdiction your legal team did not agree to.

The distinction worth being precise about is zones versus regions. Multi-zone protects against one building losing power and is cheap enough to be the default for anything that matters. Multi-region protects against an entire region failing, costs far more, and adds real complexity around data consistency. Most products genuinely do not need it, and saying so in an interview shows better judgement than claiming everything should be multi-region.

Syntax

# Same command, different region, materially different product:
aws s3 mb s3://my-bucket --region ap-south-1      # Mumbai
aws s3 mb s3://my-bucket --region us-east-1       # N. Virginia

# Availability zones inside one region:
#   ap-south-1a   ap-south-1b   ap-south-1c
#
# One zone can lose power without the others going down.
# Running in a single zone is cheaper and is a single point of failure.
#
# Latency, roughly, from Bengaluru:
#   ap-south-1 (Mumbai)     ~20 ms
#   ap-southeast-1 (S'pore) ~60 ms
#   us-east-1 (Virginia)   ~200 ms

Key points

  • Region is chosen once and is painful to change later — data has to be migrated and some services cannot move at all.
  • Multi-zone protects against a building failing. Multi-region protects against a whole region failing, costs far more, and most products genuinely do not need it.
  • Data residency rules mean the region choice can be a legal decision, not only a performance one.
The mistake that costs people the interview: Defaulting to us-east-1 because every tutorial uses it. For an Indian product that is a permanent latency tax on every user and an avoidable compliance question.

Practice challenge

Pick the regionWorking level
Task

An Indian fintech serves customers only in India and must keep personal data onshore. A tutorial tells them to deploy to us-east-1. Give the region you would choose, and two separate reasons the tutorial's default is wrong here.

Expected answer
Region: ap-south-1 (Mumbai)
Performance: ~20ms from Bengaluru vs ~200ms to Virginia, on every round trip
Legal: data residency — personal data would sit under another jurisdiction
Answer template
Region: ______
Reason 1 (performance): ______
Reason 2 (legal): ______
Show a hint
  1. Latency is per round trip, not once per session
  2. One of the two reasons has nothing to do with speed

Open this exercise in the app →

Check yourself

1. What does an availability zone protect against?

  1. A whole region failing
  2. One building or power source failing
  3. Slow internet
  4. Rising costs
Show answer

B. One building or power source failing

2. Why is region choice hard to reverse?

  1. Providers charge a fee
  2. Data must be migrated and some services cannot move
  3. It requires a new account
  4. It is not hard to reverse
Show answer

B. Data must be migrated and some services cannot move

3. For users in India, which region is usually correct?

  1. us-east-1
  2. ap-south-1
  3. eu-west-1
  4. whichever is cheapest
Show answer

B. ap-south-1

Back to the syllabus ↑

Infrastructure as code with Terraform

Advanced Cloud · 16 min · 20 XP

Clicking through a web console to create servers works once and is unrepeatable. Infrastructure as code means writing the setup in a file, committing it, and letting a tool build it. The file becomes the record of what exists — no more wondering who created a machine, when, or whether anything depends on it.

Terraform appears in 51% of the DevOps postings we measured, which puts it ahead of most tools people spend longer learning. The reason is that it works across providers and, crucially, it can tell you what it is about to change before it changes anything. terraform plan is a dry run that reads like a diff, and reading it carefully is the habit that separates careful engineers from expensive ones.

Terraform keeps state — a file recording what it built, so it can compute the difference between the world as described and the world as it is. That state file is the fragile part: losing it or hand-editing it is how environments get corrupted, which is why teams store it remotely with locking rather than on someone's laptop. The related discipline is tagging everything, because six months on, an untagged machine is one nobody dares delete.

Syntax

# main.tf — the whole environment, in version control

resource "aws_s3_bucket" "reports" {
  bucket = "jobstraight-reports"
}

resource "aws_instance" "api" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"
  tags = {
    Name        = "api-server"
    Environment = "production"
  }
}

# terraform plan    shows what WOULD change, changes nothing
# terraform apply   makes it so
# terraform destroy tears the whole thing down

# plan output reads like a diff:
#   + aws_instance.api will be created
#   ~ aws_s3_bucket.reports will be updated in-place

Key points

  • Always run plan before apply. It is a dry run, and reading it is the habit that separates careful engineers from expensive ones.
  • Terraform keeps state — a file recording what it built. Losing or hand-editing that state is how environments get corrupted; store it remotely and lock it.
  • Tag everything. Six months on, an untagged machine is one nobody dares delete because nobody knows what it does.
The mistake that costs people the interview: Making a quick change in the web console and not putting it in the code. The next apply either reverts your fix or fails on a conflict, and the file no longer describes reality — which was the entire point.

Practice challenge

Read a terraform planAdvanced
Task

A plan output shows: '~ aws_db_instance.main will be updated in-place' and '- aws_s3_bucket.backups will be destroyed'. You expected only a database size change. State what you do next and why.

Expected answer
Do not apply. The bucket destruction was not intended, so the code no longer matches what you meant — investigate why backups is being removed (deleted from config, or renamed) before running apply.
Answer template
Action: ______
Reason: ______
Show a hint
  1. The whole point of plan is that it runs before anything changes
  2. A destroy on a bucket named 'backups' is not recoverable by re-running apply

Open this exercise in the app →

Check yourself

1. What does terraform plan do?

  1. Creates the infrastructure
  2. Shows what would change without changing it
  3. Deletes unused resources
  4. Estimates the monthly bill
Show answer

B. Shows what would change without changing it

2. Why does Terraform keep a state file?

  1. To cache credentials
  2. To record what it built so it can compute the difference
  3. To speed up plan
  4. For billing
Show answer

B. To record what it built so it can compute the difference

3. What breaks when someone edits infrastructure in the console instead?

  1. Nothing
  2. The code no longer describes reality and the next apply conflicts
  3. Terraform stops working permanently
  4. The state file is deleted
Show answer

B. The code no longer describes reality and the next apply conflicts

Back to the syllabus ↑

Design a small system out loud

Job-ready Cloud · 18 min · 25 XP

The cloud interview is rarely about services. You are given something vague — "design a URL shortener", "how would you host this API for 10,000 users" — and assessed on whether you ask what the constraints are before you start drawing. Candidates who name six AWS services in the first minute score badly, because naming is not designing.

The shape that works: clarify the requirement, state the traffic assumption out loud, sketch the smallest thing that meets it, then say where it breaks and what you would change. "Ten thousand users, mostly during the working day, so a couple of hundred requests a second at peak — one load-balanced service and a managed database handles that. It breaks when reads dominate, and the first fix is a cache, not a bigger database."

Say the trade-off you are accepting, every time. Managed services cost more per unit and less in salary. Multiple availability zones survive a data-centre failure and double your bill. Serverless removes capacity planning and adds cold starts. An interviewer is listening for whether you know something is being traded, not for the answer they had in mind.

Syntax

Requirement:  a link shortener, 10k users, reads >> writes

Assume     : ~200 req/s peak, 95% reads, links live for years
Smallest   : ALB -> 2x container (Fargate) -> RDS Postgres (Multi-AZ)
             short code = base62 of the row id
Breaks when: read traffic outgrows one DB instance
First fix  : cache the code->URL lookup (ElastiCache), TTL 24h
Then       : read replicas; only then consider a rewrite

Trade-offs stated:
  Multi-AZ   -> survives one AZ failing, roughly doubles DB cost
  Fargate    -> no servers to patch, ~20% more per vCPU than EC2
  Postgres   -> boring and well understood; NoSQL buys nothing here

Key points

  • Ask for the constraint before you draw anything. "How many users, and what is the read/write split?" is the single highest-scoring sentence in a cloud interview.
  • State a number for your traffic assumption even if you have to invent it. A wrong number you can reason from beats no number.
  • Name where your design breaks before the interviewer does. It reads as experience rather than as a gap they found.
The mistake that costs people the interview: Jumping straight to a microservice diagram with a queue, a cache and six services for a problem that one server and a database would solve. Interviewers read over-engineering as inexperience, because someone who has run systems knows what each extra box costs to operate at 3am.

Practice challenge

Size it before you draw itJob-ready
Task

You are asked to design image hosting for a marketplace: 50,000 sellers, each uploading a few photos a week, buyers viewing them constantly. Before drawing anything, write the three clarifying questions you would ask, your traffic assumption with a number, and the smallest design that meets it — then say where it breaks.

Expected answer
Q1: read/write ratio and peak concurrent viewers?
Q2: image sizes, and do we need resizing/thumbnails?
Q3: retention - do listings and their photos live forever?
Assumption: ~50k sellers x 5 photos/week is tiny for writes (<1/s); reads dominate, say 500/s peak. Ratio roughly 1000:1 read-heavy.
Smallest: object storage (S3) + CDN in front. No servers in the read path at all.
Breaks when: you need resizing, moderation or access control per image
First fix: a resize-on-upload function writing derivatives to the same bucket - still no server in the read path
Answer template
Q1: ______
Q2: ______
Q3: ______
Assumption: ______ req/s, read:write ratio ______
Smallest design: ______
Breaks when: ______
First fix: ______
Show a hint
  1. A read:write ratio this extreme usually means the answer is storage plus a CDN, not an application tier
  2. Ask what has to happen to an image between upload and display - that is where the real requirement hides

Open this exercise in the app →

Check yourself

1. What should you do first when given an open-ended design question?

  1. Draw the architecture
  2. Name the services you would use
  3. Ask about scale and the read/write split
  4. Estimate the monthly bill
Show answer

C. Ask about scale and the read/write split

2. Why say where your design breaks?

  1. It fills time
  2. It shows you know the limits of your own choice
  3. It is required by AWS
  4. It avoids drawing a diagram
Show answer

B. It shows you know the limits of your own choice

3. For a read-heavy service outgrowing its database, what is the usual first fix?

  1. Rewrite in a faster language
  2. Add a cache in front of the reads
  3. Shard the database immediately
  4. Move to a different cloud
Show answer

B. Add a cache in front of the reads

Back to the syllabus ↑

The bill, and what runs it up

Basics Cloud · 14 min · 10 XP

Cloud pricing is rented time and rented movement, and almost every surprise on a bill comes from one of four things. Compute is billed while it exists, not while it is busy — an idle server costs the same as a working one, which is why a forgotten test instance is the most common line item nobody can explain. Storage is billed per gigabyte per month and is usually cheap enough to ignore until snapshots accumulate, because deleting a volume does not delete its snapshots.

The third is data transfer, and it is the one people do not see coming, because the direction matters. Data in is typically free; data out to the internet is charged per gigabyte, and traffic between regions or between availability zones is charged too. That is how an architecture that looks tidy on a diagram — a service in one region talking constantly to a database in another — becomes an invoice nobody budgeted for, without a single thing being wrong.

The fourth is managed services, which trade money for the work you no longer do. A managed database costs several times the raw server, and is usually still correct, because the alternative is you doing backups, patching, failover and monitoring. The honest way to compare is not price against price, but price against the hours and the risk you are handing over — and then to check the actual bill monthly, because the gap between the estimate and reality is where the story lives.

Syntax

# The four things that make up almost every bill:
#
# 1. COMPUTE   billed while it EXISTS, not while it is used
#    t3.medium  ~$30/mo running 24/7 -- idle costs the same
#    -> stop non-production overnight: ~65% saved on that instance
#
# 2. STORAGE   per GB per month, plus snapshots you forgot
#    100 GB volume    ~$8/mo
#    30 daily snaps   ~$75/mo   <- deleting the volume leaves these
#
# 3. TRANSFER  IN free, OUT charged, CROSS-REGION charged
#    1 TB out to internet   ~$90
#    cross-AZ chatter between app and db: charged both ways
#
# 4. MANAGED   you pay for the operations you no longer do
#    self-run Postgres on a VM   ~$30/mo + your weekends
#    managed equivalent         ~$130/mo + backups, failover, patching
#
# Always on, from day one:
#  - a budget alert at 50%, 80%, 100% of expected spend
#  - tags (owner, environment) so the bill can be split
#  - auto-shutdown schedule on every dev/test resource

Key points

  • Compute bills for existence, not usage. An idle instance costs full price, so scheduled shutdown on non-production is the largest easy saving available.
  • Data out and cross-region transfer are charged; data in usually is not. An architecture that chats across regions is expensive without being wrong.
  • Set a budget alert before you create anything. A bill is discovered a month late by default, and that is one month of a mistake you could have caught on day two.
The mistake that costs people the interview: Deleting a virtual machine and assuming the cost is gone. Its volume may persist, and its snapshots almost certainly do — they are billed independently, they do not appear in the instance list, and they accumulate on a schedule nobody remembers setting.

Practice challenge

Explain the billBasics
Task

A team deleted six virtual machines last month and the bill fell by only 10%. Their architecture has an application in one region talking constantly to a database in another. Name the two things still being billed from the deleted VMs, name the transfer cost they are paying, and give the one control that would have caught this in week one.

Expected answer
Still billed: the attached volumes, and the snapshots of those volumes (snapshots survive deletion of both the VM and the volume)
Transfer cost: cross-region data transfer, charged on traffic between the application and the database - and charged in both directions
Control: a budget alert set at 50/80/100% of expected spend, plus owner and environment tags so the bill can be attributed
Answer template
Still billed after deleting a VM: ______ and ______
Transfer cost: ______
Control that catches it early: ______
Show a hint
  1. Deleting the instance does not delete what was attached to it
  2. Data in is usually free; the charge is on data out and between regions

Open this exercise in the app →

Check yourself

1. An instance is running but completely idle. What does it cost?

  1. Nothing, it is idle
  2. The full hourly rate — compute bills for existence
  3. Half rate
  4. Only storage
Show answer

B. The full hourly rate — compute bills for existence

2. Which is normally charged?

  1. Data in from the internet
  2. Data out to the internet
  3. Both are free
  4. Neither is metered
Show answer

B. Data out to the internet

3. You deleted a VM but the bill barely changed. Most likely cause?

  1. Billing lag of 30 days
  2. Volumes and snapshots persist and are billed separately
  3. The VM did not delete
  4. Support plan fees
Show answer

B. Volumes and snapshots persist and are billed separately

Back to the syllabus ↑

Identity, least privilege and the leaked key

Working level Cloud · 16 min · 15 XP

In the cloud, identity is the perimeter. There is no building to be inside of; every action is an API call carrying credentials, and permission is the only thing standing between an attacker with a key and your data. This is why almost all serious cloud incidents are identity failures rather than exploits: a key in a public repo, an over-broad role, a service account still active for someone who left last year.

Least privilege means an identity can do what it needs and nothing more, and the honest version of it is uncomfortable, because the easy path is always a wildcard. Granting s3:* on * makes the error go away in ten seconds and leaves a permission you will never revisit. The workable discipline is to start from deny, add the specific action on the specific resource, and use the access analyser and last-used data your provider gives you to remove what has never been called.

Long-lived keys are the thing to design out. A static access key is a password that never expires, gets copied into a script, a laptop, a CI variable and a Slack message, and cannot be traced back to a person. The replacement is short-lived credentials issued to a role — an instance profile for a server, a workload identity for a container, an assumed role for a human logging in through SSO — all of which expire in hours and are attributable. When a key does leak, the order matters: revoke first, then read the logs to see what it did, then fix how it escaped, because reversing those steps leaves the key live while you investigate.

Syntax

# TOO BROAD -- the ten-second fix that never gets revisited
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

# LEAST PRIVILEGE -- specific action, specific resource
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::reports-prod/incoming/*"
}

# Prefer a role over a stored key:
#   server     -> instance profile
#   container  -> workload identity
#   human      -> SSO + assume role (expires in hours, attributable)

# A key has leaked. Order matters:
#  1. DEACTIVATE the key   (not "investigate first" -- it is live)
#  2. read the audit log: what did it call, from where, for how long
#  3. rotate anything it could reach
#  4. fix the escape route: .gitignore, secret manager, CI variable

# Find what to remove: last-used data tells the truth
aws iam get-access-key-last-used --access-key-id AKIA...
aws accessanalyzer list-findings

Key points

  • Identity is the perimeter. Most cloud breaches are a leaked credential or an over-broad role, not a clever exploit against infrastructure.
  • Start from deny and add the specific action on the specific resource. Wildcards are the ten-second fix that becomes a permanent standing permission.
  • Revoke a leaked key before investigating it. Reading the logs first is investigating an attack that is still in progress.
The mistake that costs people the interview: Granting a wildcard permission to unblock a deployment, intending to narrow it later. Nothing fails afterwards to remind you, so the permission stays for years and is inherited by every service that reuses the role. Narrow it in the same change, or write the ticket before you merge.

Practice challenge

Narrow an over-broad policyWorking level
Task

A service needs to read and write objects under the incoming/ prefix of the reports-prod bucket. Someone granted s3:* on * to unblock a deploy. Write the least-privilege replacement, and list the four steps in order for a key that has just been found in a public repository.

Expected answer
Action: ["s3:GetObject", "s3:PutObject"]
Resource: "arn:aws:s3:::reports-prod/incoming/*"
Leaked key: 1 deactivate the key immediately 2 read the audit log for what it called, from where, and for how long 3 rotate everything it could reach 4 fix the escape route (gitignore, secret manager, CI variable)
Answer template
Policy Action: ______
Policy Resource: ______
Leaked key, in order: 1 ______ 2 ______ 3 ______ 4 ______
Show a hint
  1. Name the specific actions and the specific prefix, not the bucket
  2. Investigating first means investigating an attack that is still live

Open this exercise in the app →

Check yourself

1. Why are cloud breaches usually identity failures?

  1. Cloud providers are insecure
  2. There is no network perimeter — credentials are the only control on API calls
  3. Encryption is weak
  4. Firewalls do not exist
Show answer

B. There is no network perimeter — credentials are the only control on API calls

2. An access key is found in a public repo. First action?

  1. Read the audit logs
  2. Deactivate the key immediately
  3. Email the team
  4. Delete the repository
Show answer

B. Deactivate the key immediately

3. What replaces a long-lived access key on a server?

  1. A longer key
  2. An instance role issuing short-lived, attributable credentials
  3. A password
  4. An IP allowlist
Show answer

B. An instance role issuing short-lived, attributable credentials

Back to the syllabus ↑

Picking the right service for the job

Advanced Cloud · 17 min · 20 XP

Every provider offers half a dozen ways to run code and half a dozen ways to store data, and the names differ across clouds while the categories do not. For compute the ladder runs from a virtual machine, where you own the operating system and everything on it, through containers on a managed orchestrator, to serverless functions where you supply only the code and pay per invocation. Control and operational burden move together: the more the provider manages, the less you can tune and the less you have to maintain.

For storage the deciding question is the access pattern, not the size. Object storage is for whole files fetched by key — images, exports, backups — and it is cheap, effectively unlimited, and not a filesystem. Block storage is a disk attached to one machine, which is what a database wants. A relational database is right when the data has structure and you need joins and transactions; a key-value store is right when you always look things up by one key and want it in single-digit milliseconds; a cache is right in front of either when the same expensive answer is requested repeatedly.

The engineering judgement is picking the least exciting thing that meets the requirement, because operational cost compounds. Serverless is genuinely excellent for spiky, short, event-driven work and genuinely painful for long-running jobs, heavy dependencies and anything sensitive to cold starts. A relational database handles vastly more load than most people assume, and 'we might need to scale' is not evidence that you do. Choose for the load you have with a known path to the load you expect, and write down why — the reasoning is what makes the decision reviewable later.

Syntax

# COMPUTE -- control vs operational burden
#   VM            you own the OS, patching, scaling      most control
#   Containers    you own the image; platform schedules
#   Serverless    you own only the code, pay per call    least control
#
#   spiky + short + event-driven      -> serverless
#   steady + long-running + tunable   -> containers or VM
#   cold start unacceptable           -> not serverless

# STORAGE -- decided by access pattern, not size
#   Object   whole files by key; cheap, huge, NOT a filesystem
#   Block    a disk for one machine; what a database wants
#   File     shared POSIX mount; convenient, slower, pricier

# DATA -- decided by the query you must answer
#   Relational   structure, joins, transactions            default
#   Key-value    always fetched by one key, single-digit ms
#   Cache        same expensive answer requested repeatedly
#   Warehouse    scans over billions of rows for analytics
#
# Anti-pattern: a warehouse used for single-row lookups
#   (built for scans; a per-row lookup is slow AND expensive)
# Anti-pattern: object storage used as a filesystem
#   (no partial write, no rename; every 'edit' rewrites the object)

Key points

  • Compute choice is a trade of control against operational burden. Serverless removes the most work and takes away the most tuning — right for spiky event work, wrong for long jobs and cold-start-sensitive paths.
  • Choose storage by access pattern. Object storage is files by key and not a filesystem; a warehouse is built for scans and is slow and expensive for single-row lookups.
  • Pick the least exciting option that meets the actual requirement, and record the reasoning. Anticipated scale is not measured scale.
The mistake that costs people the interview: Choosing a distributed or serverless architecture for load a single managed database would carry comfortably. You inherit cold starts, distributed debugging and a far harder local development story, all to solve a scale problem you have not yet measured.

Practice challenge

Choose the serviceAdvanced
Task

For each workload, name the category you would choose and give the one-line reason: (a) a webhook receiver that gets 20 requests an hour in bursts, (b) a nightly job that runs 40 minutes with large ML dependencies, (c) storing 8 TB of user-uploaded video, (d) looking up a single user profile by id in under 10 ms.

Expected answer
(a) Serverless function - spiky, short, event-driven, and you pay per invocation rather than for idle time
(b) Container or VM - long-running with heavy dependencies, which is exactly where serverless timeouts and cold starts hurt
(c) Object storage - whole files fetched by key, cheap per GB, effectively unlimited
(d) Key-value store - always fetched by one key, and single-digit millisecond lookups are what it is built for
Answer template
(a) ______ because ______
(b) ______ because ______
(c) ______ because ______
(d) ______ because ______
Show a hint
  1. Serverless is decided by shape of load, not by preference
  2. The last one is decided by the query, not by the amount of data

Open this exercise in the app →

Check yourself

1. Which workload suits serverless least?

  1. A spiky webhook receiver
  2. A long-running job with heavy dependencies and strict latency
  3. An occasional image thumbnailer
  4. A scheduled small cleanup
Show answer

B. A long-running job with heavy dependencies and strict latency

2. What is object storage not?

  1. Cheap
  2. A filesystem supporting partial writes and renames
  3. Durable
  4. Suited to large files
Show answer

B. A filesystem supporting partial writes and renames

3. Why is a data warehouse a poor choice for single-row lookups?

  1. It cannot store rows
  2. It is built for scans, so per-row lookups are slow and costly
  3. It has no indexes at all
  4. It is write-only
Show answer

B. It is built for scans, so per-row lookups are slow and costly

Back to the syllabus ↑

Monitoring, alerts and the 3am page

Job-ready Cloud · 18 min · 25 XP

Monitoring answers 'is it working', and the mistake is monitoring the machine instead of the promise. CPU at 90% may be perfectly healthy; checkout failing for 3% of customers is an incident even while every dashboard is green. So start from what you promise users — requests succeed, and they are fast enough — and express it as a service level objective with a number and a window, such as 99.9% of checkout requests succeeding over 30 days. That number is what makes 'is this bad enough to wake someone' answerable rather than a matter of taste.

The three signals underneath are metrics, logs and traces, and they answer different questions. Metrics are cheap numbers over time and tell you something is wrong. Logs are events with detail and tell you what happened to one request. Traces follow a single request across services and tell you where the time went, which is the only practical way to find the slow hop in a chain of six services. Teams that collect only metrics can see a problem and not locate it; teams that collect only logs pay a fortune and still cannot see a trend.

Alerting is where judgement shows. Every alert must be actionable and must page a human only when a human must act now — everything else is a ticket or a dashboard. Alert on symptoms rather than causes: 'error rate above 2% for five minutes' is one alert, while the twelve possible causes are twelve alerts that all fire together and bury the signal. And treat alert fatigue as an outage in slow motion, because an on-call engineer who has learned that most pages are noise will eventually miss the one that was not.

Syntax

# Monitor the promise, not the machine.
# SLO: 99.9% of checkout requests succeed over 30 days
#   -> error budget = 0.1% = ~43 minutes of failure per month
#   -> burning it fast is what deserves a page

# THE FOUR GOLDEN SIGNALS
#   Latency      how long requests take (use p95/p99, never the mean)
#   Traffic      how many requests
#   Errors       how many fail
#   Saturation   how full the system is (queue depth, connections)

# ALERT ON SYMPTOMS, NOT CAUSES
#  good: error rate > 2% for 5 minutes            (one alert)
#  bad:  cpu > 80%, memory > 90%, disk > 85%,     (twelve alerts,
#        threads > 200, queue > 100, ...           all firing at once)

# EVERY PAGE MUST PASS THIS TEST
#  1. Is a human needed RIGHT NOW?      no -> ticket, not a page
#  2. Is there a documented action?     no -> write the runbook first
#  3. Would I want to be woken for it?  no -> it is not a page

# Why p95, not the mean:
#   1,000 requests at 50ms + 10 requests at 30s
#   mean  = 347ms  -> looks fine
#   p99   = 30s    -> ten customers are staring at a spinner

Key points

  • Monitor what you promise users, not machine internals. CPU at 90% can be healthy; a 3% checkout failure rate is an incident while every host looks green.
  • Alert on symptoms, not causes. One symptom alert beats twelve cause alerts that all fire together and hide which one mattered.
  • Use p95 and p99, never the mean. An average is dragged down by the many fast requests and hides the tail that users actually experience.
The mistake that costs people the interview: Adding an alert after every incident without ever removing one. The board fills with pages that no longer mean anything, on-call learns to acknowledge without reading, and the alert that mattered arrives into a system that has trained everyone to ignore it.

Practice challenge

Fix a noisy alert setJob-ready
Task

On-call receives pages for CPU above 80%, memory above 90%, disk above 85% and thread count above 200. They fire together during every deploy and nobody acts on them. Meanwhile a 4% checkout failure went unnoticed for an hour. Write the alert that should exist, say what happens to the four, and give the three-question test every page should pass.

Expected answer
Should exist: checkout error rate above 2% for 5 minutes - a symptom alert on the user-facing promise
The four: demote to dashboards or tickets. They are causes, not symptoms, they fire together, and they trained on-call to ignore pages
Test: 1 is a human needed right now? 2 is there a documented action? 3 would I want to be woken for this?
Answer template
Alert that should exist: ______
The four existing alerts: ______
Three-question test: 1 ______ 2 ______ 3 ______
Show a hint
  1. Alert on the promise you make to users, not on machine internals
  2. Twelve cause alerts firing together hide which one mattered

Open this exercise in the app →

Check yourself

1. Why report p95 latency rather than the mean?

  1. It is easier to compute
  2. The mean is dragged down by fast requests and hides the slow tail users feel
  3. p95 is always lower
  4. Means cannot be graphed
Show answer

B. The mean is dragged down by fast requests and hides the slow tail users feel

2. Which is the better alert?

  1. CPU above 80%
  2. Checkout error rate above 2% for five minutes
  3. Memory above 90%
  4. Disk above 85%
Show answer

B. Checkout error rate above 2% for five minutes

3. An alert fires often and nobody can act on it. What should happen?

  1. Leave it, it may matter one day
  2. Remove it or downgrade it to a dashboard — noise trains people to ignore pages
  3. Raise its priority
  4. Route it to more people
Show answer

B. Remove it or downgrade it to a dashboard — noise trains people to ignore pages

Back to the syllabus ↑

Common questions

Do I need any background to start Cloud?

No. This track begins at its own beginning and assumes nothing, and the first lesson explains what the thing is before showing you any syntax.

How long does the Cloud track take?

About 125 minutes of reading across 8 lessons, plus the practice challenges and 24 multiple-choice questions, which is where the time actually goes.

Is it free?

Yes, and there is no account. Everything runs in your browser.

More: all 15 tracks · what employers actually ask for · the full syllabus

Keep reading

The STAR method, properly: how to build answers that hold up
A working guide to STAR interview answers: how to weight each part, how to build five stories that cover most…
Returning to work after a career break: rebuilding confidence and explaining the gap
How to present a career break on your CV, close the confidence gap, and answer interview questions about time…
Free AI interview coach
Free AI interview coach: voice mock interviews that talk back, role-specific questions, coding practice and…
Interview countdown, prediction & mock practice
Free interview prep: a live countdown to your interview date, then the 15 most common questions as flip-cards…