What changes between the roles?
Platform engineering often creates reusable capabilities for development teams: deployment paths, documentation, environments or observability that people can use without bespoke help each time. DevOps-oriented roles may concentrate on collaboration across development and operations, automation, release pipelines and the systems that support delivery.
These responsibilities overlap. A Kubernetes engineer might build the shared platform or operate workloads on one. An SRE might define service objectives and incident practices that inform both. Describe your scope rather than trying to prove that one title is more advanced.
- Who used the capability you built?
- Was it a shared platform, a team-specific deployment or operational support?
- Which decisions did you own and which belonged to application teams?
Connect tools to operational decisions
Kubernetes can manage application workloads, but operating it well requires more than writing deployment YAML. Think about resource settings, rollout and rollback, service connectivity, access and what happens when a component becomes unhealthy. A useful example explains a workload decision in its wider operating context.
Terraform can express infrastructure as code, but safe use also involves reviewing plans, managing state, controlling access and understanding changes before applying them. Cloud-provider names provide background; the design and operational decisions demonstrate experience.
- Give an example of a release or infrastructure change with a clear failure plan.
- Describe how developers learned to use your work and how they got support.
- Avoid sharing credentials, detailed security configurations or private architecture.
Show reliability, not a count of incidents
Observability should help a team decide what to do. Explain what signals you monitored, how an alert related to user impact, and how you handled uncertainty during a problem. If service objectives were used, describe what they measured and who agreed on the trade-offs.
Incidents are rarely individual achievements. A sanitized example can show collaboration, communication, rollback or follow-up without disclosing a customer's environment. Be clear if you were on call, consulted occasionally or helped design the process.
Describe your cloud and DevOps experience clearly
Start with a bottleneck or reliability need. Describe your role, the path you built or improved, the teams affected and one decision you would make differently. Support claims with an example of a reviewed change, useful documentation or a measurable process—without implying results you cannot substantiate.
As your responsibilities change, update the difference between hands-on Kubernetes, Terraform, CI/CD, cloud architecture and SRE practice. Specificity helps a hiring team ask better questions and helps you recognize roles that genuinely match your experience.
Turn this guide into your profile
- Create an account and verify your email.
- Complete your profile; you can optionally upload a .pdf or .docx resume during setup, and manage resumes later in your Talent Passport.
- Keep your Talent Passport current as your work changes.