Project structure · Data and DevOps
Terraform project structure
Opens with creditsAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
Curated by Tauseef FayyazIntermediate133 files and foldersTerraform 1.16 (also runs on OpenTofu 1.13), AWS provider 6.x, TFLint 0.64 with the AWS ruleset 0.49Checked October 2026How it grows
Each stage opens the explorer there
- 1Day 1What the scaffold and your first hour give you16 files and folders
- 2GrowingWhat a real app with features and tests adds+54 files and folders
- ProductionWhat running it for real users adds+27 files and foldersOpens with credits
- ExpertWhat a team needs to keep it healthy for years+36 files and foldersOpens with credits
How it is organised
- Reusable code lives in `modules/`; each folder in `environments/` is a root module that calls those modules with its own values and has its own state.
- One state per environment. A plan in dev can never change prod, and you can see every environment's settings by opening its folder.
- State lives in a versioned, encrypted S3 bucket with locking. Never in Git, never only on a laptop.
- Follow the HashiCorp style guide file names: `terraform.tf` for versions, `providers.tf`, `backend.tf`, `main.tf`, `variables.tf`, `outputs.tf`, `locals.tf`.
- Pin versions in layers: `.terraform-version` pins the CLI, `required_providers` sets the allowed range, and the committed `.terraform.lock.hcl` pins the exact provider build.
- Reusable modules declare minimum versions only and have no lock file in Git; root modules decide the exact versions.
- Every change goes through a pull request that shows the plan. Only CI applies, with short-lived OIDC credentials and an approval for prod.
- Test cheaply first: fmt, validate and TFLint on every save, mocked `terraform test` on every push, scanners and policies on every plan, real apply tests before a module release.
- No secrets in `.tf` or `.tfvars` files. Let the cloud generate and store them (Secrets Manager, managed passwords) and pass references around.
- Write code that both Terraform and OpenTofu accept unless you have decided otherwise; use `.tofu` files only for OpenTofu-only features.
At the top of the project
Open one in the explorer for the full story
- shop-infra/
- .devcontainer/A dev container with Terraform, TFLint, Trivy and the AWS CLI preinstalled.1 inside
- .vscode/Shared editor settings and extension recommendations.2 inside
- bootstrap/A tiny one-off configuration that creates the S3 bucket holding every other state file.5 inside
- environments/One folder per environment, each a root module with its own state. Some teams call it live/.2 inside
- modules/Reusable modules, each a folder that the environments call with their own values.4 inside
- .editorconfigTwo-space indentation and a final newline for .tf, .hcl and YAML files.
- .gitignoreKeeps provider downloads, state, plans and local overrides out of Git.
- .pre-commit-config.yamlGit hooks that run fmt, validate, TFLint, terraform-docs and Trivy before each commit.
- .terraform-versionThe exact Terraform CLI version for this repo.
- .tflint.hclTFLint config: the recommended Terraform rules and the AWS ruleset.
- MakefileShort commands for the long ones: make fmt, make lint, make test, make plan ENV=dev.
- README.mdWhat this repo manages, how to get credentials, and how to plan and apply.
Learn more on Sefism
Roadmaps, cheat sheets and projects that go with Terraform.
- RoadmapDevOps and cloud roadmapLinux, Docker, Kubernetes, AWS
- Roadmap· AWSCloud engineering roadmapOne cloud in depth, with certifications
- Roadmap· Platform engineeringPlatform engineering and SRE roadmapSLOs, observability, Kubernetes platforms
- Cheat sheetDevOps and cloud cheat sheetLinux, Docker, Kubernetes, AWS.
- Cheat sheetCloud engineering cheat sheetOne cloud in depth, with certifications.
- FYP idea· IntermediateTerraform Plan Blast Radius Reviewer That Explains Risky Infrastructure Changes on Pull RequestsBuild a pull request bot that reads the machine-readable output of terraform plan or tofu plan and explains in plain language what could go wrong: a database that will be replaced and lose data, a security group opened to the internet, an IAM policy that grew from read to admin. Reviewers stop approving 400-line plans they never read. High-risk changes need an extra approval.
- FYP idea· AdvancedCloud Landing Zone Starter Kit for Small Teams with TerraformBuild an open infrastructure-as-code kit that gives a small startup or software house a secure cloud foundation on AWS, Azure or Google Cloud in an afternoon: separate environments, SSO and least-privilege roles, a network with public and private subnets, central audit logging, budgets, guardrail policies and a drift and compliance report. An advanced cloud and DevOps final year project.
- FYP idea· IntermediateStudent Cloud Sandboxes with Budgets and Automatic Cleanup for University LabsBuild a system that gives every student in a cloud computing course their own sandbox on AWS, Azure or Google Cloud, with a budget, least-privilege access, required tags and nightly clean-up of anything left running, plus a lecturer dashboard. A beginner-to-intermediate cloud and DevOps final year project that solves a problem every university lab has: surprise bills and forgotten resources.
- QuestionWhich cloud should I learn first: AWS, Azure or GCP?If you have no reason to choose otherwise, start with AWS: it has the largest market share and the most learning material. Choose Azure if the employers you want run on Microsoft, and GCP if you are heading into data and ML work at companies that use it. The concepts transfer, so the first cloud matters less than learning it properly.
See 7 moreShow fewer
- QuestionHow do I practise on AWS, Azure or Google Cloud without getting a surprise bill?Use the free offer that fits you, set a budget alert before you create anything, tag every resource, build and destroy your labs with code, and run a five-minute check for the usual culprits, such as NAT gateways, load balancers, databases and public IPs, before you close your laptop.
- QuestionCan a fresher get a cloud engineering job, or do I need to start in support or DevOps first?Some freshers do, usually through graduate programmes, cloud support roles or companies that train juniors, but most people reach a cloud engineering title after a first job in cloud support, system administration, DevOps or backend work. One cloud to associate level plus a project you can explain makes either route much shorter.
- QuestionWhat is platform engineering, and how is it different from DevOps?DevOps is a culture and set of practices: developers and operations sharing responsibility for shipping and running software. Platform engineering is one way to put that into practice at scale: a team builds an internal platform, a paved road of tools and templates, so product teams can ship without becoming infrastructure experts.
- Resource· GuideOpenTofu DocumentationThe official docs for OpenTofu, the open source, community-run fork of Terraform. Covers the HCL language, the tofu CLI, state and backends, a step-by-step migration path from Terraform, and features Terraform does not have, such as client-side state encryption and provider for_each.
- Resource· GuideAWS DocumentationThe official home of every AWS user guide, API reference and CLI reference, plus decision guides that compare services such as Fargate and Lambda. The IAM, VPC, EC2 and S3 user guides are the most reliable way to learn how AWS really behaves, and they are free.
- Resource· ToolInfracostAn open source tool that shows the monthly cost of Terraform, CloudFormation or CDK changes before they are deployed, as a comment on the pull request or inline in your editor, for AWS, Azure and Google Cloud. The easiest way to bring cost into code review.
- Resource· RoadmapLearn to CloudA free, open curriculum for becoming a cloud engineer, founded by Gwyneth Peña-Siguenza with Rishab Kumar. It runs from Linux, networking and Python through cloud platform fundamentals, DevOps and security, with a hands-on project in each phase and a choice of AWS, Azure or Google Cloud.
Checked against 21 official sources, October 2026. If something has changed, the docs win.Show sourcesHide sources
- Terraform: Style guide
- Terraform: Standard module structure
- Terraform: Dependency lock file
- Terraform: S3 backend
- Terraform: Tests
- Terraform: Refactoring with moved blocks
- Terraform: Import blocks
- Terraform: Checks
- Terraform releases and changelog
- hashicorp/setup-terraform action
- AWS provider on the Terraform Registry
- OpenTofu documentation
- TFLint
- TFLint AWS ruleset
- Trivy: Terraform misconfiguration scanning
- Checkov documentation
- terraform-docs
- pre-commit-terraform
- Conftest
- GitHub Docs: Configuring OpenID Connect in AWS
- GitHub Docs: Dependabot supported ecosystems
Best practices and checklists for this stack
Picked from the other libraries by shared topics.
Best practices
See all- Kubernetes Best PracticesRun workloads on Kubernetes that schedule well, survive restarts and node drains, and stay locked down: resources, probes, PDBs, Pod Security and RBAC.
- Terraform Best PracticesWrite Terraform that teams can review and change safely: file layout, version pinning, remote state with locking, secrets, modules, refactoring and tests.
- CI/CD Best PracticesBuild pipelines that are fast, trustworthy and safe to deploy from: trunk-based flow, fast tests, locked-down workflows, signed artifacts, canaries and DORA metrics.
Checklists
See all- Incident Response ChecklistPrepare for and handle production incidents: on-call, severity levels, declaring, roles, mitigation, security containment, status updates and blameless postmortems.
- Kubernetes Production ChecklistVerify a workload and its cluster before real traffic: requests and limits, probes, PDBs, spread, Pod Security, RBAC, network policies, secrets, images, autoscaling, upgrades and backups.
- Disaster Recovery ChecklistBackups and DR you can prove: RPO and RTO per system, backup coverage, off-site and immutable copies, restore tests, zone and region choices, runbooks, drills, dependencies and communication.
Work with me
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com