Cloud labs alongside the BYU-Idaho Cloud Computing track

BYU-Idaho’s Cloud Computing track gives me the shape of the field. The labs I run alongside the coursework give me fluency. Fluency across IaC, edge, identity, and networking is only earned by building, and reading and video tutorials are not the same thing.

The rule I set for the labs: one production-shape lab per concept, saved as a template so the next lab starts from a working baseline instead of a blank editor.

What “production-shape” means to me

Production-shape does not mean production-grade. It means the lab looks like the thing I would actually deploy if the ask were real. That rules out most of the guided tutorials I have run - not because they are wrong, but because they teach you to click through a console and end up with a screenshot, not a repo you can git clone into a new account and have something running in ten minutes.

The concrete shape:

• Full VPC with private subnets, a NAT for outbound, and a bastion pattern for admin. Not just “spin up an EC2 in the default VPC.”
• A serverless static site with a function backend and a real domain. Not just “deploy to S3 and open the public URL.”
• An Ansible bootstrap that takes a fresh box from a bare OS to a hardened, monitored, backed-up node. Not just “install nginx.”

Each of those lives in its own repo, gitignored secrets, README that assumes zero prior context, and a Makefile or task file for the standard operations. When the next concept comes along, I start from the closest existing template.

What the labs have actually taught me

• VPCs are not the interesting part. The interesting part is what you do when the pattern breaks - a subnet running out of IPs, a security-group cycle, an interface endpoint doing something surprising. The labs are how I learn the pattern well enough to notice when it breaks.
• Serverless is a build-time question, not a runtime question. The runtime behavior of a Pages Function or Lambda is easy. Setting up the build pipeline so it actually redeploys cleanly on a real repo push, with sane preview environments and no exposed secrets, is where the work lives.
• Ansible is worth learning even for solo homelab work. The point is not orchestration at scale. The point is that “here is how the box got the way it is” becomes a diff-able file instead of a memory.

Why templates

The best lab is the one I did not have to redo. Every template shortens the gap between “I want to try X” and “X is running.” That gap is where most side projects die.

The Cloud Architect direction the whole thing is aimed at will not come from another certification. It will come from having built enough of these that when an interviewer asks “have you designed for X,” I can point at a real diff.