3 DevOps Projects for Beginners: Build, Test and Explain

Start with one small application and develop it through three projects: run it reliably, deliver changes automatically, then practise recovering it. You will spend less time switching tutorials and more time understanding how the pieces fit together.

These CloudPros practice briefs help you build, test and troubleshoot a working system. Each has a defined result, a failure to investigate and project work to keep. If you need the terminology first, use the DevOps tools guide.

Choose the project that matches your starting point

If a terminal is new to you, begin with the first project. If you can already containerise an application, start with the pipeline and return to any missing foundations. You do not have to use Kubernetes to make a useful portfolio.

Project 1: make a small service reproducible

Brief: another person should be able to clone your repository, start the application, check its behaviour and stop it using your instructions.

Choose an application with a narrow purpose: a greeting endpoint, a notes API or a small status page. Use a tutorial starter if needed, credit its source and keep the application simple. The objective is to operate it, not spend a month building product features.

Record the language/runtime version, dependencies, start command and expected response. Add a check that returns failure when the expected behaviour is absent. If you need an approachable first script, try the release-file validation exercise.

Introduce a failure

Stop the application and run your check. Does it report a useful error, exit unsuccessfully and avoid waiting forever? Start the application on the wrong port and compare the symptoms. Record what you observed before fixing the problem.

Done when: someone can follow the README in a clean environment, and your check distinguishes success from the failure you introduced. Keep secrets out of the repository; provide sample variable names with harmless example values.

Useful next steps: Linux commands to practise and a first Git workflow.

Project 2: test and package every change

Brief: a proposed change should run checks automatically. A release should produce a container image you can identify and run again.

Use the same application. Write a Dockerfile and verify that the container behaves like the local version. Add a workflow that checks out the repository, installs the necessary dependencies and runs your tests. Build the image only after the checks pass.

GitHub's workflow documentation describes the events, jobs and steps used for this. Docker's image guide explains how an image packages the files and configuration needed to run a container.

Keep pull-request checks separate from any later publishing or deployment step. A beginner's pipeline can stop at a successful local image build. If you publish to a registry, review its access, usage and billing settings first.

Introduce a failure

Make a change that breaks a test. Confirm that the workflow fails at the expected step and that any dependent release step does not run. Repair the change and compare the two runs. A useful test detects a real behaviour change, rather than always passing.

Label each image with an identifiable revision and record the relationship between source commit, workflow run and image. Explain how you would locate the previous working version. A tag can be moved, so record an image digest when you need an immutable reference.

Done when: you can show a failed change, the corrected change and the resulting image. A new reader should understand what the checks prove and what they do not cover.

Follow our beginner CI/CD tutorial and workflow security checklist. Add only the permissions your workflow needs.

Project 3: deploy, observe and recover

Brief: run your application in a disposable local Kubernetes environment, then investigate a failed release and restore the previous working state.

Begin with a Deployment and a Service. Sketch the request path from the client to the application. Add health checks appropriate to the application, and explain what each check tests. The official Kubernetes basics tutorial provides a sequence covering deployment, exposure, scaling and updates.

Local tooling also has requirements: check memory, disk space and supported installation instructions before starting. If Kubernetes is too much for your current machine or experience, practise the same operating questions with one Docker container first.

Introduce a failure

In the disposable lab, change the application image to a nonexistent version. Inspect the rollout and Pod events before making another change. Compare desired state with actual state. Restore the previous working image, then verify the application response as well as the platform status.

Use the Pod troubleshooting guide to structure the investigation. Write a short incident note with the symptom, evidence, cause, repair and a check that would catch the mistake earlier.

Done when: you can trace a request, identify the failed rollout, restore service and remove the lab using documented cleanup steps. Avoid testing failure scenarios against a shared or production environment.

Add cloud infrastructure only when it answers a question

An AWS extension might teach you networking, access control or repeatable provisioning with Terraform. Define that objective before opening the console. Write down the resources you expect to create, how charges arise and how you will remove them.

Use the AWS lab cost checklist, then the first Terraform configuration guide. A budget notification is not a general spending cap. Check for resources left behind after an exercise, including storage and networking components.

You can demonstrate valuable skills locally while deciding whether a cloud extension is worth the cost. Do not label a local project as production experience.

Package the evidence for a reviewer

Keep the repository readable. Give it a short description and a README with these sections:

What this application does
Architecture and request path
Prerequisites and setup
Tests and expected results
Build and release process
Failure investigation and recovery
Known limitations
Cleanup
Sources and my contributions

For a deeper review, use the portfolio evidence checklist. Then turn verified work into specific bullets using our DevOps CV and resume guide. If you want live teaching around the same skills, explore the CloudPros curriculum.

Frequently asked questions

What is a good first DevOps project?+

Start with a small application you can run locally, keep in Git and check with a repeatable command. Document setup and failure behaviour before adding containers, a pipeline or cloud infrastructure.

Do I need AWS to build DevOps projects?+

No. You can practise Git, scripting, containers, automated tests and local Kubernetes without an AWS account. Add a cloud lab when you have a clear learning objective and understand its cost and cleanup requirements.

How many DevOps projects should I put on my CV?+

Choose the projects that best demonstrate the requirements of the role. One project you can explain, reproduce and troubleshoot is more useful than several copied tutorials you cannot discuss. There is no universal required number.

Can I use a tutorial project in my portfolio?+

Yes, with honest attribution. State the starting source, distinguish your own changes, and show a failure you investigated or a decision you made. Do not present copied work as an original production system.