Starte bei Deny by default und vergib Rechte anhand von beobachteter Nutzung statt anhand von Vermutungen. Generier eine erste Policy aus den Access Logs, schneid sie mit Resource-ARNs und Condition Keys statt mit Wildcards zu, und gib jedem Workload seine eigene Rolle. Ergänz Guardrails auf Organisationsebene wie Service Control Policies und Permission Boundaries, damit sich niemand selbst mehr geben kann, und geh dann regelmäßig ungenutzte Rechte durch und kürze sie weg.
Warum Interviewer das fragen
Least Privilege sagen alle. Deutlich weniger haben es umgesetzt, ohne Production zu zerlegen. Der Interviewer will eine praktikable Methode: wie du zu einer Policy kommst, wie du Wildcards vermeidest und wie du Policies über die Zeit eng hältst, während sie ganz natürlich Rechte ansammeln. Guardrails wie Service Control Policies zu erwähnen zeigt, dass du trennen kannst zwischen dem, was ein Team vergeben darf, und dem, was es tatsächlich vergibt.
So baust du deine Antwort auf
- Beschreib, wie du die erste Policy aus echter Nutzung ableitest.
- Erklär das Zuschneiden über Ressourcen und Condition Keys statt über Wildcards.
- Ergänz die Schicht mit den Guardrails auf Organisationsebene.
- Geh auf die laufende Prüfung ein und darauf, wie du Permission Creep erwischst.
Beispielantwort
Die Falle ist, vorab die perfekte Policy schreiben zu wollen. Das blockiert entweder das Team oder endet als Wildcard, weil irgendwann alle keine Lust mehr hatten. Was funktioniert: breit in einem Non-Production-Account starten, aus dem Audit Trail mitschneiden, was der Workload tatsächlich aufruft, und daraus eine Policy generieren. Dann ziehe ich sie enger: echte Resource-ARNs statt Stern, und Condition Keys dort, wo sie zählen, sodass eine Rolle nur Dinge aus unseren eigenen Accounts assumen oder nur in einer Region agieren kann. Jeder Workload bekommt seine eigene Rolle statt einer geteilten großen App-Rolle, denn geteilte Rollen sind der Grund, warum ein Service am Ende die Daten eines anderen löschen kann. Darüber sitzen Guardrails auf Organisationsebene: Service Control Policies, die ganze Kategorien verbieten, etwa Logging abschalten oder öffentliche Buckets anlegen, dazu Permission Boundaries, damit ein Team Rollen erstellen kann, ohne über sein eigenes Limit hinaus zu eskalieren. Und dann die Prüfung: monatliche Reports über ungenutzte Zugriffe, und alles, was neunzig Tage lang nicht angefasst wurde, fliegt raus. Rechte wachsen immer nur, solange nicht jemand das Kürzen zur Gewohnheit macht.
Steht dieses Vorstellungsgespräch bald an? GhostPilot hört bei deinem Live-Call mit, erkennt die Frage in dem Moment, in dem sie gestellt wird, und bringt dir eine strukturierte Antwort in Echtzeit auf den Bildschirm. Probier es im nächsten Mock aus, oder hol dir einen $29 Session Pass, kein Abo, für den Ernstfall.
So funktioniert esNachfragen, mit denen du rechnen solltest
- Wie gehst du mit einem Team um, das während eines Incidents breiten Zugriff braucht?
- Was ist der Unterschied zwischen einer Permission Boundary und einer Service Control Policy?
- Wie würdest du eine Rolle entdecken, die mehr Rechte hat, als sie braucht?
Weitere Fragen für Cloud Engineer
Dein Interviewer stellt seine eigene Version davon. Kopier deine echte Stellenbeschreibung in den kostenlosen Question Predictor und bekomm die 20 Fragen, die diese Rolle am wahrscheinlichsten stellt, samt dem, worauf jede wirklich abzielt.
Meine Fragen vorhersagen