Show the engineering loop, not just a code sample
Infrastructure as code (IaC) describes infrastructure in files that tools can evaluate and use to provision or change resources. The strongest portfolio project makes the full work cycle visible: requirements, design, proposed change, review, deployment decision, verification, and cleanup. A hiring manager should be able to understand the result without guessing what the configuration is supposed to do.
Pick a small, safe scope. For example, define a private application environment with a network boundary, a service role, a basic workload, and logging. Keep it in a personal sandbox, use synthetic data, and avoid employer systems, production credentials, customer data, or copied internal configuration. You can build the example in Terraform or a cloud provider’s native template format. The point is to show judgment and repeatability, not to imply that one tool is universally best.
Build a portfolio repository in six parts
- Mission and architecture. Write a short brief: what the system is for, who uses it, the assumptions, and what is deliberately out of scope. Include a simple diagram and identify trust boundaries, network paths, and data flows.
- Small reusable configuration. Organize inputs, outputs, and modules so another engineer can see which choices vary by environment. Keep naming and resource descriptions consistent. Explain any shortcuts that make the demo smaller than a production design.
- A reviewable change. Include a pull request or change note showing what changed and why. Terraform’s plan command produces a preview of proposed actions; its documentation also notes that a speculative plan does not apply changes. Capture a sanitized example of the review step, with no account identifiers, secrets, or private infrastructure details.
- Tests and checks. Add formatting and validation steps, plus tests for important assumptions such as allowed network paths, required tags, or encryption settings. Explain limits: a passing static check cannot prove that an entire system is secure or suitable for production.
- Operations and drift. Document how an operator detects configuration changes made outside the IaC workflow and how the team decides whether to reconcile or update the declared configuration. AWS explains that CloudFormation drift detection compares actual resource properties with those specified in a stack template, and that coverage depends on supported properties and resources. That caveat is a good example of the operational detail employers value.
- Safe state and cleanup. Explain where state is stored, who can access it, how changes are locked or coordinated, and how the sandbox is removed. Terraform’s documentation warns that state can contain sensitive information and recommends secure remote storage with access controls and locking rather than a repository that lacks those protections. Never publish a state file or secrets.
Make security and maintenance part of the demo
Use least privilege in any account you control, and do not put credentials in source files, screenshots, or issue history. Show how secrets are injected through a protected mechanism without exposing their values. Include a short “known limitations” section that explains what the sample does not cover: for example, high availability, a formal threat model, organization-wide policy, or recovery testing.
For a mature portfolio, connect the code to a secure-development lifecycle. NIST’s Secure Software Development Framework (SSDF) organizes practices around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. You do not need to claim full SSDF compliance in a small lab. Instead, point to the practices your example demonstrates—review, testing, controlled changes, and a clear response path.
What to put in the README
- A concise description of the problem and the expected output.
- A diagram, component list, assumptions, and setup steps.
- How to run checks and interpret the proposed change.
- Security decisions and the boundaries of the exercise.
- How to clean up resources and avoid unexpected ongoing costs.
- What you would improve next if the system moved beyond a learning lab.
Do not optimize the sample for size or cleverness. Optimize for a reviewer’s ability to follow your reasoning. A modest environment with clear boundaries, readable changes, a credible test plan, careful state handling, and honest limitations usually communicates more than a sprawling collection of provider-specific snippets.
Turn the portfolio into an interview conversation
Prepare to walk through one design decision, one failure mode, and one trade-off. Be able to explain what the plan showed, what you checked before applying it, how you would investigate drift, and what would change for a real team. If you used documentation or AI assistance, describe what you verified yourself. Hiring teams are assessing how you reason and communicate, not whether you memorized every provider setting.
Finally, tailor the project to the work you want. For cloud operations, emphasize observability and recovery. For platform engineering, emphasize reusable interfaces and developer experience. For security engineering, explain threat boundaries and permission design. A focused, well-documented project gives employers a concrete basis for a technical conversation and gives you a repeatable way to show how you work.