Portfolio Projects for Cloud Engineer

Your cloud certifications are not getting you interviews, and you are starting to wonder if the problem is the projects on your resume. Reviewers see dozens of "deployed a static site on S3" bullets every week. Those projects prove you followed a tutorial, not that you can own infrastructure.

Three well-built projects beat a wall of certificates. Here is what to build, how to write it up, and how to talk about it.

What reviewers actually look for#

Hiring managers and senior engineers reviewing cloud portfolios care about a short list of things. They want evidence you made real decisions, not just ran commands in order. They want to see failure handled, cost considered, and security taken seriously.

The single biggest signal is trade-off reasoning. Why Kubernetes instead of ECS? Why Terraform modules and not a single giant file? If your README explains the choice and what you gave up, you move from "tutorial follower" to "engineer."

They also check whether the project is yours. Forked repos with a changed name get closed in seconds. Original architecture, original naming, original problems. That is the bar.

Project 1: a multi-environment infrastructure pipeline#

Build infrastructure as code that deploys the same stack to dev, staging, and prod with different configurations. Terraform or OpenTofu with a remote state backend, a CI pipeline that runs plan on pull requests and apply on merge, and separate state per environment.

Add guardrails. OPA or Checkov policies in CI that block a public S3 bucket or an unencrypted database. Slack or email notification on apply failure. A documented rollback path.

This project proves you understand environments, state management, drift, and pipeline design. Those are daily realities in any cloud role.

Worked example: the resume bullet

Weak:

Used Terraform to deploy AWS resources in multiple environments.

Strong:

Built Terraform pipeline deploying 3 environments (dev, staging, prod) from one codebase with per-environment state, PR-time plan previews, and Checkov policy gates that blocked 4 misconfigurations during testing.

The second bullet names the mechanism, the scale, and one concrete outcome. Do not invent numbers you cannot defend. If you blocked nothing during testing, say the policy runs and what it checks.

Project 2: an observable, self-healing application platform#

Deploy a small real application, not a hello-world container. A URL shortener, a rate-limited API, a log aggregation service. Something with state, concurrency, and failure modes.

Run it on ECS Fargate, EKS, or a managed container service. Put it behind a load balancer with health checks. Wire up CloudWatch or Prometheus metrics, structured logs, and a dashboard showing latency, error rate, and saturation. Configure autoscaling on a metric that matters. Add an alert that fires on error rate and one that fires on cost anomaly.

Then break it on purpose. Kill a task. Inject latency. Document what the system did and what you fixed.

This project proves you can operate what you deploy. Most junior candidates can deploy. Few can explain what happens at 3am when it fails.

Project 3: a cost and security audit tool#

Write a tool that scans a cloud account and reports waste and risk. It can be Python or Go running as a Lambda or a scheduled container. Have it find unattached volumes, old snapshots, idle load balancers, over-permissive security groups, IAM users without MFA, and resources missing required tags.

Output a report to Slack, email, or a simple dashboard. Add a "what would this save" line using current pricing you pull or hardcode with a date stamp. Include an allowlist so intentional exceptions do not spam the report.

This project proves you think like an owner. Cost and security are not side topics. They are part of the job.

How to present it on GitHub#

Structure matters more than stars. Reviewers spend 60 to 90 seconds on a repo before deciding to dig in or close it.

• A README that opens with one sentence on what the project does and why you built it
• An architecture diagram, drawn in Mermaid, Excalidraw, or draw.io, exported as PNG
• A "Decisions and trade-offs" section with at least three choices you made and the alternative you rejected
• A "What broke and how I fixed it" section with real incidents from your build
• Exact setup steps a stranger can follow, including required tools and versions
• Cost notes: roughly what it costs per month to run and how to tear it down
• Screenshots of dashboards, alerts, or reports the project produces
• A LICENSE file and a .gitignore that actually matches the stack

Keep the repo clean. No committed credentials, no 200MB state files, no dead branches. Run a secret scanner before you push.

How to list it on your resume#

Put projects in their own section if you are early career, or under a "Selected projects" line inside experience if you have relevant work history. Three projects is enough. Two excellent ones beat five shallow ones.

Use the same bullet structure every time: what you built, the mechanism, one specific outcome. Keep each bullet to one or two lines. Link the GitHub repo and, if you have one, a live demo or a recorded walkthrough.

Before you finalize, run your resume through a free ATS checker to catch formatting that parsers drop, and use a job description decoder to see which skills in the posting your projects actually address. Then browse live openings on our jobs page to see what real cloud roles ask for right now.

Mistakes that make projects look like tutorials#

• The README is a copy of the tutorial's README with your name swapped in
• Everything is named my-project, demo, or test
• There is no architecture diagram at all
• The only "outcome" is "it worked"
• All resources are in one region, one environment, one flat file
• No mention of cost, monitoring, or security anywhere
• The git history is one giant "initial commit" pushed the same day
• The project uses a service that the tutorial used but you cannot explain

If you cannot explain a component in your own words, remove it or learn it. Interviewers will ask.

How to talk about the projects in interviews#

Have a two-minute version and a ten-minute version ready. The two-minute version is: what it does, the architecture in one breath, one decision you made, one thing that broke. The ten-minute version goes deeper on trade-offs and failure.

Expect questions like "why this design," "what would you change with more time," "what happens if the database goes down," and "what did this cost." Prepare honest answers for each. "I would move to multi-AZ next because right now it is single-AZ and that is a real limitation" is a good answer. Pretending the design is perfect is not.

Sample answer: "Tell me about a cloud project you are proud of"

I built a Terraform pipeline that deploys the same stack to dev, staging, and prod with separate state files. PRs run a plan and post the diff as a comment, merges apply to the target environment. I added Checkov policy checks after I accidentally left a test bucket public during development, so now that class of mistake gets blocked before apply. The thing I would change next is adding drift detection on a schedule, because right now drift only shows up when someone runs a plan manually.

It names the mechanism, admits a real mistake, and shows a next step. That lands well.

Free tools#

• jobrise.io/en/free-ats-checker/
• jobrise.io/en/free-jd-decoder/
• jobrise.io/en/jobs/
• jobrise.io/en/blog/

FAQ#

How many projects should a cloud engineer portfolio have?

Three solid projects is the sweet spot. Two is fine if they are deep and documented well. Five shallow tutorial clones will hurt you more than help you.

Should I deploy everything on AWS?

No. Pick one primary provider and go deep, then mention exposure to others if you have it. Depth in one cloud beats surface-level checkboxes across three.

Do I need to keep the projects running and paying for them?

Not always. A recorded walkthrough plus a documented teardown is acceptable, and often smarter. Just say so in the README and keep the infrastructure code reproducible.

Are certifications worth anything if I have good projects?

Yes, they still clear HR filters and some job postings require them. Build the projects first if you have to choose. Certificates get you read, projects get you hired.

What if my project is based on a tutorial?

Rebuild it with different constraints, different services, or a different problem. Then document the decisions you made that the tutorial did not cover. If you cannot do that, build something else.