I've spent the last several months studying Kubernetes in depth and have worked through a comprehensive technical course. I'm planning to take a Kubernetes certification soon, then build a serious portfolio project rather than another basic demo.
I have a strong background in cryptography and am considering creating a privacy-preserving leaked-password monitoring system inspired by k-anonymity approaches. The idea would involve securely checking whether passwords or credentials have appeared in breach datasets without exposing the original secrets.
On the Kubernetes side, I've configured cert-manager with an API gateway, installed Cilium, built and maintained local clusters, and spent time debugging kube-proxy, iptables, services, and network policies. Networking is the area I enjoy most.
I also have experience with Python, ACID and NoSQL databases, RabbitMQ, Git, Ansible, GitLab CI, Proxmox, KVM, and basic monitoring tools. I'm considering building a complete CI/CD setup with testing, GitLab pipelines, Kubernetes controllers, Argo CD, security checks, and possibly a cloud deployment. I've used Prometheus and Grafana before, but it's difficult to demonstrate their value on a local cluster where nothing generates much real-world traffic.
For someone applying to junior DevOps, Kubernetes, or security roles, what kind of project would recruiters actually find convincing? Would a multi-environment or multi-cluster deployment, observability stack, infrastructure-as-code, or security-focused project provide the best return? Is it worth pursuing another certification, such as a Kubernetes security certification, or would a well-documented end-to-end project and a few open-source contributions be more valuable?
3 Answers
The leaked-password project is a strong idea, especially because it combines your cryptography background with infrastructure and security. Just make sure it demonstrates more than an algorithm: document the threat model, privacy guarantees, rate limiting, secret handling, data ingestion, testing, and deployment architecture.
For the Kubernetes portion, contributing to established open-source projects can be more valuable than building a huge system alone. Look for beginner-friendly issues in projects around networking, deployment, certificates, observability, policy, or runtime security. Documentation improvements, tests, bug reproduction, and small fixes all show that you can work with real codebases.
A polished project that uses several of these tools, plus a couple of genuine contributions, will usually stand out more than another basic Kubernetes demo.
Having your own cluster already gives you a useful foundation. Use it to host several realistic services instead of focusing only on a single showcase application: an internal platform, a database-backed API, a message queue, automated backups, ingress, certificate management, access control, and monitoring.
Then make the project easy to evaluate. Include architecture diagrams, setup instructions, failure scenarios, security decisions, costs, and a short explanation of what you would change for a larger deployment. Recruiters and engineers usually learn more from seeing how you operate and troubleshoot a system than from seeing a long list of installed tools.
A security certification can help, particularly if security is your target area, but it should complement a practical project rather than replace one. For a junior candidate, evidence that you can build, automate, observe, secure, and explain a system is likely to have better value than collecting certifications alone.
My concern is that security-focused roles often expect professional experience, so I’m trying to decide whether pursuing a security certification now is more useful than finishing a complete project.
A realistic portfolio environment could include separate development, staging, and production clusters or namespaces, with infrastructure provisioned by Terraform and deployments managed through Helm and Argo CD. Add automated tests, policy checks, image scanning, rollback procedures, and clear documentation.
For observability, use OpenTelemetry with a metrics, logs, and traces stack such as Prometheus, Grafana, Loki, and Tempo. A local cluster may not have production-scale problems, but you can create useful scenarios: deliberately introduce latency, crash a service, exhaust resources, break a dependency, or generate failed deployments. Then show how your dashboards and alerts help diagnose the issue.
That kind of setup demonstrates operational thinking rather than just familiarity with individual tools.
When people say multi-environment Kubernetes, they usually mean isolated development, staging, and production setups, or at least separate namespaces with different configuration and promotion rules. The important part is showing how changes move safely between environments.
I’m planning a complete CI/CD pipeline with testing, GitLab CI, Kubernetes, Argo CD, and security checks. I’m still unsure whether adding cloud infrastructure or going deeper into Cilium would be worthwhile for a junior role.