# Cloud Engineering Portfolio: Five Projects Worth Building - Link: https://cloudcareerhq.com/cloud-engineering-portfolio-projects/ - Published: 2026-11-06T16:03:19-08:00 - Author: RobLuv **CCHQ ARTICLE GUIDE**   /   CLOUD CAREERS ### Practical learning, clear decisions, real-world context An easy-to-navigate field guide with key takeaways, applied checks, FAQs, and official references. Approximately 7 minutes of reading. A cloud engineering portfolio should demonstrate that you can design, deploy, secure, operate, and explain a workload—not simply that you followed a tutorial. The strongest projects give an interviewer evidence of practical decisions: why a network path exists, how an application authenticates, what a pipeline can change, how costs are controlled, and how you responded to a failure. Five well-documented projects can cover these skills without creating an expensive miniature enterprise. This guide proposes a progression from basic content delivery to private application architecture, CI/CD federation, containers, and security investigation. Each project includes an objective, skills to demonstrate, verification ideas, and a cleanup plan. These are project blueprints, not claims that the resources were deployed or tested. ### At a glance The main topics you’ll work through: * What makes a portfolio project credible * Project one: secure static site delivery * Project two: private API and database boundaries * Project three: Terraform with GitHub Actions OIDC ### In this guide * [What makes a portfolio project credible](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#what-makes-a-portfolio-project-credible) * [Project one: secure static site delivery](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#project-one-secure-static-site-delivery) * [Project two: private API and database boundaries](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#project-two-private-api-and-database-boundaries) * [Project three: Terraform with GitHub Actions OIDC](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#project-three-terraform-with-github-actions-oidc) * [Project four: containerized application with health checks](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#project-four-containerized-application-with-health-check) * [Project five: cloud security investigation](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#project-five-cloud-security-investigation) * [A consistent README template for all five](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#a-consistent-readme-template-for-all-five) * [How to present the portfolio in interviews](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#how-to-present-the-portfolio-in-interviews) * [Frequently asked questions](https://cloudcareerhq.com/cloud-engineering-portfolio-projects/#frequently-asked-questions) **01 / KEY CONCEPT** ## What makes a portfolio project credible **KEY TAKEAWAY** Choose a clear problem and define the constraints before implementing it. List who uses the system, what data it processes, how requests arrive, what must remain private, and what the expected cost drivers are. Then create a diagram, a version-controlled repository, a README, and a short architectural decision record. Explain how to deploy and destroy the lab without exposing credentials. A screenshot of a green dashboard has little value without an explanation of the identity and operational boundaries behind it. Treat testing evidence carefully. State what you actually ran, which region and environment were used, the date or versions where relevant, and what result you observed. Never invent a console screenshot or claim that a failure scenario worked if you did not perform it. If a design remains conceptual, label it as a design. An honest troubleshooting note can improve a portfolio by showing how you handle ambiguity and corrective action. Preserve only sanitized artifacts, and remove account IDs, tokens, and sensitive resource information from public documentation. **02 / PRACTICAL APPLICATION** ## Project one: secure static site delivery **KEY TAKEAWAY** Build a small documentation or personal site using a deliberate public content path while keeping the underlying storage private where the architecture supports it. Learn DNS, TLS, object storage, caching or content delivery, and least-privilege deployment identities. The interesting engineering question is not how to upload HTML. It is why the public can fetch specific content without gaining administrative permissions on the origin storage or the publishing system. Document the request path from a browser to the content source, including TLS termination and caching behavior. Test the expected public page and a storage action that should not be available to an anonymous user. Record cache invalidation and version-release behavior if you use a CDN. Add a budget alert and list any continuing charges from custom domains, transfer, or distribution features. Include a teardown covering DNS, distribution, storage, logs, and any retained assets. This project demonstrates foundational cloud architecture without requiring servers. **03 / KEY CONCEPT** ## Project two: private API and database boundaries **KEY TAKEAWAY** Deploy a minimal API that receives an authenticated request and queries a private database or data service. Keep the data store off unnecessary public endpoints. Define a distinct application identity with only the required data permissions and place secrets in an approved location. Document networking routes, security groups or equivalent controls, and how the API authenticates users. A simple one-table application can be enough; sophisticated business logic is less important than clear trust boundaries. Verify that an authorized request works and an unauthorized request fails. Try a harmless direct connection to the database from an untrusted lab context and confirm the expected restriction. Record how application errors are logged without storing private records or passwords. Explain the backup and restore assumptions and the limitations of the lab. Check ongoing costs, especially managed database runtime, networking, and backups. Destroy the environment after documenting the results. This project is useful for discussing application security, network segmentation, and troubleshooting. **04 / PRACTICAL APPLICATION** ## Project three: Terraform with GitHub Actions OIDC **KEY TAKEAWAY** Use Terraform to create a small approved set of resources and store its state in a protected backend. Add a GitHub Actions workflow that formats, validates, and plans a change, with approval before an apply. Authenticate to AWS through OIDC and a restricted IAM role instead of long-lived access keys. The security story includes the role trust policy, resource permissions, protected branches or environments, state locking, and who can approve deployments. Show a pull request containing a change, the resulting plan, the approval process, and the observed deployed configuration. Test a harmless action that the pipeline is allowed to perform and one that it should not be able to perform. Explain why the build job and deployment role are separated. Document how drift is handled and how an unsuccessful deployment is investigated. Destroy the lab using a reviewed plan, and identify state files and cloud resources that should remain protected or be removed. This project links infrastructure skills with modern delivery security. **05 / KEY CONCEPT** ## Project four: containerized application with health checks **KEY TAKEAWAY** Create a small HTTP service, package it as a container image, and deploy it to a managed container platform such as ECS. Use a task or workload identity with scoped access, a supported image registry, useful logs, and a health endpoint. You do not need Kubernetes to demonstrate container deployment. The key concepts are image immutability, task configuration, networking, resource sizing, restart behavior, and observable releases. Deploy one version and record the image digest and health-check result. Then publish an updated version and observe how the service replaces tasks or Pods. In a lab, introduce a controlled application error and inspect health and log signals. Explain how the deployment would scale and where costs arise from compute, networking, load balancers, and image storage. If the project uses a public endpoint, document the exact scope and controls. Clean up tasks, services, images, associated load balancers, logs, and networking resources intentionally. **06 / PRACTICAL APPLICATION** ## Project five: cloud security investigation **KEY TAKEAWAY** Create a test workload with deliberately narrow permissions and predictable audit events. Record a normal allowed action, then attempt a clearly unauthorized action against a non-sensitive test resource. Investigate the denial using relevant identity and service logs and confirm the policy path that caused it. Expand the exercise into a tabletop scenario involving a compromised deployment identity or unintended public access policy, without performing real attacks or affecting unrelated systems. Write a short incident report: initial alert or symptom, impacted assets, evidence, hypothesis, containment decision, corrective change, and preventive action. Explain what your logging configuration could not prove and what additional data might be needed. If you use threat-detection or audit products with charges, estimate costs before enabling them. Include how to restore access safely if a policy change breaks the application. This project demonstrates cloud security engineering judgment, not merely access to a security console. **07 / KEY CONCEPT** ## A consistent README template for all five **KEY TAKEAWAY** Each project should begin with the problem and intended audience, followed by a high-level architecture diagram and a list of prerequisites. Document the actual region, service model, dependencies, permissions, security assumptions, and cost drivers. Include steps for deployment and validation, plus a section called Observed results that only contains evidence from real tests. Add a troubleshooting log with the errors encountered and their resolutions. Finish with cleanup and known limitations. A colleague should be able to assess the project without reading the entire source repository first. Use descriptive folder names, small modules, secure environment configuration, and a clear license if you share code. Avoid publishing state files, private credentials, sensitive logs, or personal account identifiers. Keep diagrams accurate: if an application has no private database in its deployed version, don’t draw one as if it were operational. Include the exact documentation links that informed important design choices. A well-structured README is itself evidence of an engineer’s ability to communicate operational responsibilities. **08 / PRACTICAL APPLICATION** ## How to present the portfolio in interviews **KEY TAKEAWAY** Choose one or two projects that match the role. For a cloud engineer, trace networking and a recovery scenario. For a DevOps engineer, explain pipeline approval, identity federation, and rollback. For a cloud security engineer, show a permission evaluation, detection evidence, and the rationale for a guardrail. Practice a concise walkthrough: business requirement, architecture, trade-off, implementation, observed result, and what you would improve with more time or resources. Be transparent about your level of involvement. An AI-assisted project is not disqualified from being useful, but you should understand, validate, and be able to explain the code. If your project is based on a tutorial, identify the modifications and original reasoning you added. Interviewers may ask what broke, how you diagnosed it, and what you would do differently. Those questions reward hands-on depth much more than a long list of services. ### Before you finish: practical checklist Turn the main lessons into a short review of your own environment: * Choose a clear problem and define the constraints before implementing it. * Explain how to deploy and destroy the lab without exposing credentials. * Build a small documentation or personal site using a deliberate public content path while keeping the underlying storage private where the architecture supports it. * Document the request path from a browser to the content source, including TLS termination and caching behavior. * Test the expected public page and a storage action that should not be available to an anonymous user. ## Frequently asked questions ### Should projects be production grade? They should demonstrate good engineering habits, but a low-cost portfolio lab does not need every production redundancy feature. Clearly document what would be added for production. ### Do I need five different cloud providers? No. A consistent series on one provider can demonstrate depth. Add another provider only when the comparison supports your career goals. ### Can I show a project that had failures? Yes. Real problems and documented corrections often demonstrate stronger troubleshooting and communication skills than a perfect-looking result without evidence. ## References and next steps [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/userguide/waf.html)· [Terraform workflow](https://developer.hashicorp.com/terraform/tutorials/cli/init)· [GitHub OIDC for AWS](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws)· [ECS Fargate getting started](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/getting-started-fargate.html) Start with one project, verify its results, and publish only the evidence you can substantiate. Add the next project when you understand the first one’s identity, network, cost, and failure behavior. Continue in [Cloud Careers](https://cloudcareerhq.com/category/cloud-careers/) and [Hands-On Labs](https://cloudcareerhq.com/category/hands-on-labs/) for learning and implementation ideas.