Interviewfragen für Platform Engineers, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Antworte mit einer Plattform, die du gebaut oder betrieben hast: wer sie genutzt hat, was sie den Nutzern gebracht hat, worüber sie sich beschwert haben und was du geändert hast. Interviewer hören darauf, ob du Entwickler als Kunden behandelst, mit Zahlen zur Nutzung und zur gesparten Zeit.

Was ein Platform Engineer können muss

• Das Produkt: die interne Entwicklerplattform, Golden Paths, Self-Service, Developer Experience und Akzeptanz.
• Der Boden: KubernetesIn 63 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Gemeinsame Cluster für viele Teams betreiben: Namespaces, Quotas, Netzwerkregeln, Operatoren und Upgrades ohne Ausfall. für viele Teams, Infrastructure as Code mit TerraformIn 35 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Module, die andere Teams wiederverwenden, sicher abgelegter State, feste Versionen und Pläne, die vor dem Apply geprüft werden. oder einem anderen Werkzeug, auf AWSIn 29 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Konten, Identitäten, Netze und die verwalteten Dienste, die die Plattform den Teams anbietet, und ihre Kosten. je nach Anbieter, AzureIn 31 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Subscriptions, Identitäten und die verwalteten Dienste, die die Plattform in einer Microsoft-Umgebung für Teams bündelt. je nach Anbieter oder Google CloudIn 14 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Projekte, Identitäten und verwaltetes Kubernetes in Google Cloud, den Teams über die Plattform angeboten. je nach Anbieter.
• Auslieferung: gemeinsame CI/CDIn 64 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Gemeinsame Pipeline-Vorlagen, die jeden Dienst auf dieselbe Weise bauen, testen, scannen und ausrollen.-Vorlagen, GitOps, Secrets und Policy as Code.
• Betrieb: Observability mit PrometheusIn 14 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Metriken für die Plattform selbst und die Standards, die jeder Dienst bekommt, mit Grafana-Dashboards darauf. oder Ähnlichem, Upgrades, Rufbereitschaft, Kosten und Sicherheit.

Die Plattform als Produkt

Was ist eine interne Entwicklerplattform, und warum betreibst du sie als Produkt?

Worauf sie achten: dass du für Nutzer baust, nicht eine Sammlung von Werkzeugen.

Kurze Antwort: „Eine interne Entwicklerplattform ist die Menge gemeinsamer Werkzeuge und Dienste, mit denen Produktteams Software selbst anlegen, ausliefern und betreiben: Cluster, Pipelines, Vorlagen, Secrets, Monitoring. Plattform als Produkt heißt, wir behandeln die Entwickler als Kunden: Wir finden heraus, was sie bremst, veröffentlichen eine Roadmap, schreiben Dokumentation und messen, ob sie sich dafür entscheiden, sie zu nutzen.“

Die ausführliche Antwort: Eine Plattform, die ohne ihre Nutzer gebaut wird, endet als Pflichthürde, um die Teams herumarbeiten. Sprich mit Teams, schau zu, wie ein neuer Dienst eingerichtet wird, und fang mit dem Schritt an, der am meisten wehtut. Das Ziel ist weniger kognitive Last für Entwickler: weniger Dinge, die jedes Team wissen muss, um sicher auszuliefern. Ein Entwicklerportal wie Backstage, Port oder Humanitec kann die Eingangstür sein; zum Start reichen oft ein Wiki und gute Vorlagen.

Schwache Antwort: „Wir installieren Kubernetes und sagen den Teams, sie sollen es nutzen.“ Nachfrage: „Woran erkennst du, dass die Plattform funktioniert?“ Nenne die Kennzahlen, die du verfolgen würdest.

Wie würdest du einen Golden Path für einen neuen Dienst entwerfen, mit Vorlagen, denen Teams vertrauen können?

Worauf sie achten: ein unterstützter Standard, der schnell und sicher ist und trotzdem Raum lässt.

Kurze Antwort: „Ein Golden Path ist der unterstützte Weg, eine häufige Art von Dienst zu bauen, etwa eine Web-API: Eine Vorlage legt das Repository an, mit Pipeline, Tests, Container-Build, Monitoring, Secrets und Deployment schon eingerichtet. Ein Team kann den Weg verlassen, verantwortet dann aber selbst, was es baut. Ich halte die Vorlagen versioniert, damit Updates auch Dienste erreichen, die schon angelegt sind.“

Die ausführliche Antwort: Fang mit den zwei oder drei Arten von Diensten an, die die meisten Teams bauen, nicht mit jedem Fall. Vorlagen verrotten, wenn sie niemandem gehören und Änderungen alte Dienste nicht erreichen, also plane, wie ein Update der Vorlage in bestehende Repositories fließt. Ein Katalog der Dienste zeigt dann, welche Dienste welchem Weg folgen und wem sie gehören.

Schwache Antwort: „Eine Vorlage für alles.“ Nachfrage: „Ein Team braucht einen Batch-Job, keine API.“ Erkläre, wann du einen neuen Weg hinzufügst und wann du Nein sagst.

Wie gibst du Teams Self-Service, ohne die Kontrolle zu verlieren?

Worauf sie achten: Leitplanken, die über Policies wirken, nicht über Tickets.

Kurze Antwort: „Self-Service heißt, ein Team bekommt eine Datenbank, einen Namespace oder eine Pipeline selbst, in Minuten, über eine Vorlage, einen Merge Request oder ein Portal. Die Kontrolle kommt aus den Standardwerten und aus Policies, die automatisch geprüft werden: freigegebene Einstellungen, Quotas, Verschlüsselung an, kein öffentlicher Zugriff. Ausnahmen sind möglich, werden aber beantragt und festgehalten.“

Die ausführliche Antwort: Eine Ticket-Warteschlange ist das Gegenteil von Self-Service, und das Plattform-Team wird zum Engpass. Lass die Plattform die wenigen Regeln durchsetzen, die zählen, und berate beim Rest. Zeig Teams, was ihnen gehört und was es kostet, damit Freiheit mit Verantwortung kommt.

Schwache Antwort: „Teams öffnen ein Ticket, und wir legen es für sie an.“ Nachfrage: „Die Security will jede neue Datenbank prüfen.“ Erkläre, wie die Policy die Prüfung übernehmen kann.

Wie misst du die Developer Experience und die Akzeptanz der Plattform?

Worauf sie achten: dass du Ergebnisse für Nutzer misst, nicht die Aktivität des Plattform-Teams.

Kurze Antwort: „Ich messe, wie lange ein neuer Dienst bis in die Produktion braucht, wie oft Teams deployen und wie oft Änderungen fehlschlagen, wie viele Teams und Dienste die Golden Paths nutzen und was Entwickler in kurzen, regelmäßigen Umfragen sagen. Sinkende Nutzung oder mehr Umwege zeigen mir, dass der Plattform etwas fehlt.“

Die ausführliche Antwort: Verbinde Zahlen aus den Werkzeugen mit Gesprächen; jedes übersieht, was das andere sieht. Sei vorsichtig mit Kennzahlen über einzelne Entwickler, die Vertrauen beschädigen und in manchen Ländern die Zustimmung der Arbeitnehmervertretung brauchen; in Deutschland bestimmt der Betriebsrat mit, wenn technische Einrichtungen Leistung oder Verhalten der Beschäftigten überwachen können. Teile die Ergebnisse und was du ändern wirst.

Schwache Antwort: „Wir zählen geschlossene Tickets.“ Nachfrage: „Die Nutzung ist bei der Hälfte der Teams stehen geblieben.“ Erkläre, wie du herausfinden würdest, warum.

Kubernetes, Infrastructure as Code und GitOps

Wie betreibst du Kubernetes mit Multi-Tenancy für viele Teams auf gemeinsamen Clustern?

Worauf sie achten: Isolation, Fairness und Sicherheit zwischen Teams auf gemeinsamen Clustern.

Kurze Antwort: „Multi-Tenancy heißt, mehrere Teams teilen sich sicher einen Cluster. Jedes Team bekommt Namespaces mit Quotas, Netzwerkregeln, die Traffic blockieren, den es nicht braucht, Rollen, die auf seinen eigenen Bereich begrenzt sind, und Policies, die riskante Einstellungen ablehnen. Sehr sensible oder laute Workloads bekommen eigene Cluster.“

Die ausführliche Antwort: Entscheide früh zwischen wenigen großen gemeinsamen Clustern und vielen kleinen: Gemeinsame Cluster sind günstiger und schwerer zu isolieren, viele Cluster sind für jedes Team einfacher und teurer im Betrieb. Stell die Kosten pro Team in Rechnung oder zeig sie zumindest. Admission Policies, mit Werkzeugen wie OPA Gatekeeper oder Kyverno, setzen die Regeln an der Tür durch.

Schwache Antwort: „Alle bekommen Cluster-Admin, es sind ja alles Kollegen.“ Nachfrage: „Der Job eines Teams verbraucht den ganzen Speicher eines Nodes.“ Erkläre Quotas und Limits.

Wie planst du Upgrades von Kubernetes und der Plattform, wenn viele Teams von dir abhängen?

Worauf sie achten: Upgrades als Routine, mit Ankündigung, Tests und einem Weg zurück.

Kurze Antwort: „Ich führe einen Kalender der Upgrades, kündige sie früh an, teste sie auf einem Cluster außerhalb der Produktion mit echten Workloads und prüfe, ob Teams noch entfernte Features nutzen. Dann rüste ich Cluster für Cluster auf, angefangen beim am wenigsten kritischen, und halte Kapazität bereit, um Workloads sicher von Nodes wegzuverlegen.“

Die ausführliche Antwort: Zurückzufallen ist das größere Risiko: Der Support endet, und mehrere Versionen müssen auf einmal übersprungen werden. Automatisiere die Prüfungen auf veraltete Einstellungen und gib Teams ein Werkzeug, das zeigt, was sie ändern müssen. Helm Charts und Operatoren, die die Plattform installiert, brauchen dieselbe Disziplin bei Upgrades.

Schwache Antwort: „Wir rüsten auf, wenn etwas kaputtgeht.“ Nachfrage: „Ein Team kann nicht rechtzeitig aktualisieren.“ Erkläre, wie du seine Frist gegen das Support-Fenster abwägst.

Wie verwaltest du Infrastructure as Code im Maßstab einer Plattform, über Module, State und Werkzeuge hinweg?

Worauf sie achten: wiederverwendbare Module, sicherer State und ein fairer Blick auf die Werkzeuge.

Kurze Antwort: „Ich schreibe kleine, versionierte TerraformIn 35 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Module, die andere Teams wiederverwenden, sicher abgelegter State, feste Versionen und Pläne, die vor dem Apply geprüft werden.-Module mit klaren Eingaben, halte den State remote, verschlüsselt und gesperrt und teile ihn auf, damit eine Änderung nicht alles berühren kann. Jede Änderung wird in einer Pipeline geplant und vor dem Apply reviewt. Teams nutzen Module nach Version und aktualisieren, wenn sie bereit sind.“

Die ausführliche Antwort: Die Werkzeuge stehen nebeneinander: Terraform und sein offener Fork OpenTofu, Pulumi in allgemeinen Programmiersprachen und Crossplane, das Cloud-Ressourcen aus Kubernetes heraus verwaltet. Wähle nach den Fähigkeiten des Teams und nach dem, was schon da ist, und vermeide es, ohne Grund drei davon zu betreiben. Erkenne Abweichungen nach einem festen Plan und lege fest, was passiert, wenn jemand etwas von Hand ändert.

Schwache Antwort: „Eine große State-Datei für die ganze Firma.“ Nachfrage: „Eine Änderung an einem Modul würde vierzig Datenbanken neu anlegen.“ Erkläre, wie du sie sicher ausrollen würdest.

Was ist GitOps, und wann würdest du es nutzen?

Worauf sie achten: dass du das Pull-Modell und seine Abwägungen verstehst.

Kurze Antwort: „GitOps heißt, der gewünschte Zustand der Cluster liegt in einem Git-Repository, und ein Agent in jedem Cluster, etwa Argo CD oder Flux, hält den Cluster im Gleichschritt damit. Eine Änderung ist ein Merge Request; ein Rollback ist ein Revert. Es passt zu Kubernetes-Plattformen mit vielen Diensten und Clustern, weil jede Änderung reviewt und festgehalten wird.“

Die ausführliche Antwort: Secrets brauchen Sorgfalt, denn sie sollten nicht im Klartext im Repository liegen. Die Weitergabe zwischen Umgebungen braucht eine klare Struktur im Repository. Nicht alles passt: Cloud-Ressourcen außerhalb des Clusters werden oft weiter über Pipelines angewendet.

Schwache Antwort: „GitOps heißt, wir nutzen Git.“ Nachfrage: „Jemand hat eine Einstellung im Cluster von Hand geändert.“ Erkläre, was der Agent tut und wie du es siehst.

Pipelines, Secrets, Policies und Kosten

Wie baust du CI/CD-Pipelines, die jedes Team nutzen und trotzdem anpassen kann?

Worauf sie achten: gemeinsame Vorlagen, die standardmäßig sicher und leicht zu erweitern sind.

Kurze Antwort: „Ich biete Pipeline-Vorlagen für die häufigen Fälle an, mit Build, Tests, Security-Scans, dem Container-Image und dem Deployment eingebaut, in GitLab CIIn 10 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Eines der verbreiteten Pipeline-Werkzeuge; Vorlagen schreiben, die viele Projekte einbinden. je nach Anbieter, GitHub ActionsIn 8 % der Anzeigen für Platform Engineer gefragt (Stand 05.11.2026).Eines der verbreiteten Pipeline-Werkzeuge; wiederverwendbare Workflows schreiben, die viele Repositorys aufrufen. je nach Anbieter oder was immer die Firma nutzt. Teams binden die Vorlage ein und fügen eigene Schritte hinzu; die Pflichtprüfungen lassen sich nicht entfernen.“

Die ausführliche Antwort: Versioniere die Vorlagen und kündige Änderungen an, denn eine kaputte Vorlage stoppt alle Teams auf einmal. Halte Pipelines schnell; Entwickler merken jede Minute. Signiere Images und führe eine Liste dessen, was in ihnen steckt, wie es Regeln für die Software-Lieferkette immer öfter verlangen.

Schwache Antwort: „Jedes Team schreibt seine eigene Pipeline von Grund auf.“ Nachfrage: „Der Security-Scan verdoppelt die Laufzeit der Pipeline.“ Sprich darüber, wie du ihn beschleunigen oder verlegen würdest.

Wie gehst du auf der ganzen Plattform mit Secrets um?

Worauf sie achten: keine Secrets im Code, Rotation und, wo möglich, Identitäten statt Schlüssel.

Kurze Antwort: „Secrets liegen in einem Secret Store, dem der Cloud oder einem Vault, und erreichen die Workloads zur Laufzeit über deren eigene Identität. Wo die Cloud es erlaubt, nutzen Workloads ihre Identität direkt und brauchen gar kein Secret. Secrets werden nach Plan rotiert, und der Zugriff darauf wird protokolliert.“

Die ausführliche Antwort: Durchsuche Repositories und Images in der Pipeline nach durchgesickerten Secrets. Mach den sicheren Weg zum Standard in den Vorlagen, damit kein Team entscheiden muss. Plane die Rotation so, dass sie nicht für jeden Dienst ein Release braucht.

Schwache Antwort: „Die Secrets liegen im Repository, aber das ist privat.“ Nachfrage: „Vor einer Stunde ist ein Schlüssel durchgesickert.“ Zuerst widerrufen, die Nutzung prüfen, dann den Weg schließen, über den er hinausgelangt ist.

Wie setzt du Policy as Code durch, ohne Teams zu blockieren?

Worauf sie achten: wenige starke Regeln, automatisiert, mit einem klaren Weg, eine Ausnahme zu beantragen.

Kurze Antwort: „Ich schreibe die wenigen Regeln, die nie gebrochen werden dürfen, als Policy, die in der Pipeline und an der Tür des Clusters läuft, etwa kein öffentlicher Speicher, Verschlüsselung an, Images nur aus unserer Registry. Der Rest sind Warnungen mit Rat. Ein Team, das eine Ausnahme braucht, beantragt sie; sie wird für eine bestimmte Zeit freigegeben und festgehalten.“

Die ausführliche Antwort: Starte Regeln im Warnmodus, behebe die bestehenden Verstöße mit den Teams und schalte dann auf Blockieren um. Schreib den Grund neben jede Regel. Policies, die ohne Erklärung blockieren, machen das Plattform-Team zum Feind.

Schwache Antwort: „Wir blockieren alles, was nicht freigegeben ist.“ Nachfrage: „Eine Regel stoppt ein Release am Freitagabend.“ Erkläre den Weg zur Ausnahme.

Wie hältst du die Kosten der Plattform im Griff und zeigst sie den Teams?

Worauf sie achten: Kosten als Eigenschaft des Designs, mit Verantwortlichen.

Kurze Antwort: „Ich versehe jede Ressource mit einem Tag oder Label für ihr Team und ihren Dienst, zeige jedem Team jeden Monat seine eigenen Kosten, setze Requests und Limits, damit Cluster nicht zu groß sind, und skaliere alles außerhalb der Produktion nachts herunter. Gemeinsame Kosten werden nach einer einfachen Regel aufgeteilt, die alle kennen.“

Die ausführliche Antwort: Auch die Plattform selbst kostet: Vergleiche das mit dem, was Teams ausgeben würden, wenn sie dasselbe allein bauen. Zusagen beim Cloud-Anbieter senken den Preis für gleichmäßige Last. Dashboards zu den Kosten neben dem Katalog der Dienste machen den Verantwortlichen sichtbar.

Schwache Antwort: „Kosten sind das Problem der Finanzabteilung.“ Nachfrage: „Die Kosten eines Teams haben sich verdreifacht.“ Erkläre, wie du herausfinden würdest, was sich geändert hat.

Rufbereitschaft, Migration und die Roadmap

Wie richtest du die Rufbereitschaft für die Plattform ein, und wie teilst du die Verantwortung mit Produktteams und SREs?

Worauf sie achten: klare Zuständigkeit in der Nacht, aufgeschrieben, bevor sie gebraucht wird.

Kurze Antwort: „Das Plattform-Team ist in Rufbereitschaft für die Plattform selbst: Cluster, Pipelines, gemeinsame Dienste. Produktteams sind in Rufbereitschaft für ihre eigenen Dienste, unterstützt von SREs, wo die Firma welche hat. Der Katalog der Dienste sagt, wem was gehört, und Runbooks sagen, wann eine Störung übergeben wird.“

Die ausführliche Antwort: Ohne diese Linie beginnt jede Störung mit der Suche nach dem Verantwortlichen. Verfolge die Alarme für das Plattform-Team; kommen die meisten aus den Fehlern eines einzigen Teams, verbessere die Leitplanke. Ein gemeinsamer Prozess für Störungen über Plattform, SRE und Produktteams vermeidet zwei Prozesse in einem Ausfall.

Schwache Antwort: „Das Plattform-Team ist in Rufbereitschaft für alles, was darauf läuft.“ Nachfrage: „Der Dienst eines Teams fällt wegen einer Änderung am Cluster aus.“ Erkläre, wer leitet und wie.

Plane die Migration von fünfzig Diensten auf die neue Plattform.

Worauf sie achten: ein Plan in Wellen, der Vertrauen gewinnt, mit Hilfe für die Teams.

Kurze Antwort: „Ich fange mit zwei oder drei wohlgesinnten Teams mit einfachen Diensten an, lerne von ihnen und verbessere die Plattform vor der nächsten Welle. Jede Welle hat ein Datum, eine Checkliste und Engineers aus dem Plattform-Team, die beim Produktteam sitzen. Die alte Umgebung wird an einem Datum abgeschaltet, das zu Beginn vereinbart wurde.“

Die ausführliche Antwort: Mach den Umzug für die Teams lohnend: schnellere Pipelines, weniger Rufbereitschaft, Dinge, die sie nicht mehr verantworten müssen. Heb die schwierigsten Dienste für den Schluss auf, wenn sich die Plattform bewährt hat. Verfolge den Fortschritt offen und akzeptiere, dass ein paar Dienste vielleicht nie umziehen und einen eigenen Plan brauchen.

Schwache Antwort: „Wir kündigen eine Frist an, und die Teams ziehen selbst um.“ Nachfrage: „Zwei Teams weigern sich umzuziehen.“ Erkläre, wie du den Grund herausfinden und was du anbieten würdest.

Wie würdest du als Staff Platform Engineer oder Platform Engineering Manager die Roadmap der Plattform aufbauen?

Worauf sie achten: Prioritäten aus Belegen und den Mut, Nein zu sagen.

Kurze Antwort: „Ich sammle, was Teams brauchen, aus Umfragen, Störungen, Supportanfragen und den Plänen der Firma, schätze Nutzen und Aufwand und veröffentliche eine Roadmap nach Quartalen mit wenigen klaren Wetten. Ich sage genauso klar, was wir nicht tun, wie was wir tun. Über den Fortschritt berichte ich in den Kennzahlen, die den Teams wichtig sind.“

Die ausführliche Antwort: Auf der Stufe des Staff Platform Engineers besteht die Arbeit aus dem Design des Kerns der Plattform und den Standards über Teams hinweg; als Platform Engineering Manager und später Head of Platform sind es das Team, das Budget, die Roadmap und die Beziehung zur Leitung des Engineerings. Rechne mit einer Fallstudie, in der drei Abteilungen jeweils das nächste Quartal des Plattform-Teams wollen.

Schwache Antwort: „Wir bauen, was das lauteste Team verlangt.“ Nachfrage: „Der CTO will nächsten Monat ein neues Werkzeug.“ Erkläre, wie du es gegen die Roadmap abwägen würdest.

Dein Lebenslauf für diese Fragen

Jeder Baustein der Plattform in deinem Lebenslauf lädt zu den Fragen oben ein: wer ihn genutzt hat, was er ersetzt hat, was kaputtging und was sich für die Entwickler geändert hat. Eine Zeile pro Baustein, unter der Stelle, an der du ihn gebaut hast, gibt dem Interviewer den Aufhänger für jede Geschichte:

Eine kostenlose Bewertung an einem Job als Platform Engineer zeigt die Lücken, nach denen ein Interviewer bohren wird; bereite die Geschichten hinter diesen Skills vor allem anderen vor.