Intermediate Cloud Projects: Portfolio Builds for Growing Engineers

What “intermediate” actually means in a portfolio context

An intermediate project does not have to be large. The step up from beginner is not about size — it is about complexity of thinking. Specifically:

• Multiple services that interact with each other (not just one Lambda talking to one database)
• Infrastructure provisioned entirely as code — no manual console clicks
• At least one non-obvious architectural decision that you can explain and defend
• Evidence of thinking about what happens when things fail

An intermediate project built with these characteristics will outperform many “advanced” projects that are large but poorly documented and clearly not thought through.

Start by upgrading what you already have

Before building anything new, consider whether an existing beginner project can be upgraded. This is often faster, produces better results, and shows evolution in your thinking — which is itself impressive.

Useful upgrades for existing projects:

• Add a proper CI/CD pipeline to a project that was deployed manually
• Add monitoring and alerting to a project that has none
• Refactor flat Terraform into reusable modules
• Add least-privilege IAM roles to a project using overly broad permissions
• Add remote Terraform state with locking if it currently uses local state
• Write a complete README documenting the architecture decisions

One well-upgraded project can be more impressive than two new shallow ones.

Project 1: Multi-tier application with Terraform modules

What to build

Provision a three-tier application environment — networking, compute, and data tiers — using Terraform with proper module organisation. The modules should be reusable across environments. Deploy separate dev and prod workspaces using the same modules with different variable values.

What this demonstrates

Real Terraform usage at companies means modules, workspace or directory separation, remote state in S3 or GCS with DynamoDB or Cloud Storage locking, and variable files per environment. A flat main.tf with everything in one file signals a beginner. Module organisation signals someone who has read real-world Terraform codebases.

Decisions to document

Document how you structured your modules — one module per service or one module per environment tier? Both are legitimate choices with different trade-offs. Explain why you chose remote state over local state and what the locking mechanism prevents.

Project 2: Containerised application on Kubernetes with proper configuration

What to build

Deploy a multi-container application to Kubernetes — at minimum a web service and an API — with Kubernetes Deployments, Services, ConfigMaps, Secrets (using a real secret store integration where possible), and an Ingress resource. Add resource requests and limits, readiness probes, and liveness probes to every container.

What this demonstrates

Resource limits are non-negotiable in production Kubernetes — without them, one misbehaving pod can exhaust a node. Readiness and liveness probes are how Kubernetes decides whether to send traffic to a pod and whether to restart it. Both are expected knowledge for Kubernetes roles. Most beginner Kubernetes projects skip them entirely.

Decisions to document

Explain the resource request and limit values you chose — why those numbers? Explain what condition causes the liveness probe to fail and what Kubernetes does in response. Explain why you separated the services into different Deployments rather than one.

Project 3: Full observability stack

What to build

Deploy Prometheus and Grafana (either self-hosted or using managed offerings) to monitor an existing application. Create dashboards covering request rate, error rate, and latency (the RED method). Define at least three alerting rules with realistic thresholds. Document the runbook action for each alert — what a human should do when it fires.

What this demonstrates

Observability thinking is rare in junior portfolios. A project that shows you understand why the RED method (Rate, Errors, Duration) exists and can write a meaningful alerting rule with a documented runbook will be noticed. This project is directly relevant to SRE and senior cloud engineer roles.

Decisions to document

Explain the threshold you set for each alert and why. “Alert when error rate exceeds 5% for 5 minutes” should come with an explanation: why 5%? Why 5 minutes and not 1 minute? What does the alert mean about the user experience when it fires?

Project 4: Secrets and configuration management

What to build

Build an application that pulls all of its configuration and secrets from a managed secret store (AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault). The application should use IAM roles or service accounts to authenticate to the secret store — no static credentials. Include a CI/CD pipeline that references secrets via environment injection, not hardcoded values.

What this demonstrates

Credentials management is consistently one of the most common cloud security failures in real organisations. An engineer who understands the pattern — application identity via IAM role, secrets in managed store, no hardcoded values anywhere in the codebase or pipeline — is demonstrating production-grade security thinking even in a portfolio project.

Decisions to document

Explain why you chose a managed secret store over environment variables. Explain how the application authenticates to the secret store without a credential (the key question: who authenticates the authenticator?). This is the IAM identity chain — document it.

Project 5: Cost-optimised architecture with spot or preemptible instances

What to build

Deploy a batch processing or compute-heavy workload using AWS Spot Instances or GCP Preemptible VMs, combined with a mechanism to handle interruptions gracefully — checkpointing state, draining jobs, or retrying from the last checkpoint. Include a cost comparison between on-demand and spot pricing in your README.

What this demonstrates

Cost awareness is a real professional skill. Cloud engineers who can design for cost without sacrificing reliability are valued. Spot and preemptible instance usage is a common interview topic and a common real-world pattern for batch workloads, CI build agents, and ML training jobs.

Decisions to document

Explain what happens when a spot instance is interrupted and how your architecture handles it. What data could be lost? What is the worst-case scenario for a job in flight? Showing you have thought through failure modes is more impressive than showing the happy path.

Project 6: End-to-end deployment pipeline with rollback

What to build

Build a full deployment pipeline for an existing application that covers: automated tests, Docker build and push, deployment to a staging environment, a manual or automated approval gate, and deployment to production with either blue/green switching or a canary rollout. Include an automated rollback that triggers if the post-deployment health check fails.

What this demonstrates

Most beginner pipelines just push to production. An intermediate pipeline shows you understand the difference between deploying and safely deploying. Approval gates, staging environments, and rollback mechanisms are standard at any serious company and are frequently discussed in DevOps interviews.

Decisions to document

Explain how the rollback is triggered — is it automatic based on a metric threshold, or is it a manual step? Explain the trade-off between blue/green (full traffic switch, more resource cost) and canary (gradual shift, more complexity). Explain what the approval gate is checking and who should be able to approve it in a real organisation.

What comes after intermediate projects

At the intermediate level, two or three well-executed projects are enough to be competitive for junior and mid-level cloud engineer, DevOps, and SRE roles. The goal is not to complete all six projects above — it is to have enough evidence across different skill areas to demonstrate that you can work on real systems.

If you are targeting senior roles or want to go deeper, the advanced cloud projects guide covers production-grade multi-region and platform engineering builds.

For help presenting these projects well, see how to write a cloud portfolio case study and cloud portfolio GitHub repository structure.