Interviewfragen für Cloud Engineers, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Antworte in den Begriffen des Anbieters, den die Anzeige nennt, und füge einen eigenen Fall hinzu: was du gebaut hast, für wie viele Teams, was schiefging und was es gekostet hat. Kennst du einen anderen Anbieter besser, sag das und übertrage die Idee; Interviewer schätzen die Idee mehr als den Produktnamen.

Was ein Cloud Engineer können muss

• Grundlagen: Accounts oder Subscriptions, Identitäten und Rollen, Policies und die geteilte Verantwortung zwischen Anbieter und Kunde.
• Netze: Adressbereiche, Subnetze, Routing, Firewalls, Private Endpoints, DNS und die Verbindung zu den eigenen Standorten der Firma.
• Code und Änderungen: Infrastructure as CodeIn 40 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Module schreiben und prüfen, den State sicher halten, vor dem Apply planen und Abweichungen zwischen Code und Cloud finden., State, Reviews und Pipelines in CI/CDIn 66 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Pipelines, die Änderungen an der Infrastruktur jedes Mal gleich testen und ausrollen, mit einem Review vor dem Apply..
• Zuverlässigkeit: Availability Zones und Regionen, Backups, Disaster Recovery und MonitoringIn 9 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Metriken sammeln und bei dem alarmieren, was Nutzer spüren; oft neben den Monitoring-Werkzeugen der Anbieter..
• Workloads und Geld: virtuelle Maschinen, ContainerIn 60 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Workloads auf einem verwalteten Cluster betreiben: Deployments, Skalierung, Netzwerk, Secrets und Upgrades des Clusters., Serverless Functions, verwaltete Datenbanken und was jedes davon auf AWSIn 52 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Konten und Organisationen, Identitäten und Rollen, Netze, Rechenleistung, Speicher, verwaltete Datenbanken und die Rechnung. je nach Anbieter, AzureIn 47 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Subscriptions und Management Groups, Entra ID für Identitäten, virtuelle Netze, Richtlinien und die Kostenberichte. je nach Anbieter oder Google CloudIn 25 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Projekte und Ordner, Identitäten und Zugriffe, Netze, Rechenleistung und die verwalteten Dienste, auf denen Teams aufbauen. je nach Anbieter kostet.

Grundlagen: Verantwortung, Landing Zones, Identitäten und Netze

Was bedeutet das Shared Responsibility Model für deine tägliche Arbeit?

Worauf sie achten: dass du weißt, wo die Pflicht des Anbieters endet und deine beginnt.

Kurze Antwort: „Das Shared Responsibility Model, das Modell der geteilten Verantwortung, teilt die Arbeit auf: Der Anbieter sichert Gebäude, Hardware und die Dienste, die er betreibt; wir sichern, was wir darauf setzen, etwa Identitäten, Netzwerkregeln, Daten, die Einstellungen jedes Dienstes und unsere eigenen Server. Je verwalteter der Dienst, desto weniger ist unseres, aber Zugriff und Daten sind immer unsere Sache.“

Die ausführliche Antwort: Die meisten Sicherheitsvorfälle in der Cloud kommen von der Seite des Kunden: ein Speicher-Bucket, der öffentlich geblieben ist, ein Schlüssel in einem Repository, ein Konto mit viel zu vielen Rechten. Die tägliche Arbeit sind also Leitplanken, die solche Fehler verhindern, Logging, das zeigt, wer was getan hat, und Reviews von Änderungen. Bei einer virtuellen Maschine patchst du das Betriebssystem selbst; bei einer verwalteten Datenbank patcht der Anbieter, und du entscheidest trotzdem, wer sich verbinden darf.

Schwache Antwort: „Der Anbieter kümmert sich um die Sicherheit, deshalb sind wir umgezogen.“ Nachfrage: „Wer patcht ein Container-Image, das wir gebaut haben?“ Wir: Der Anbieter betreibt die Plattform, das Image gehört uns.

Eine Firma fängt in der Cloud an. Wie würdest du die Landing Zone aufbauen?

Worauf sie achten: dass du mit Struktur und Leitplanken anfängst, nicht mit dem ersten Workload.

Kurze Antwort: „Eine Landing Zone ist der vorbereitete Boden, auf dem jedes Team baut: eine Struktur von Accounts oder Subscriptions nach Umgebung und Team, zentrale Identitäten mit Single Sign-on, zentrales Logging, das Teams nicht abschalten können, ein Netzdesign mit gemeinsamen Verbindungen, Policies, die riskante Einstellungen blockieren, und ein Budget und Tags an jedem Konto. Ich baue sie als Code, damit ein neues Team in einer Stunde dieselbe Umgebung bekommt.“

Die ausführliche Antwort: Jeder Anbieter hat dafür einen Startbaukasten, und viele Firmen passen einen an, statt bei null anzufangen. Trenne die Produktion vom Rest, halte ein Notfallkonto für den Ernstfall bereit, ein Break-Glass-Konto, und entscheide früh, wie Teams ein neues Konto beantragen. Schreib die wenigen Regeln auf, über die nicht verhandelt wird, etwa kein öffentlicher Speicher und keine Schlüssel für Personen, und lass die Teams den Rest entscheiden.

Schwache Antwort: „Alle arbeiten in einem gemeinsamen Konto, aufteilen können wir später.“ Nachfrage: „Ein Team braucht eine Ausnahme von einer Policy.“ Erkläre, wie Ausnahmen beantragt, freigegeben, zeitlich begrenzt und festgehalten werden.

Wie verwaltest du Identitäten und Zugriffe, und wie hältst du Least Privilege in der Praxis ein?

Worauf sie achten: dass Identität deine erste Kontrolle ist und dass du sie über die Zeit aufgeräumt halten kannst.

Kurze Antwort: „Menschen melden sich über den Identity Provider der Firma mit Multi-Faktor-Authentifizierung an und bekommen Rollen, keine persönlichen Schlüssel. Workloads bekommen eigene Identitäten mit nur den Rechten, die sie brauchen, Least Privilege, und keine langlebigen Secrets. Ich prüfe die Rechte regelmäßig und entferne, was nicht genutzt wurde.“

Die ausführliche Antwort: Geh von Gruppen und Rollen aus, die zu Aufgaben passen, vergib Admin-Rechte nur befristet und mit Begründung und alarmiere bei der Nutzung der Root- oder Owner-Konten. Die Anbieter können berichten, welche Berechtigungen eine Rolle nie genutzt hat; dort lässt sich am leichtesten kürzen. Least Privilege ist nie fertig, also mach das Review zur Routine, nicht zum Projekt.

Schwache Antwort: „Die Entwickler haben Admin-Rechte, damit sie nicht blockiert sind.“ Nachfrage: „Der Laptop eines Entwicklers wird gestohlen.“ Erkläre, was sein Zugriff erreichen konnte und wie du ihn kappen würdest.

Entwirf das Netz für eine Anwendung, die die Büros der Firma erreichen muss, aber nicht das Internet.

Worauf sie achten: Subnetze, Routing und private Verbindungen, ohne aus Versehen einen öffentlichen Weg.

Kurze Antwort: „Ich setze die Anwendung in private Subnetze ohne Route ins Internet, erreiche die Dienste des Anbieters über Private Endpoints und verbinde die Büros über ein VPN oder eine Standleitung mit einem zentralen Hub-Netz. Firewall-Regeln erlauben nur die nötigen Ports, und DNS löst die privaten Namen auf beiden Seiten auf.“

Die ausführliche Antwort: Plane Adressbereiche, die sich nicht mit den Büros oder mit anderen Netzen überschneiden, die du später vielleicht anbindest; Überschneidungen zu beheben ist mühsam. Ein Hub-and-Spoke-Design hält gemeinsame Verbindungen und die Prüfung des Verkehrs an einer Stelle. Updates für Server brauchen trotzdem einen Weg hinein, über einen Proxy oder einen privaten Spiegel. Logge die Netzwerkflüsse, damit du einem Prüfer zeigen kannst, dass nichts über einen anderen Weg hinausging.

Schwache Antwort: „Ich öffne die Security Group für alles und schränke sie später ein.“ Nachfrage: „Zwei Netze müssen miteinander sprechen, aber ihre Adressbereiche überschneiden sich.“ Sprich über Adressübersetzung oder neue Adressen und warum eine frühe Planung der Bereiche das vermeidet.

Infrastructure as Code, Pipelines und Secrets

Warum Infrastructure as Code, und wie gehst du mit State und Drift um?

Worauf sie achten: dass du Code für Wiederholbarkeit und Review nutzt und seine Schwachstellen kennst.

Kurze Antwort: „Infrastructure as Code heißt, die Umgebung ist in Dateien beschrieben, wird wie Software reviewt und von einer Pipeline angewendet, damit Umgebungen übereinstimmen und jede Änderung eine Geschichte hat. Bei TerraformIn 40 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Module schreiben und prüfen, den State sicher halten, vor dem Apply planen und Abweichungen zwischen Code und Cloud finden. hält die State-Datei fest, was existiert, also lege ich sie in einen gesperrten, verschlüsselten Remote-Speicher. Drift, eine Änderung außerhalb des Codes, finde ich mit einem regelmäßigen Plan und übernehme sie entweder in den Code oder mache sie rückgängig.“

Die ausführliche Antwort: Die Werkzeuge unterscheiden sich: Terraform und Pulumi arbeiten über Anbieter hinweg, CloudFormation gehört zu AWS und Bicep zu Azure, und jeder Anbieter hat seine eigene native Option. Die Gewohnheiten sind dieselben: kleine Module mit klaren Eingaben, festgeschriebene Versionen, ein Plan, den eine zweite Person vor dem Apply liest, und niemand mit Rechten, die Produktion von Hand zu ändern, außer im Notfall, der dann in den Code zurückgeschrieben wird.

Schwache Antwort: „Ich behebe Dinge in der Konsole und passe den Code an, wenn ich Zeit habe.“ Nachfrage: „Zwei Pipelines haben gleichzeitig denselben State geändert.“ Erkläre das Sperren und warum jeder State einen einzigen Verantwortlichen haben sollte.

Wie rollst du eine Änderung an der Infrastruktur sicher aus?

Worauf sie achten: eine Gewohnheit für Releases der Infrastruktur, die den Wirkungsbereich begrenzt.

Kurze Antwort: „Die Änderung geht über einen Merge Request mit angehängtem Plan, automatischen Prüfungen auf Policies und Sicherheit und einem Review, dann in dieser Reihenfolge durch Entwicklung, Test und Produktion. Riskante Änderungen gehen in einer ruhigen Stunde hinaus, mit einem aufgeschriebenen Rollback, und ich beobachte danach die Dashboards.“

Die ausführliche Antwort: Lies den Plan auf alles, was zerstört und neu angelegt wird, denn eine kleine Änderung im Code kann eine Datenbank ersetzen. Teile große Änderungen auf und schütze wichtige Ressourcen vor dem Löschen. Prüfungen von Policies in der Pipeline fangen öffentlichen Zugriff oder fehlende Verschlüsselung ab, bevor ein Mensch es muss. Schreib auf, wer Änderungen an der Produktion freigibt und wann Änderungen eingefroren sind, zum Beispiel während einer Verkaufsspitze.

Schwache Antwort: „Wenn der Plan durchläuft, ist es sicher.“ Nachfrage: „Der Plan zeigt, dass der Load Balancer ersetzt wird.“ Erkläre, warum das wichtig ist und wie du einen Ausfall vermeiden würdest.

Wie speicherst und rotierst du Secrets und Schlüssel, und wie schützt du Daten mit Verschlüsselung?

Worauf sie achten: keine Secrets im Code und Verschlüsselung, die du erklären kannst.

Kurze Antwort: „Secrets liegen im Secret Store des Anbieters oder in einem Vault, werden zur Laufzeit von den Identitäten gelesen, die sie brauchen, und nach Plan rotiert oder wenn jemand geht. Wo immer möglich, nutzen Workloads ihre eigene Identität statt überhaupt eines Secrets. Daten werden gespeichert und bei der Übertragung verschlüsselt, mit Schlüsseln im Schlüsseldienst, und der Zugriff auf die Schlüssel wird protokolliert.“

Die ausführliche Antwort: Durchsuche Repositories und Images nach Secrets, denn ein einziger durchgesickerter Schlüssel kann mehr kosten als ein Jahr Cloud-Rechnung. Entscheide, wer die Schlüssel kontrolliert: die Standardschlüssel des Anbieters oder Schlüssel, die die Firma selbst verwaltet, wie es manche regulierte Firmen verlangen. Plane, was passiert, wenn ein Schlüssel gelöscht wird, denn verschlüsselte Daten ohne ihren Schlüssel sind verloren.

Schwache Antwort: „Das Passwort steht in einer Umgebungsdatei im Repository, das ist privat.“ Nachfrage: „Vor einer Stunde wurde ein Schlüssel in ein öffentliches Repository gepusht.“ Zuerst widerrufen, dann in den Logs nach Nutzung suchen, dann die Gewohnheit ändern.

Verfügbarkeit, Wiederherstellung, Monitoring und Störungen

Wie entwirfst du Hochverfügbarkeit über Availability Zones und Regionen hinweg?

Worauf sie achten: dass du das Design an das anpasst, was das Geschäft braucht und bezahlt.

Kurze Antwort: „Eine Availability Zone ist ein eigenes Rechenzentrum innerhalb einer Region, also verteile ich Server und verwaltete Dienste hinter einem Load Balancer über mindestens zwei Zonen; das deckt die meisten Ausfälle ab. Eine zweite Region schützt vor dem Ausfall einer ganzen Region, kostet aber mehr und ist schwieriger, also nutze ich sie nur, wenn das Geschäft sie braucht.“

Die ausführliche Antwort: Geh von den vereinbarten Zielen aus: wie lange der Dienst ausfallen und wie viele Daten er verlieren darf. Viele verwaltete Dienste bieten eine zonenredundante Option per Schalter. Achte auf die Teile, die nicht verteilt sind, etwa ein einzelnes NAT Gateway oder eine einzelne Datenbankinstanz. Eine zweite Region braucht kopierte Daten, Namen, die umziehen, und eine getestete Umschaltung; ohne Test ist sie eine Hoffnung.

Schwache Antwort: „Wir sind in der Cloud, also ist alles immer verfügbar.“ Nachfrage: „Die Region des Anbieters fällt vier Stunden lang aus.“ Sag, was dein Design dann tut und was es kosten würde, mehr zu tun.

Plane Backup und Disaster Recovery für ein kritisches System.

Worauf sie achten: Ziele für die Wiederherstellung, Kopien außerhalb des Wirkungsbereichs und getestete Wiederherstellungen.

Kurze Antwort: „Ich vereinbare mit den Verantwortlichen zwei Werte: das Recovery Point Objective, wie viele Daten verloren gehen dürfen, und das Recovery Time Objective, wie lange die Wiederherstellung dauern darf. Dann richte ich die Backups danach aus, halte Kopien in einem anderen Konto und einer anderen Region, die normale Admins nicht löschen können, und führe nach Plan eine Wiederherstellung durch, um zu beweisen, dass es funktioniert.“

Die ausführliche Antwort: Ransomware und ein gestohlenes Admin-Konto sind die Fälle, für die du entwirfst, also zählen unveränderliche oder gesperrte Backups. Disaster Recovery braucht auch die Infrastruktur selbst, und genau hier zahlt sich Infrastructure as Code aus: Du kannst die Umgebung aus Code neu bauen und die Daten hineinspielen. Schreib das Runbook, übe es mindestens einmal im Jahr und miss die Zeit.

Schwache Antwort: „Der Anbieter hält von allem drei Kopien.“ Nachfrage: „Jemand hat das Produktionskonto gelöscht.“ Erkläre, wo deine Kopien liegen und wer sie noch erreichen könnte.

Was überwachst du in der Cloud, und was sollte jemanden nachts wecken?

Worauf sie achten: Alarme, die auf die Wirkung bei Nutzern und echtes Risiko zeigen, nicht auf Lärm.

Kurze Antwort: „Ich beobachte, was Nutzer spüren, etwa Fehler und Antwortzeiten, dazu die Zeichen der Plattform, die vor Ärger kommen: volle Platten, fehlschlagende Health Checks, Grenzen von Quotas, ablaufende Zertifikate, und die Zeichen für Sicherheit, etwa eine Root-Anmeldung oder eine abgeschaltete Policy. Nur was jetzt Handeln braucht, alarmiert jemanden; der Rest geht in eine tägliche Durchsicht.“

Die ausführliche Antwort: Nutze Monitoring und Logging des Anbieters, oft zusammen mit PrometheusIn 9 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Metriken sammeln und bei dem alarmieren, was Nutzer spüren; oft neben den Monitoring-Werkzeugen der Anbieter. und Grafana oder einem anderen Werkzeug über Anbieter hinweg, und halte die Logs zentral, damit eine Suche jedes Konto abdeckt. Jeder Alarm braucht einen Verantwortlichen und ein Runbook. Auch Kosten sind ein Signal: Ein Alarm bei ungewöhnlichen Tagesausgaben fängt durchgesickerte Schlüssel und außer Kontrolle geratene Jobs ab.

Schwache Antwort: „Wir alarmieren bei einer CPU über achtzig.“ Nachfrage: „Die Person in Rufbereitschaft hat letzte Nacht vierzig Alarme bekommen, und keiner war wichtig.“ Sortiere sie danach, welches Handeln sie brauchen, und entferne oder justiere den Rest.

Ein produktiver Dienst ist nach einer Änderung an der Cloud-Umgebung ausgefallen. Führ uns durch die Störung.

Worauf sie achten: ruhige Ordnung: den Dienst wiederherstellen, kommunizieren, dann ohne Schuldzuweisung die Ursache finden.

Kurze Antwort: „Ich bestätige die Auswirkung, eröffne eine Störung und sage, wer leitet. Der schnellste sichere Weg zurück ist meist, die Änderung über die Pipeline zurückzurollen. Ich führe eine Zeitleiste und veröffentliche Updates. Sobald der Dienst wieder läuft, halten wir ein Review ohne Schuldzuweisung und schließen die Lücke, die die Änderung durchgelassen hat, etwa eine fehlende Prüfung oder einen fehlenden Test.“

Die ausführliche Antwort: Schau zuerst, was sich geändert hat: die Historie der Pipeline, das Audit-Log des Anbieters und seine eigene Statusseite, falls der Fehler bei ihm liegt. Mach unter Druck nicht mehrere Änderungen gleichzeitig. Das Review fragt, warum die Änderung sicher wirkte, und die Maßnahmen machen die nächste Änderung sicherer, nicht einen Menschen vorsichtiger.

Schwache Antwort: „Ich behebe es schnell in der Konsole und sage es niemandem.“ Nachfrage: „Der Rollback schlägt fehl.“ Erkläre, wie du aus Code oder Backups wiederherstellen und wen du hinzuziehen würdest.

Kosten, Workloads, Migration und mehr als eine Cloud

Die Cloud-Kosten sind diesen Monat stark gestiegen. Wie findest du heraus, warum, und wie senkst du sie?

Worauf sie achten: dass du die Rechnung lesen kannst und Kosten als Eigenschaft des Designs behandelst.

Kurze Antwort: „Ich schlüssele die Rechnung nach Dienst, Konto und Tag auf, um zu finden, was gewachsen ist, und frage dann den Verantwortlichen, warum. Häufige Ursachen sind vergessene Testressourcen, zu große Server, Daten, die zwischen Regionen oder ins Internet fließen, und Logs, die ewig aufbewahrt werden. Ich behebe die Ursache, setze Budgets und Alarme und mache Tagging zur Pflicht, damit sich die nächste Rechnung lesen lässt.“

Die ausführliche Antwort: Die Arbeit an den Kosten, oft FinOps genannt, teilst du dir mit der Finanzabteilung und den Teams. Gleichmäßige Last kann Zusagen oder reservierte Kapazität für einen niedrigeren Preis nutzen; kurze Jobs können freie Kapazität nutzen, die der Anbieter zurückfordern darf. Schalte Entwicklungsumgebungen nachts ab. Zeig jedem Team jeden Monat seine eigenen Ausgaben, denn Menschen steuern, was sie sehen können.

Schwache Antwort: „Die Cloud ist teuer, da kann man nichts machen.“ Nachfrage: „Die Finanzabteilung will eine Prognose für nächstes Jahr.“ Erkläre, wie du sie aus den aktuellen Ausgaben, dem Wachstum und den geplanten Projekten aufbauen würdest.

Virtuelle Maschinen, Container oder Serverless: Wie wählst du für einen neuen Dienst?

Worauf sie achten: eine Wahl nach dem Workload und dem Team, nicht nach der Mode.

Kurze Antwort: „Serverless Functions passen zu kurzer, ereignisgesteuerter Arbeit, die ab und zu läuft: keine Server zum Patchen, Kosten nur bei Ausführung, aber Grenzen bei der Laufzeit. Container passen zu Diensten, die ständig laufen und Kontrolle brauchen, auf einer verwalteten Plattform oder auf KubernetesIn 60 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Workloads auf einem verwalteten Cluster betreiben: Deployments, Skalierung, Netzwerk, Secrets und Upgrades des Clusters., wenn die Firma schon eines betreibt. Virtuelle Maschinen sind für Software, die einen ganzen Server braucht.“

Die ausführliche Antwort: Frag, wer es nachts betreibt. Kubernetes ist mächtig und braucht Menschen, die es kennen; ein verwalteter Container-Dienst reicht vielleicht. Serverless verlagert Arbeit zum Anbieter und bindet dich enger an ihn. Container, die mit DockerIn 33 % der Anzeigen für Cloud Engineer gefragt (Stand 05.11.2026).Kleine, sichere Container-Images bauen und wissen, was darin läuft, bevor sie in Produktion gehen. gebaut sind, lassen sich leichter zwischen Anbietern mitnehmen als Functions. Schreib die Entscheidung mit ihren Gründen auf, damit sie sich später überprüfen lässt.

Schwache Antwort: „Kubernetes für alles, das ist der Standard.“ Nachfrage: „Die Function läuft zwanzig Minuten.“ Erkläre die Zeitgrenzen und was du stattdessen nutzen würdest.

Wie würdest du eine Anwendung aus dem Rechenzentrum der Firma in die Cloud migrieren?

Worauf sie achten: ein Plan in Etappen mit wenig Risiko und ehrliche Entscheidungen darüber, wie viel sich ändern soll.

Kurze Antwort: „Zuerst erfasse ich, was die Anwendung braucht: Server, Daten, Netzwerkverbindungen, Lizenzen und wer sie nutzt. Dann entscheiden wir mit den Verantwortlichen, ob wir sie so umziehen, wie sie ist, sie an verwaltete Dienste anpassen oder neu bauen. Die Daten ziehen mit laufender Kopie um, wir testen in der Cloud, und die Umstellung ist kurz und hat einen Weg zurück.“

Die ausführliche Antwort: Zieh zuerst einfache Anwendungen um, um zu lernen, und heb die am stärksten verflochtenen für später auf. Lizenzen können den Weg bestimmen, weil sich manche nicht mitnehmen lassen. Prüf die Netzwerklatenz zu Systemen, die zurückbleiben. Schalte nach dem Umzug die alten Server zu einem festen Datum ab, sonst zahlt die Firma doppelt. Jeder Anbieter hat Werkzeuge für die Migration; der Plan zählt mehr als das Werkzeug.

Schwache Antwort: „Wir kopieren alle Server an einem Wochenende hinüber.“ Nachfrage: „Die Anwendung spricht mit einem Mainframe, der bleibt.“ Sprich über die Netzwerkverbindung, die Latenz und was du testen würdest.

Sollte eine Firma mehr als eine Cloud nutzen? Wie beantwortest du die Frage nach Multi-Cloud?

Worauf sie achten: ein ausgewogener Blick auf Kosten, Fähigkeiten und Risiko, ohne Lieblingsanbieter.

Kurze Antwort: „Viele Firmen nutzen mehr als einen Anbieter, wegen ihrer Geschichte, eines Zukaufs oder eines einzelnen Dienstes, den sie brauchen, und das ist in Ordnung. Dasselbe System gleichzeitig auf zwei Clouds zu betreiben, ist teuer und lohnt sich selten. Ich halte die gemeinsamen Teile gemeinsam, etwa Identitäten, Terraform und Logging, und lasse jeden Workload seinen Anbieter gut nutzen.“

Die ausführliche Antwort: AWS, Azure und Google Cloud decken alle die üblichen Bedürfnisse ab; die Wahl hängt an bestehenden Verträgen, den Fähigkeiten des Teams, Regeln für Daten und den Diensten, die ein Produkt braucht. Plane einen Ausstieg für die kritischsten Systeme: wissen, wo die Daten liegen, wie sie umziehen würden und ungefähr, was es kosten würde, wonach manche Aufsichtsbehörden fragen. Lass die Entscheidung schriftlich bei den Architekten und der Finanzabteilung.

Schwache Antwort: „Immer zwei Clouds, damit wir nie gebunden sind.“ Nachfrage: „Die Geschäftsleitung fragt, was passiert, wenn unser Anbieter uns im Stich lässt.“ Zeig den Ausstiegsplan und seine Kosten.

Wie würdest du als Senior Cloud Engineer oder Cloud-Architekt Standards für viele Teams setzen?

Worauf sie achten: dass du führen kannst, ohne zu blockieren, über eine Plattform und klare Regeln.

Kurze Antwort: „Ich biete einen befestigten Weg an, eine Paved Road: Module, Vorlagen und Pipelines, die den sicheren Weg zum einfachen machen, mit wenigen Regeln, die über Policies durchgesetzt werden, und dem Rest als Empfehlung. Ich schreibe Entscheidungen auf, prüfe Designs früh mit den Teams und messe Nutzung, Störungen und Kosten, nicht die Zahl geschlossener Tickets.“

Die ausführliche Antwort: Auf der Stufe von Principal Cloud Architect und Head of Cloud drehen sich die Fragen um Menschen und Geld: die Roadmap der Plattform, Verträge mit Anbietern, Nachweise zu Sicherheit und Compliance für Audits und wie viele Engineers die Plattform braucht. Rechne mit einer Fallstudie wie „drei Teams haben drei verschiedene Landing Zones gebaut“ und erkläre, wie du sie zusammenführen würdest, ohne ihre Arbeit anzuhalten.

Schwache Antwort: „Teams müssen das Cloud-Team um jede Ressource bitten.“ Nachfrage: „Ein Team sagt, dein Modul bremst es.“ Hör zu, miss und ändere das Modul oder die Regel.

Dein Lebenslauf für diese Fragen

Jedes Cloud-Projekt in deinem Lebenslauf lädt zu den Fragen oben ein: welcher Anbieter, wie viele Konten, was es gekostet hat, was ausgefallen ist und was du geändert hast. Schreib jede Geschichte als eine Zeile unter die Stelle, an der sie passiert ist, damit der Interviewer danach fragt:

Mach die kostenlose Prüfung an einem Cloud-Job, den du willst: Jeder Skill, der dabei fehlt, ist eine Frage, mit der du rechnen kannst, also bereite diese Geschichten vor den anderen vor.