Four niches. And the differences within them.

A label says little. Whoever reads "Cloud Engineer" and stops asking places random hits. We keep asking: which ecosystem, which tools, which way of thinking. Only then does a dossier match a mandate.

Cybersecurity

Attack, defence and evidence are three different professions.

Offensive security (penetration testing, red team) thinks in attack paths. Defensive security (SOC, incident response, detection engineering) thinks in signals and response time. GRC (ISO 27001, BSI IT-Grundschutz, NIS2) translates both into evidence that auditors accept. Cloud security is a field of its own on top: someone hardening IAM in Azure rarely has the same profile as a network pentester.

WHAT WE LOOK FOR

• We read certificates as a language: OSCP tells of hands-on offence, CISSP of architecture and responsibility.
• Critical-infrastructure and corporate environments demand a different way of working than start-ups: change processes instead of quick fixes.
• We ask about the last incident, not just the last tool.

Cloud

Azure, AWS and Google Cloud are three ecosystems, not three logos.

Azure hangs on the Microsoft stack (Entra ID, M365) and dominates in DACH corporations. AWS carries the broadest range of services, from start-up to enterprise. Google Cloud is at home where data and machine learning set the pace (BigQuery, Kubernetes origins). "Multi-cloud" on a CV rarely means: deep three times over.

WHAT WE LOOK FOR

• Certification paths and project years per platform, not the list of logos.
• Infrastructure as code as handwriting: Terraform, Bicep or CloudFormation reveal the home platform.
• Migration is not greenfield: lifting legacy into the cloud is a different skill from building on a green field.

DevOps

Building pipelines and owning operations are two different pairs of shoes.

CI/CD chains (GitHub Actions, GitLab, Jenkins) are the craft. SRE is the attitude behind it: error budgets, observability (Prometheus, Grafana, Datadog), on-call duty. In between lies Kubernetes, with its own distributions and its own depth.

WHAT WE LOOK FOR

• On-call experience: whoever has been woken at night builds differently by day.
• Kubernetes in production is something different from Kubernetes in a tutorial.
• Tools change, principles remain: we ask about the why behind the pipeline.

Platform Engineering

The platform is a product. The customer sits in your own house.

Internal developer platforms (Backstage and co., golden paths, self-service) demand product thinking: roadmap, user interviews, adoption. That is what separates platform engineers from DevOps generalists, even if the toolbox looks similar.

WHAT WE LOOK FOR

• Product understanding: who were the internal customers, and how was success measured?
• Adoption beats architecture: a platform nobody uses is not one.
• Interface work across team boundaries: here, communication is a core competence, not an extra.