20 Things To Do Before Calling Yourself a Cloud Engineer

Twenty hands-on skills, and where to learn every one of them for free.

There's a difference between knowing what a load balancer is and having broken one. The title "cloud engineer" gets handed out for the first kind of knowledge and tested on the second.

These are 20 things you should have done, not just read about. Each gets a short note on why it matters and the best free places to learn it.

All of it fits inside a free tier:

Pick one cloud. The concepts transfer; the console clicks don't.

Part 1: The Network Layer (1–5)

Most "cloud" problems are network problems wearing a costume. Start here.

1. Understand HTTP Traffic

Almost everything you deploy speaks HTTP. If you can't read a status code you can't read a load balancer log: a 502 means your backend died, a 504 means it's alive but too slow, and a 401 versus a 403 tells you whether it's an auth problem or a permissions problem.

Free courses

Blogs / docs

YouTube videos

Do this: Open your browser dev tools, load any site, and read the network tab. Find one request, note its method, status code, and three headers. Then reproduce it with curl -v.

2. Study VPC Architecture

Everything you deploy lives inside a VPC. If you can't draw public subnet, private subnet, route table, internet gateway, NAT gateway and security group from memory, you can't design anything real, and you can't debug why your private database suddenly lost internet access.

Free courses

Blogs / docs

YouTube videos

Do this: Build a VPC by hand, no wizard. Two subnets across two availability zones, one public, one private. Put an EC2 instance in each. SSH into the public one, then reach the private one from it.

3. Configure DNS Routing

An alarming number of production incidents start at DNS. You need A records, CNAMEs and ALIAS records, what TTL does to how fast a change propagates, and how weighted, latency-based and failover policies shift traffic between regions.

Free courses

Blogs / docs

YouTube videos

Do this: Buy a cheap domain, point it at a load balancer, then set up a weighted policy that splits traffic 90/10 between two targets. Watch the split happen. Then change a TTL and time how long propagation actually takes.

4. Test Load Balancer Types

Picking the wrong load balancer is a quiet, expensive mistake. ALB works at Layer 7 and routes on paths, hosts and headers; NLB works at Layer 4 with very low latency and static IPs; Gateway Load Balancer exists for putting security appliances inline. Knowing which to reach for is both an interview question and a production decision.

Free courses

Blogs / docs

YouTube videos

Do this: Put an ALB in front of two instances serving different text. Refresh until you see both. Then kill one and watch the health check pull it out of rotation.

5. Identify Network Traffic

Security groups are stateful and only allow. NACLs are stateless and can explicitly deny. Mix them up and you'll spend an afternoon on a connection that hangs instead of failing. You should be able to tell "never arrived" from "arrived and was rejected" from "arrived, was accepted, and the app crashed."

Free courses

Blogs / docs

YouTube videos

Do this: Deliberately break connectivity three different ways — wrong security group, wrong NACL, wrong route table — and diagnose each one from the symptoms alone before checking your notes.

Part 2: Core Cloud Primitives (6–8)

Identity, storage, and compute. Every architecture is some arrangement of these three.

6. Set Up an IAM Policy

IAM is the actual security perimeter of your account, and over-permissioned roles are the most common cause of cloud breaches. Use roles rather than long-lived keys for anything machine-to-machine, remember that an explicit Deny always beats an Allow, and build permissions up from nothing instead of trimming down from *.

Free courses

Blogs / docs

YouTube videos

Do this: Write a policy from scratch that lets a role read from exactly one S3 bucket prefix and nothing else. Test it. Then use Access Analyzer to check whether it's tighter than what you'd have written by instinct.

7. Compare Storage Tiers

Storage is where cloud bills quietly balloon. Object, block and file storage are not interchangeable, and knowing when a lifecycle policy should shift old logs into a cheaper access tier pays for itself in the first month.

Free courses

Blogs / docs

YouTube videos

Do this: Upload the same file to standard, infrequent access, and an archive tier. Write down the storage cost and the retrieval cost and time for each. Then set a lifecycle rule that transitions objects automatically after 30 days.

8. Distinguish Compute Workloads

VMs, containers and functions solve different problems: a whole machine you pay for whether it's busy or not, a packaged process that starts in seconds and packs densely, or code that costs nothing when idle but has cold starts and execution limits. Choosing correctly is most of what "architecture" means at the junior level.

Free courses

Blogs / docs

YouTube videos

Do this: Deploy the same trivial "hello world" API three ways: on a VM, in a container, and as a function. Time each deployment. Compare the cost at zero traffic and at constant traffic.

Part 3: Shipping Things (9–12)

Now you can put workloads in the cloud. Next: put them there repeatably.

9. Deploy Containers in the Cloud

Containers are the default unit of deployment now. You should be able to write a Dockerfile, build a multi-stage image, push it to a registry, and run it on a managed service without hand-holding.

Free courses

Blogs / docs

YouTube videos

Do this: Containerize an app, push the image to a registry, and run it behind a load balancer on a managed container service. Then scale it to three replicas and confirm traffic spreads across all three.

10. Automate with Infrastructure as Code

Clicking through a console doesn't scale, isn't reviewable, and can't be reproduced six months later. Once infrastructure lives in code, every change becomes a pull request with an author, a diff and a rollback path.

Free courses

Blogs / docs

YouTube videos

Build this: Terraform with AWS — Real-Time Project provisions a VPC, subnets, an internet gateway, app instances across two zones, and a load balancer entirely from code. Companion repo: iam-veeramalla/terraform-zero-to-hero. This is item 2 and item 4 on this list, done properly.

11. Design One CI/CD Pipeline

A pipeline turns git push into a deployed application with no human in the middle: build, test, scan, package, deploy. Build one end to end and "how does code get to production here?" stops being a mystery at every job you take afterwards.

Free courses

Blogs / docs

YouTube videos

Build this: Docker CI/CD Project — a push triggers the pipeline, the image gets built and pushed, and the container ships. Do it once and you'll never be intimidated by a pipeline config again.

12. Implement Serverless Functions

Serverless is the clearest demonstration of what the cloud actually sells you: capacity you don't manage. A function plus an API gateway costs nothing until someone calls it, and the trade-offs (cold starts, execution limits, harder local testing) are what separate people who use serverless well from people who use it for everything.

Free courses

Blogs / docs

YouTube videos

Do this: Ship a function behind an API gateway, then deliberately trigger a cold start and measure it. Then set a concurrency limit and watch what happens when you exceed it.

Part 4: Running Things (13–17)

Deploying is the easy half. Everything below is what the job actually is.

13. Set Up Logging

When something breaks at 2am, logs are the only evidence you have. They need to be centralized, structured as JSON rather than free text, and retained long enough to be useful without costing more than the service producing them.

Free courses

Blogs / docs

YouTube videos

Do this: Ship application logs to a central log group, then write a query that finds every 5xx in the last hour grouped by endpoint. Set a retention policy so it doesn't run forever.

14. Configure Monitoring Alerts

An alert that fires constantly trains everyone to ignore alerts, which is worse than having none. Pick metrics that reflect user pain (error rate, latency, saturation), set thresholds that mean something, and route the page to someone who can act on it.

Free courses

Blogs / docs

YouTube videos

Do this: Create an alarm on CPU or error rate that notifies you by email or Slack. Then load-test the service until it actually fires. An alarm you've never seen fire is not a working alarm.

15. Inspect Network Flow Logs

Flow logs record the metadata of every connection in and out of your network interfaces: source, destination, ports, protocol, bytes, and whether traffic was accepted or rejected. When a connection is silently failing, a REJECT record tells you it's a security group or NACL problem in about thirty seconds.

Free courses

Blogs / docs

YouTube videos

Do this: Turn on flow logs for a VPC, deliberately block a connection with a security group rule, then find the REJECT record for it in the logs. Filter for REJECT only to cut the noise.

16. Track Auto Scaling Systems

Auto scaling is the reason the cloud beats a rack of servers, and it's also where beginners get burned. Launch templates, min/desired/max capacity, target tracking versus step scaling, cooldowns, and health checks aggressive enough to kill and replace healthy instances in a loop.

Free courses

Blogs / docs

YouTube videos

Do this: Build an auto scaling group behind a load balancer, then generate enough load to trigger a scale-out. Watch it happen. Then stop the load and time how long scale-in takes.

17. Upgrade Running Workloads

Anyone can deploy to an empty environment. Deploying to one that's currently serving traffic, without dropping a request, is the actual skill. Rolling replaces gradually, blue-green flips all at once and gives you instant rollback, canary sends a slice and watches the metrics before committing.

Free courses

Blogs / docs

YouTube videos

Do this: Deploy v1, put constant traffic against it with a simple load generator, then roll out v2 without losing a single request. Then roll back to v1 the same way.

Part 5: Not Getting Fired (18–20)

The unglamorous items. These are the ones that come up in your first month on a real team.

18. Restore Deleted Resources

Backups you've never restored aren't backups, they're a feeling. Know which deletes are recoverable and which are permanent, and how versioning, deletion protection and MFA delete change that answer. Doing a restore once, calmly, in a test account is enormously better than doing it for the first time during an incident.

Free courses

Blogs / docs

YouTube videos

Do this: Enable versioning on a bucket, delete an object, restore it. Snapshot a volume, delete the volume, rebuild it from the snapshot. Write down how long each took — that number is your recovery time objective.

19. Implement Resource Tagging

Tagging sounds like paperwork until you're staring at a $40,000 bill and can't tell which team caused it. Owner, environment, cost centre, project: it's what makes cost allocation, automated cleanup and attribute-based access possible at all, and nobody does it until it's painful to retrofit.

Free courses

Blogs / docs

YouTube videos

Do this: Define a four-tag standard, apply it to everything in your account through Terraform (not by hand), then activate cost allocation tags and see your bill broken down by them.

20. Configure Budget Alerts

The most common horror story in cloud engineering is the surprise bill: a forgotten NAT gateway, a runaway scaling group, a public bucket getting hammered. Set a monthly threshold with alerts at 50%, 80% and 100% of forecast, and let anomaly detection catch the spikes a fixed threshold misses. Do it on day one of any new account.

Free courses

Blogs / docs

YouTube videos

Do this: Set a $10 budget on your practice account with alerts at 50% and 80%. Enable anomaly detection. Now you can experiment freely without lying awake about it.

The Capstone

Once you've done all twenty individually, do them together. One project, end to end:

A finished project you can walk someone through beats a certificate you crammed for. If a cert keeps you disciplined, take one, but build the thing either way.

Crash Course Quick List

Every video in one place, in case you just want the links:

How To Work Through This

Pick one item, do the "Do this" box, move on. One a week gets you through the list in five months.

Two rules: set up item 20 before anything else, and tear down what you build the moment you're done with it. The NAT gateway you forgot about is the most expensive lesson here.

All links are free courses, crash courses, official docs, or free-to-follow projects. Free tiers, service names, and video availability change over time, so check the pricing page before you deploy anything and search the title if a link has moved.