How to Pass a Cloud Take-Home Task or Technical Test

Cloud take-home tasks are common at startups and mid-size companies that want to see real work before making a hire. Many candidates who know their subject well still fail these assessments — not because of gaps in cloud knowledge, but because of how they approach, structure, and submit the work. This page covers how to handle the whole process, from reading the brief to presenting it in a follow-up interview.

What Take-Home Tasks Look Like in Cloud Roles#

Companies ask for different things depending on what they need. The most common formats are:

Infrastructure-as-code tasks. Write a Terraform module, deploy a resource group with correct tagging, or build a reusable VPC module. These assess whether you can write clean, parameterised IaC and not just Terraform that happens to work.

Container or Kubernetes deployment tasks. Dockerise an application, write a Helm chart, deploy a service to a local cluster, or set up a deployment with health checks and resource limits. These test your understanding of the full container lifecycle, not just that you’ve run docker build before.

CI/CD pipeline tasks. Build a GitHub Actions, GitLab CI, or CircleCI pipeline that runs tests, builds a container image, and pushes it to a registry. These test pipeline structure, secret handling, and environment separation — areas where mistakes are easy to make.

Architecture design tasks. “Design an architecture for a service that handles X” — produce a diagram and written rationale. Less common as a pure take-home, often used as a structured part of a system design interview.

Debugging or troubleshooting tasks. Here’s a broken Terraform configuration, a failing pipeline, or a Kubernetes deployment that won’t start — find what’s wrong and fix it. These test practical knowledge more than theoretical.

What Companies Are Actually Evaluating#

Does it work? Yes, that matters. But interviewers reviewing take-home tasks are also looking at things the code itself doesn’t tell them:

Decision-making. Why did you choose this approach over alternatives? Did you acknowledge the trade-offs?

Code quality. Is the Terraform modular? Are there hardcoded values that should be variables? Is naming consistent and clear?

Security awareness. Are secrets in the code or in environment variables? Are IAM permissions scoped appropriately or wildcard?

Documentation. Is there a README that explains how to run this? Would someone unfamiliar with your code be able to use it?

Scope management. Did you complete the core task cleanly, or did you half-complete an over-ambitious interpretation?

A submission that works perfectly but has hardcoded API keys, no README, and no explanation of decisions often loses to a submission that’s slightly simpler but clean, documented, and professionally presented.

How to Approach the Task#

Read the brief twice before writing a line of code. Identify what is explicitly required, what is implied, and what is ambiguous. Make a list of the ambiguities.

Ask one clarifying question, early. Most companies expect you to ask at least one question. It signals engagement and saves you from building something that misses the point. Asking “is this meant to be production-grade or a working proof-of-concept?” is a reasonable and useful question. Asking ten questions suggests you can’t operate with ambiguity.

Timebox your work. If the brief says “3–4 hours,” treat that as a real constraint. Submitting something that took 12 hours and is very polished is not an advantage — it signals you can’t manage scope. Do the core task well, note what you’d add with more time, and stop.

Plan before you build. Spend 15–20 minutes deciding on your approach before touching the keyboard. What structure will the Terraform have? What stages will the pipeline include? What image base will you use and why? This planning often surfaces decisions worth documenting.

Test your own submission. Run it from a clean directory, on a fresh state, following only your own README instructions. If it breaks, a reviewer will find the same break.

What to Include Beyond the Code#

The README is where most candidates leave marks on the table. A good README for a take-home task includes:

How to run it. Prerequisites, environment variables needed, commands to execute, expected output. Assume the reviewer is starting from scratch.

Decisions made and why. “I used a remote S3 backend for Terraform state to avoid local state conflicts” is better than leaving the reviewer to guess. Note 3–5 meaningful decisions.

What you’d do differently with more time. Be specific. “I’d add input validation on the Terraform variables and configure a proper CI/CD pipeline to apply the plan” is useful. “I’d make it more production-ready” is not.

What you intentionally left out. If the task hinted at monitoring and you didn’t implement it, say so and briefly explain why (time constraints, outside scope, would need more context on the target environment). This shows you saw it, not that you missed it.

Assumptions. If you assumed the task was targeting a single region, or that the reviewer has Terraform 1.x installed, write that down.

This structure takes 30–45 minutes to write and is the difference between a submission that looks professional and one that looks like a homework answer.

Common Failure Modes#

Over-engineering. The task asked you to deploy a containerised app. You built a multi-region, auto-scaling, blue-green deployment with full observability. This is a problem: it takes longer, introduces more failure points, is harder to review, and signals that you can’t match output to requirements.

Missing the stated requirement. Read the brief again. If they asked for the infrastructure to be idempotent and you’ve written aws_instance resources with no lifecycle rules, you’ve missed a stated requirement.

Hardcoded secrets. AWS access keys, database passwords, or API tokens committed to the repository will fail the submission. Use environment variables, tfvars files (listed in .gitignore), or secrets managers. Always add a .gitignore appropriate to the tools you used.

No error handling. A pipeline that fails with no meaningful error output, or a script that exits silently on failure, suggests you haven’t thought about how this would be operated in practice.

No README. Submissions with no README require the reviewer to read the code, guess at intent, and figure out how to run it. This creates unnecessary friction and signals that documentation is an afterthought for you.

Submitting too fast. Take-home tasks sent back within an hour of receipt (for a task rated at 3–4 hours) suggest you didn’t engage with it seriously. If you genuinely finish quickly, spend the remaining time polishing the README and testing the submission.

Presenting the Work in a Follow-Up Interview#

Most companies schedule a technical review call after a take-home task. The format is usually: walk me through what you built, then questions from the reviewer.

Lead with decisions, not description. Don’t narrate the code line by line. Start with: “My approach was X because Y. The key decisions I made were A, B, and C.” This matches the way the reviewer wants to consume the information.

Anticipate the “what would you change?” question. Have a real answer ready. Interviewers often ask this to see how you reflect on your own work. “I’d extract the networking layer into a separate module to make it reusable, and I’d add proper variable validation” is the kind of specific answer that works.

Be prepared to defend your choices. The reviewer may push back: “Why did you use X instead of Y?” A strong answer explains the trade-off you weighed. A weak answer is “I’m more familiar with X” — unless that’s genuinely the most honest and relevant answer.

Admit mistakes directly. If you spot a flaw in your submission while presenting it, name it before the reviewer does. “I noticed after submitting that the IAM role has broader permissions than it needs — I’d scope those down in production” is a mature response that shows self-awareness.