Cloud-Keywords stehen heute in fast jedem IT-Lebenslauf. Doch was wirklich zählt, ist nicht, ob jemand „mit AWS gearbeitet“ hat – sondern wie tief. Hat die Person lediglich ein paar Ressourcen per Klick in der Konsole erstellt? Oder wurde eine ganze Cloud-Infrastruktur per Code aufgebaut, inklusive Governance, Kostenkontrolle und Sicherheitskonzept? Was im Cloud Recruiting wirklich wichtig ist.
Viele Recruiter:innen können diese Tiefe nicht auf den ersten Blick erkennen – und verpassen so die besten Cloud-Architekt:innen. Dieser Artikel zeigt dir, wie du treffsicher unterscheidest zwischen Buzzword-Bingo und echter Architekturverantwortung.
1. Cloud ist nicht gleich Cloud: Warum Buzzwords im CV nichts über Tiefe aussagen
Cloud steht drauf – aber was steckt drin? Kandidat:innen schreiben oft „Azure“, „AWS“ oder „GCP“ in ihre Profile, obwohl sie damit nur am Rande gearbeitet haben. Zum Beispiel:
-
ein Entwickler deployt Code in ein Azure App Service – ohne je mit Netzwerken, Security oder Architektur zu tun zu haben.
-
ein Admin nutzt S3-Speicher in einem bestehenden AWS-Setup – ohne Verantwortung für dessen Design oder Governance.
Solche „Cloud Exposure“-Erfahrungen sind weit verbreitet, aber sie bedeuten keine Architekturkompetenz. Genau hier beginnt deine Arbeit als Recruiter: gezielt herausfinden, ob du es mit einer echten Cloud-Architekt:in zu tun hast.
2. Cloud Exposure vs. Cloud Ownership: Ein entscheidender Unterschied
Der wichtigste Unterschied liegt in der Verantwortung:
| Cloud Exposure | Cloud Ownership |
|---|---|
| Nutzung bestehender Ressourcen | Aufbau & Design der Cloud-Umgebung |
| Zugriff über GUI oder Web-Konsole | Einsatz von Infrastructure as a Code (zB. Terraform) |
| Kein Einfluss auf Architekturentscheidungen | Auswahl von Achitektur-Patterns, Tools und Strukturen |
| Fokus auf Nutzung | Fokus auf Betriebssicherheit, Skalierbarkeit, Governance |
| Column 1 Value 5 | Column 2 Value 5 |
Fragen im Interview: Cloud Recruiting
„Haben Sie selbst die Architektur entwickelt oder in einem bestehenden System gearbeitet?“
„Wie haben Sie Security, Netzwerk und Zugriffskontrolle gelöst?“
„Wie wurde Ihre Infrastruktur ausgerollt – manuell oder via IaC?“
3. Technische Beweise finden: GitHub, Terraform & Zertifikate – auch ohne IT-Hintergrund erkennen, was zählt
Viele Recruiter:innen schrecken davor zurück, sich GitHub-Profile oder Terraform-Code anzuschauen. Dabei brauchst du kein Tech-Profi zu sein, um Indizien für tiefes Know-how zu erkennen.
GitHub – so findest du öffentliches Cloud-Know-how:
-
Geh auf github.com und suche nach dem Namen des Kandidaten.
-
Achte auf Repositories mit Begriffen wie:
-
terraform -
landing-zone -
azure-bicep -
cloudformation
-
-
Schau dir die Ordnerstruktur an:
-
Gibt es
main.tf,variables.tf,README.md? Das deutet auf Infrastructure as Code hin.
-
-
Ist der Code kommentiert oder professionell strukturiert? Dann hat die Person vermutlich echte Projekterfahrung eingebracht.
📌 Tipp: Wenn kein GitHub-Profil vorhanden ist, frag aktiv nach. Viele erfahrene Architekt:innen haben private Repos oder liefern Referenzbeispiele auf Anfrage. Cloud Recruiting
Zertifikate – was Recruiter:innen beachten sollten:
-
Level beachten: Associate ≠ Professional. AWS Certified Solutions Architect – Professional ist deutlich anspruchsvoller.
-
Gültigkeit: Viele Zertifikate laufen nach 2–3 Jahren ab. Nachweise aus 2018 sind meist irrelevant.
-
Tool-Zertifikate: Terraform, Kubernetes, Azure Architect Expert – all das signalisiert echte Hands-on-Erfahrung.
Wenn du unsicher bist: Frag im Interview nach einem konkreten Projekt, in dem das Wissen angewendet wurde.
4. TOGAF, Architektur-Patterns und Landing Zones: Wie man echte Architekt:innen erkennt
Cloud-Architektur ist mehr als nur technische Umsetzung – sie bedeutet strategisches Denken. Wer hier mitreden kann, kennt Frameworks wie TOGAF, denkt in Domänen und nutzt standardisierte Muster für Skalierung, Security und Betrieb.
Woran du erkennst, ob jemand wirklich Architektur „denkt“:
-
Die Person kann erklären, warum sie sich für ein Hub-and-Spoke-Modell entschieden hat – und wann sie lieber Flat Networking nutzt.
-
Sie kennt Begriffe wie Landing Zones, Shared Responsibility Model oder Guardrails – und kann sie mit Beispielen füllen.
-
Sie denkt nicht nur an Technik, sondern auch an Compliance, Skalierung, Kosten und Teams.
🧠 Frage:
„Wie haben Sie Governance, Kosten und Security in Ihrer Architektur abgebildet?“
5. Sourcing-Strategien für Cloud-Architekt:innen – jenseits von LinkedIn
Viele Top-Leute findest du nicht mit klassischen LinkedIn-Suchen. Warum? Weil sie dort wenig aktiv sind – oder bewusst Understatement betreiben. Hier sind bessere Wege:
🧑💻 GitHub & GitLab:
-
Suche gezielt nach Repositories mit
terraform,cloud,bicep,landing-zone. -
Tools wie octohunt.com oder X-Ray-Bools (z. B.
site:github.com "terraform landing zone") helfen dir beim Finden relevanter Profile.
🧾 Zertifizierungsverzeichnisse:
-
Microsoft, AWS & Google führen teils offizielle Listen ihrer zertifizierten Professionals.
-
Nutze diese als Startpunkt für Sourcing, z. B. in Kombination mit Standort.
🎤 Events & Speaker-Sourcing:
-
Schau bei Meetups oder Konferenzen (z. B. DevOpsCon, CloudLand, KubeCon), wer als Speaker auftritt.
-
Diese Leute haben meist tiefes Wissen und ein gutes Netzwerk – ideal für Active Sourcing.
💡 LinkedIn anders nutzen:
-
Boolean-Suche nach
("cloud architect" OR "solutions architect") AND (terraform OR TOGAF)liefert bessere Treffer als simples Keyword-Scannen.
Du willst Cloud-Architekt:innen finden, die wirklich tief im Thema sind?
Wir helfen dir nicht nur beim Verstehen – sondern übernehmen auch die gezielte Suche nach Cloud-Expert:innen, die wirklich Verantwortung tragen: Mit technischen Analysen, Tool-Recherche, Active Sourcing auf GitHub & Co. und klarer Bewertung der Skills.
Wenn du willst, übernehmen wir das Recruiting für dich – treffsicher, technisch fundiert und schnell.
📥 Lade dir hier kostenlos unseren PDF-Guide mit praktischer Checkliste, Interviewfragen und Sourcing-Tipps herunter:
👉 „Cloud-Architekt:innen richtig lesen – Cheatsheet für Recruiter:innen“
