Free tech learning for everyone, from basics to pro

ProjectsLabsAdvanced

Project: deploy a secure web app in the cloud

In short: This project shows you can take an application from code to a secure cloud deployment. You define the infrastructure in Terraform, keep the app and database private behind a load balancer and WAF, store secrets properly, scan your code, and destroy everything after recording evidence.

Goal and requirements

The goal is a small but realistic deployment, for example a simple notes or booking app, that follows the security pillar of the cloud providers' well-architected frameworks. The app itself can be tiny; the security design is the point.

  • Infrastructure as code (IaC): everything created with Terraform or OpenTofu, so it can be rebuilt and destroyed.
  • Network: public load balancer only; app and database in private subnets.
  • Data: TLS (Transport Layer Security) on the public endpoint, encryption at rest, automated backups.
  • Identity: MFA on all human accounts; the app uses a role or managed identity, never stored keys.
  • Cost and safety: a budget with alerts before you start, a single region, and terraform destroy at the end of every session.
Request pathUserHTTPS onlyWAF and CDNmanaged rulesLoad balancerTLScertificateApp tierprivatesubnetsDatabaseencrypted,private
Figure 1. Each hop narrows what can reach the next; only the edge is public and the data tier has no internet path.

Design

LayerAWS exampleAzure example
Edge and WAFCloudFront with AWS WAFApplication Gateway with WAF, or Front Door
CertificateAWS Certificate ManagerKey Vault or managed certificate
AppECS Fargate or EC2 in private subnetsApp Service with VNet integration, or Container Apps
DatabaseRDS, encrypted, not publicly accessibleAzure Database for PostgreSQL with private access
SecretsSecrets ManagerKey Vault
LogsCloudTrail, load balancer and WAF logsActivity log, diagnostic settings, Log Analytics
Security controls checklistIdentityMFA, least privilegeNetworkprivate subnets, SGsDataencryption, backupsSecretsmanaged storeLoggingaudit and accesslogsPipelineIaC scanningPatchingimages rebuiltCostbudget, destroy
Figure 2. A secure deployment covers eight areas; reviewers look for evidence in each.

Build plan

  1. Write a short threat model: assets, entry points and the top five threats, with a control for each (see threat modelling).
  2. Write Terraform modules for network, database, app and edge. Keep variables for region and names; no secrets in files.
  3. Scan the IaC and container image before deploying, and fix high findings.
  4. Deploy, then test: HTTPS works, HTTP redirects, the database has no public endpoint, WAF blocks a harmless test pattern you add as a custom rule.
  5. Collect evidence (screenshots, scan reports, log entries), then destroy.
terraform init
terraform fmt -check
terraform validate
trivy config .
trivy image <your-registry>/notes-app:1.0
terraform plan -out tfplan
terraform apply tfplan
curl -I http://<your-domain>
curl -I https://<your-domain>
terraform destroy

Warning: load balancers, NAT gateways, managed databases and WAFs are billed by the hour. Build, test and destroy in one sitting, and check the bill the next day. Keep Terraform state out of public repositories; it can contain secrets.

Deliverables and how to present it

  • Architecture diagram, threat model and a controls table mapping each threat to a control.
  • The Terraform repository with a README, CI that runs format, validate and IaC scanning.
  • A test evidence pack and a teardown confirmation.
  • A one-page cost estimate per hour and how you kept it low.

On a CV: "Deployed a three-tier web app on AWS with Terraform: private subnets, WAF, TLS, Secrets Manager and IaC scanning in CI; documented threat model and controls." Interviewers will ask about trade-offs, such as why the database is private and how secrets reach the app.

Practice

Why should the application use a role or managed identity instead of access keys?
The platform issues short-lived credentials automatically, so there are no long-lived keys to leak or rotate.
Why scan Terraform before applying it?
To catch insecure settings such as public storage or open security groups before they exist in the cloud.
Why must Terraform state be kept private?
State files can contain resource details and secret values in plain text.

Key takeaways

  • Define everything in IaC so it can be rebuilt and destroyed.
  • Only the edge is public; app and data tiers stay private.
  • Use managed secrets and workload identities, not stored keys.
  • Scan IaC and images, and keep evidence of tests.
  • Set a budget and destroy the environment after each session.
Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author

Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.

Stay up to date by email

New notes, tools and security news from FM TecHub, explained simply. Free.

We only use your email to send these updates. See our privacy policy.