Beginner Cloud Projects: First Builds to Start Your Portfolio

What you need before you start

These projects are designed for people who have basic cloud familiarity — you have poked around the console, you understand what a virtual machine is, and you have seen how IAM policies work in principle. You do not need deep expertise. You do need:

• A free-tier account on AWS, GCP, or Azure (all three have genuinely free tiers for beginners)
• A GitHub account and basic Git skills — commits, branches, pushing to remote
• Willingness to read documentation when things do not work — this is a core cloud engineering skill
• A budget ceiling set: configure billing alerts before you start so you never get a surprise invoice

You do not need to have finished a certification before building projects. Building projects and studying for certifications in parallel is often faster than doing one then the other.

Project 1: Static website with HTTPS and a CDN

What to build

Host a static website using S3 + CloudFront (AWS), Cloud Storage + Cloud CDN (GCP), or Azure Blob Storage + Azure CDN. Configure a custom domain and HTTPS. The website content can be anything — a personal page, a fake product page, a simple landing page.

What you will actually learn

• How object storage works and how bucket permissions affect public access
• What a CDN does and why it matters for latency
• How TLS certificates are provisioned and attached to distributions
• DNS record types (A, CNAME, ALIAS) and how domains connect to cloud services

What to document in your README

Explain why you chose CloudFront over direct S3 access. Explain how you restricted the S3 bucket so it is only accessible through the CDN, not directly. This decision — using an Origin Access Control — is where most beginners skip the detail.

Common mistakes to avoid

Do not leave the S3 bucket publicly accessible with “Block Public Access” turned off. This is a security misconfiguration that hiring managers will notice. Route traffic through the CDN origin properly. Also, do not deploy this project and immediately move on — write the README first.

Project 2: Serverless API with a database

What to build

Build a simple REST API using AWS Lambda + API Gateway + DynamoDB, or GCP Cloud Functions + Cloud Run + Firestore. The API should support at least two operations — for example, creating and reading records. A simple notes API, a URL shortener, or a task tracker all work well.

What you will actually learn

• How serverless functions handle HTTP requests (event parsing, response formatting)
• How IAM roles for Lambda or Cloud Functions restrict what the function can access
• How a NoSQL database differs from a relational one in terms of data modelling
• How API Gateway routing works and how to configure it without using the console manually

What to document in your README

Explain the IAM permissions you gave the Lambda execution role and why you chose those specific permissions. Explain the DynamoDB table’s partition key design. Most beginners skip both, and both are genuinely interesting to a technical interviewer.

Common mistakes to avoid

Do not give your Lambda function a role with full DynamoDB access. Write a policy that allows only the specific actions (GetItem, PutItem, etc.) on the specific table ARN. This is basic least-privilege and you will be asked about it in interviews.

Do not hardcode any secrets, API keys, or credentials in the function code or in the repository. Use environment variables pulled from Secrets Manager or SSM Parameter Store.

Project 3: Basic CI/CD pipeline

What to build

Create a GitHub repository with a small application — a Python Flask app, a Node.js Express API, or a simple Go HTTP server all work. Set up a GitHub Actions workflow that runs on every pull request and does three things: lints the code, runs tests, and builds a Docker image. On merge to main, the workflow should push the image to a container registry (ECR, GCR, or Docker Hub).

What you will actually learn

• How YAML-based CI pipeline configuration works
• How to build and tag Docker images in a pipeline
• How to authenticate from GitHub Actions to a cloud provider securely (using OIDC, not static access keys)
• How to structure a repository so the pipeline is easy to read and extend

What to document in your README

Explain the pipeline stages and why you ordered them that way (lint before test, test before build — why?). Explain how the authentication to the container registry works and why you used OIDC instead of long-lived credentials.

Common mistakes to avoid

Do not store AWS access keys or cloud credentials as GitHub secrets if you can use OIDC (GitHub’s federated identity provider) instead. OIDC is the current best practice and shows you are aware of it.

Do not build a pipeline that only runs on main. A pipeline that only validates code after it is already merged is not a real CI pipeline.

Project 4: Virtual network with two tiers

What to build

Design and provision a VPC (AWS) or VPC network (GCP) with at least two subnets: one public and one private. Launch a web server in the public subnet and a database in the private subnet. The web server should be reachable from the internet. The database should not be directly reachable from the internet — only from the web server’s security group. Use Terraform to provision everything.

What you will actually learn

• How public and private subnets work and what routing decisions make the difference
• How security groups and network ACLs (or VPC firewall rules in GCP) control traffic
• How a NAT gateway allows private instances to reach the internet outbound without being reachable inbound
• Basic Terraform structure: providers, resources, outputs, and variables

What to document in your README

Include a simple architecture diagram — even a text diagram using ASCII or a drawn image. Explain what would happen if you put the database in the public subnet. Explain why the NAT gateway exists and what traffic it allows.

Common mistakes to avoid

Do not use a single public subnet for everything. The point of this project is the segmentation. Do not hardcode the region, AMI ID, or IP ranges directly in the Terraform files — use variables so the configuration is reusable.

Project 5: Simple monitoring setup

What to build

Deploy a small application (or use one of your previous projects) and configure basic monitoring: a CPU or request latency metric, a dashboard with at least two panels, and one alerting rule that would fire on a realistic condition. Use CloudWatch (AWS), Cloud Monitoring (GCP), or deploy a self-hosted Prometheus and Grafana stack.

What you will actually learn

• How cloud-native monitoring collects and stores metrics
• How to write a metric filter or alert condition
• How to think about what “working normally” means for a system before you can define when it is broken
• How dashboards are structured and what makes them useful

What to document in your README

Explain what the alert would fire on and what action you would expect a human to take in response. This question — “alert fires, what now?” — is what separates a working alert from a useful one. Showing you thought about this is distinctive.

Common mistakes to avoid

Do not create alerts that would fire constantly in normal operation (alert fatigue) or never fire until the system has already been down for an hour. Show that you thought about the threshold.

What to do when a project is finished

A project is not portfolio-ready when the code works. It is portfolio-ready when:

• The README explains what the project is, what decisions were made, and how to deploy it
• There are no credentials, secrets, or access keys anywhere in the repository history
• The infrastructure is provisioned with code (Terraform, CloudFormation, or Deployment Manager) — not manually clicked through a console
• The repository is pinned on your GitHub profile

For detailed guidance on structuring your repository and writing strong READMEs, see cloud portfolio GitHub repository structure. When you are ready to describe your projects in job applications, how to write a cloud portfolio case study covers what to include.

Once you have two or three of these beginner projects completed, the intermediate cloud projects guide will help you decide what to build next.