Cloud-Engineer-Interviewfragen — 30+ Fragen & Expertenantworten

Das BLS prognostiziert jährlich etwa 317.700 neue Stellenangebote im IT-Bereich bis 2034, und Cloud Engineering steht im Zentrum dieses Wachstums — AWS-, Azure- und GCP-Cloud-Engineers erzielen Mediangehälter von 140.000-143.000 US-Dollar je nach Plattformspezialisierung [1]. Cloud-Engineer-Interviews sind besonders anspruchsvoll, da sie Infrastrukturwissen, Programmierfähigkeiten, Sicherheitsbewusstsein und architektonisches Denken vereinen. Dieser Leitfaden behandelt die Fragen, die entscheiden, ob Sie zuverlässige Cloud-Infrastruktur im großen Maßstab entwerfen, aufbauen und betreiben können.

Wichtigste Erkenntnisse

• Cloud-Engineer-Interviews prüfen Breite über Netzwerk, Compute, Storage und Sicherheit hinweg — plus Tiefe in mindestens einer großen Plattform (AWS, Azure oder GCP) [2].
• Verhaltensfragen untersuchen, wie Sie mit Produktionsvorfällen umgehen, Kostenoptimierung betreiben und mit Entwicklungsteams bei der Deployment-Automatisierung zusammenarbeiten.
• Technische Fragen reichen von VPC-Netzwerkgrundlagen bis zu fortgeschrittenen Themen wie Multi-Region-Disaster-Recovery und Container-Orchestrierung.
• Infrastructure-as-Code-(Terraform, CloudFormation)-Kompetenz ist mittlerweile eine Grunderwartung, kein Differenzierungsmerkmal.

Verhaltensfragen

1. Erzählen Sie von einer Situation, in der Sie einen kritischen Produktionsausfall in einer Cloud-Umgebung behoben haben.

Expertenantwort: „Unser primärer Produktionscluster in us-east-1 erlebte kaskadierende Ausfälle, als eine Auto Scaling Group Instanzen in einer Availability Zone mit beeinträchtigter EBS-Performance startete. Unser Monitoring (Datadog) alarmierte innerhalb von 3 Minuten bei erhöhter p99-Latenz. Ich diagnostizierte über das AWS Health Dashboard (bestätigter AZ-Abbau), modifizierte dann sofort die ASG, um die betroffene AZ auszuschließen. Gleichzeitig skalierte ich gesunde Instanzen in den verbleibenden AZs hoch, um die Last aufzufangen. Die Gesamtdauer des Vorfalls betrug 22 Minuten, mit 8 Minuten kundenspürbarer Auswirkung. Nach dem Vorfall implementierte ich AZ-bewusste Health Checks und automatisierten AZ-Ausschluss basierend auf AWS Health API-Ereignissen. Die Nachbesprechung ergab, dass wir keinen Einzel-AZ-Ausfall getestet hatten — wir führen jetzt vierteljährliche Game Days durch."

2. Beschreiben Sie, wie Sie die Cloud-Infrastrukturkosten deutlich gesenkt haben.

Expertenantwort: „Ich übernahm eine AWS-Umgebung mit 180.000 US-Dollar/Monat Ausgaben ohne Kostenkontrolle. Ich begann mit AWS Cost Explorer, um die größten Kostentreiber zu identifizieren — 40 % war EC2, 25 % war RDS. Ich stellte fest, dass 30 % der EC2-Instanzen überdimensioniert waren (t3.xlarge bei 8 % durchschnittlicher CPU-Auslastung), 15 Dev/Staging-RDS-Instanzen rund um die Uhr ohne automatisches Herunterfahren liefen und die Reserved-Instance-Abdeckung nur bei 20 % lag. Ich passte die Instanzgröße anhand von CloudWatch-Metriken an, implementierte Lambda-basiertes Scheduling für Nicht-Produktionsressourcen, kaufte Savings Plans für 70 % des stabilen Compute-Bedarfs und migrierte zwei RDS-Instanzen auf Aurora Serverless. Die monatlichen Ausgaben sanken auf 112.000 US-Dollar — eine Reduktion von 38 % — ohne Performance-Einbußen. Ich erstellte ein wöchentliches Kosten-Dashboard, das die Engineering-Leads regelmäßig überprüfen."

3. Wie stellen Sie sicher, dass Cloud-Infrastrukturänderungen die Produktion nicht beeinträchtigen?

Expertenantwort: „Alle Infrastrukturänderungen durchlaufen eine Pipeline: Code in Terraform, Peer-Review via PR, Validierung durch terraform plan in CI (GitHub Actions), zuerst Anwendung auf Staging, dann nach Verifikation Übernahme in die Produktion. Ich erzwinge Branch-Protection-Regeln — kein direktes Anwenden auf die Produktion. Für risikoreiche Änderungen (Netzwerk, IAM, Datenbank) verlange ich zwei Genehmigungen und plane Änderungen in verkehrsarmen Zeiten mit einem in der PR-Beschreibung dokumentierten Rollback-Plan. Ich nutze auch Terraform-Sentinel-Policies, um bekannte gefährliche Muster zu verhindern — wie das Öffnen von Security Groups auf 0.0.0.0/0 oder die Erstellung unverschlüsselter EBS-Volumes. In zwei Jahren hatten wir null infrastrukturbedingte Ausfälle [3]."

4. Erzählen Sie von einer Situation, in der Sie eine Arbeitslast von On-Premises in die Cloud migriert haben.

Expertenantwort: „Wir migrierten einen Legacy-.NET-Monolithen aus einem Co-Location-Rechenzentrum zu AWS. Ich leitete die Bewertungsphase — Dokumentation aller Abhängigkeiten, Datenflüsse und Performance-Baselines. Wir wählten zunächst einen Lift-and-Shift-Ansatz (EC2 + RDS), um das Risiko zu minimieren, mit einem Modernisierungs-Fahrplan für Phase zwei (Containerisierung). Die kritische Herausforderung war die Datenbankmigration — eine 2-TB-SQL-Server-Datenbank mit Anforderung an nahezu null Ausfallzeit. Ich nutzte AWS DMS (Database Migration Service) für kontinuierliche Replikation, führte den Wechsel während eines 30-minütigen Wartungsfensters um 2 Uhr morgens durch und validierte die Datenintegrität mit Zeilenzahl- und Prüfsummenvergleichen. Nach der Migration verbesserte sich die Latenz um 15 % durch die Co-Location von Compute und Datenbank in derselben Region."

5. Beschreiben Sie, wie Sie mit Entwicklungsteams bei Infrastrukturanforderungen zusammenarbeiten.

Expertenantwort: „Ich arbeite als interner Platform Engineer — ich entwickle Self-Service-Fähigkeiten, anstatt Tickets abzuarbeiten. Ich habe Terraform-Module für gängige Muster erstellt (ECS-Service, RDS-Datenbank, S3-Bucket mit Verschlüsselung), die Entwickler in ihren eigenen Repositories verwenden. Ich halte zweiwöchentliche Sprechstunden ab, in denen Entwickler Architekturthemen besprechen können, und nehme an der Sprint-Planung der Produktteams teil, um kommende Infrastrukturbedarfe zu verstehen. Als ein Team einen neuen Microservice bereitstellen wollte, stellte ich ein Template-Repository mit Terraform, CI/CD-Pipeline, Monitoring-Dashboards und Runbook bereit — sie hatten in 4 Stunden eine produktionsreife Umgebung statt des bisherigen 2-wöchigen Ticket-Prozesses."

6. Wie gehen Sie bei Ihrer täglichen Arbeit mit Cloud-Sicherheit um?

Expertenantwort: „Sicherheit ist keine separate Aktivität — sie ist in jede Infrastrukturentscheidung eingebettet. Ich folge dem Prinzip der minimalen Berechtigung für alle IAM-Policies und nutze IAM Access Analyzer, um übermäßig permissive Rollen zu identifizieren. Alle Daten im Ruhezustand werden mit KMS-Schlüsseln verschlüsselt (kundenverwaltete Schlüssel für sensible Arbeitslasten), und Daten bei der Übertragung verwenden TLS 1.2+. Ich führe AWS Config Rules und Security Hub Checks kontinuierlich aus, mit automatischer Behebung häufiger Befunde (öffentliche S3-Buckets, unbeschränkte Security Groups). Ich führe auch vierteljährliche Zugriffsüberprüfungen durch und rotiere Anmeldedaten alle 90 Tage. Unser letztes SOC-2-Audit hatte null Cloud-bezogene Beanstandungen [4]."

Technische Fragen

7. Erklären Sie das Shared-Responsibility-Modell in AWS, Azure oder GCP.

Expertenantwort: „Der Cloud-Anbieter ist verantwortlich für die Sicherheit ‚der' Cloud — physische Infrastruktur, Hypervisor, interne Bereiche verwalteter Dienste. Der Kunde ist verantwortlich für die Sicherheit ‚in' der Cloud — IAM-Policies, Netzwerkkonfiguration, Datenverschlüsselung, anwendungsseitige Sicherheit und OS-Patching für EC2/VMs. Die Grenze verschiebt sich je nach Diensttyp: Bei IaaS (EC2) verwalten Sie alles oberhalb des Hypervisors; bei PaaS (Lambda, RDS) verwaltet der Anbieter das OS und die Runtime; bei SaaS verwalten Sie hauptsächlich Zugriff und Daten. Die häufigsten Sicherheitsfehler entstehen dadurch, dass Kunden diese Grenze missverstehen — sie nehmen an, der Anbieter sichere ab, was tatsächlich in ihrer Verantwortung liegt, wie S3-Bucket-Policies oder Security-Group-Regeln [2]."

8. Entwerfen Sie eine hochverfügbare Multi-Region-Architektur für eine Webanwendung mit relationaler Datenbank.

Expertenantwort: „Die Architektur erstreckt sich über zwei Regionen mit Active-Passive-Datenbankkonfiguration. In der primären Region: Application Load Balancer verteilt den Verkehr auf eine Auto Scaling Group von EC2-Instanzen (oder ECS/EKS-Container) in drei Availability Zones. Die Datenbank ist Amazon Aurora mit Read Replicas in jeder AZ. In der sekundären Region: identische Infrastruktur in reduziertem Umfang (Warm Standby). Aurora Global Database bietet regionsübergreifende Replikation mit typischerweise weniger als 1 Sekunde Verzögerung. Route 53 Health Checks überwachen die primäre Region — bei Ausfall wird per DNS-Failover auf die sekundäre Region umgeschaltet. Statische Inhalte werden über CloudFront mit S3-Origin bereitgestellt, repliziert via S3 Cross-Region Replication. RTO-Ziel: unter 5 Minuten. RPO-Ziel: unter 1 Sekunde mit Aurora Global Database. Ich würde zusätzlich Route 53 Application Recovery Controller für anspruchsvollere Failover-Szenarien implementieren [5]."

9. Was ist Infrastructure-as-Code und wie implementieren Sie es?

Expertenantwort: „IaC behandelt Infrastrukturkonfiguration als Quellcode — versioniert, geprüft, getestet und automatisch angewandt. Ich verwende hauptsächlich Terraform (HCL) für Multi-Cloud-Umgebungen, da es anbieterunabhängig ist und das stärkste Ökosystem an Modulen und Providern hat. Mein Terraform-Workflow: Module nach Domäne organisiert (Netzwerk, Compute, Daten), Remote State in S3 mit DynamoDB-Locking, Workspaces zur Umgebungstrennung und CI/CD-Pipeline, die terraform plan bei PR-Erstellung und terraform apply bei Merge auf main ausführt. Ich erzwinge Codequalität mit tflint, Checkov für Sicherheitsscanning und Kostenschätzung mit Infracost. Für reine AWS-Umgebungen sind CloudFormation oder CDK gangbare Alternativen, aber Terraforms Portabilität und State-Management machen es zu meiner Standardwahl [3]."

10. Erklären Sie die Kubernetes-Architektur und wann Sie diese gegenüber Serverless wählen würden.

Expertenantwort: „Kubernetes hat eine Control Plane (API Server, etcd, Scheduler, Controller Manager) und Worker Nodes, die kubelet, kube-proxy und Container Runtime ausführen. Pods sind die kleinste deploybare Einheit. Deployments verwalten zustandslose Arbeitslasten; StatefulSets verwalten zustandsbehaftete Arbeitslasten mit stabilen Netzwerkidentitäten und persistenten Volumes. Services bieten Netzwerkfunktionen (ClusterIP, NodePort, LoadBalancer). Ich wähle Kubernetes, wenn: die Arbeitslast feinkörnige Ressourcenkontrolle erfordert, das Team Portabilität über Clouds benötigt, Arbeitslasten konsistente Verkehrsmuster haben, die von reserviertem Compute profitieren, oder die Anwendung komplexe Netzwerkanforderungen hat. Ich wähle Serverless (Lambda, Cloud Functions), wenn: Arbeitslasten ereignisgesteuert sind, der Verkehr unregelmäßig und unvorhersehbar ist, das Team klein ist und keinen Cluster-Betrieb verwalten kann, oder Cold-Start-Latenz akzeptabel ist. Die Entscheidung dreht sich um betriebliche Komplexität versus Kontrolle — Kubernetes gibt Ihnen mehr Kontrolle, erfordert aber mehr betriebliche Investition [6]."

11. Wie implementieren Sie eine CI/CD-Pipeline für Infrastruktur-Deployments?

Expertenantwort: „Meine Standard-Pipeline: (1) Entwickler pusht Terraform-Änderungen in einen Feature Branch. (2) GitHub Actions führt terraform init, terraform validate, tflint und checkov für statische Analyse aus. (3) terraform plan wird gegen die Zielumgebung ausgeführt, und der Plan-Output wird als PR-Kommentar für die Reviewer-Sichtbarkeit gepostet. (4) Nach Genehmigung und Merge wird terraform apply automatisch auf Staging ausgeführt. (5) Nach Staging-Verifikation (manuelle oder automatisierte Smoke Tests) wendet ein separater Workflow Änderungen auf die Produktion mit manuellem Genehmigungsgate an. Ich nutze OIDC für AWS-Authentifizierung (keine statischen Credentials in CI), und die Pipeline hat eine terraform destroy-Option für kurzlebige Umgebungen. State-Locking verhindert gleichzeitige Änderungen [3]."

12. Welche Strategien nutzen Sie für Monitoring und Observability in Cloud-Umgebungen?

Expertenantwort: „Ich implementiere die drei Säulen: Metriken (CloudWatch/Datadog für Infrastruktur- und Anwendungsmetriken), Logs (zentralisiert in CloudWatch Logs oder ELK/Loki mit strukturiertem JSON-Logging) und Traces (AWS X-Ray oder Jaeger für verteiltes Tracing). Für das Alerting verfolge ich einen schweregradbasierten Ansatz: P1 (automatischer Page, kundenrelevant), P2 (Slack-Alert, beeinträchtigt aber funktional), P3 (Ticket, Untersuchung am nächsten Geschäftstag). Ich nutze Golden Signals — Latenz (p50, p95, p99), Traffic (Anfragen/Sek.), Fehler (Fehlerrate) und Sättigung (CPU, Speicher, Festplatte). SLOs (Service Level Objectives) definieren die Zielzuverlässigkeit — beispielsweise 99,9 % Verfügbarkeit, p99-Latenz unter 500 ms. Aus SLOs abgeleitete Error Budgets bestimmen, wann Zuverlässigkeit Vorrang vor neuen Features hat [5]."

13. Erklären Sie VPC-Netzwerkgrundlagen und wie Sie Netzwerkarchitektur entwerfen.

Expertenantwort: „Ein VPC ist ein isoliertes virtuelles Netzwerk innerhalb einer Cloud-Region. Ich entwerfe VPCs mit einem standardisierten CIDR-Schema: /16 für das VPC, /20 für Subnetze (je 4.094 IPs), aufgeteilt über Availability Zones. Öffentliche Subnetze (mit Internet-Gateway-Route) beherbergen Load Balancer und Bastion Hosts; private Subnetze (NAT-Gateway-Route) beherbergen Anwendungsinstanzen; isolierte Subnetze (ohne Internetroute) beherbergen Datenbanken. Network ACLs bieten zustandslose Perimeterfilterung; Security Groups bieten zustandsbehaftete Filterung auf Instanzebene. Für Multi-VPC-Architekturen nutze ich AWS Transit Gateway als Hub anstelle von VPC Peering, das bei mehr als 10-15 VPCs nicht gut skaliert. Ich implementiere auch VPC Flow Logs für Netzwerk-Monitoring und Troubleshooting sowie DNS-Auflösung über Route 53 Resolver für hybride Umgebungen [4]."

Situative Fragen

14. Die AWS-Rechnung Ihres Unternehmens steigt monatlich um 15 % ohne entsprechendes Verkehrswachstum. Wie untersuchen Sie das?

Expertenantwort: „Ich würde systematisch vorgehen: (1) AWS Cost Explorer öffnen und nach Service, Region und Konto filtern, um zu identifizieren, welcher Service den Anstieg verursacht. (2) Nach neu erstellten Ressourcen suchen — CloudTrail-Logs zeigen, wer was wann erstellt hat. (3) Häufige Verschwendungsmuster prüfen: verwaiste EBS-Volumes, inaktive Load Balancer, vergessene Testumgebungen und Datentransferkosten durch Cross-Region- oder Cross-AZ-Verkehr. (4) Kürzliche Architekturänderungen überprüfen — hat jemand ein Logging-Feature aktiviert, das Terabytes an S3 sendet? (5) Marketplace-Abonnements oder Drittanbieterdienste prüfen, die sich automatisch verlängern. Ich würde die Ergebnisse mit einem priorisierten Behebungsplan präsentieren, der geschätzte Einsparungen für jede Maßnahme aufzeigt. Automatische Kostenanomalieserkennung (AWS Cost Anomaly Detection oder benutzerdefinierte Lambda) sollte implementiert werden, um zukünftige Spitzen früher zu erkennen."

15. Ein Entwicklungsteam möchte direkt von ihren Laptops in die Produktion deployen. Wie lenken Sie sie zu einem besseren Ansatz?

Expertenantwort: „Ich würde nicht mit ‚Nein' beginnen — ich würde verstehen, warum sie das möchten. Normalerweise liegt es daran, dass der Deployment-Prozess zu langsam oder zu bürokratisch ist. Ich würde einen Kompromiss vorschlagen: eine schnelle, automatisierte Pipeline, die in unter 10 Minuten vom Merge auf main in die Produktion deployt. Ich würde die Pipeline mit ihnen bauen (nicht für sie, damit sie die Verantwortung tragen), automatisierte Test- und Sicherheitsscan-Gates einbauen und demonstrieren, dass es sowohl schneller als auch sicherer ist als manuelles Deployment. Ich würde die Risiken von Laptop-Deployments erklären — nicht reproduzierbare Builds, kein Audit-Trail, keine Rollback-Fähigkeit und Credential-Exposition. Sobald sie die Pipeline erleben, wollen sie selten zurück. Akzeptanz gewinnt man durch Developer Experience, nicht durch Richtliniendurchsetzung."

16. Sie sollen Infrastruktur für eine neue Anwendung entwerfen, aber die Anforderungen sind vage. Wie gehen Sie vor?

Expertenantwort: „Ich stelle fünf klärende Fragen: (1) Welches Verkehrsmuster wird erwartet (stabil, sprunghaft, ereignisgesteuert)? (2) Welche Datenresidenz-Anforderungen gibt es (einzelne Region, Multi-Region, bestimmte Länder)? (3) Welches Verfügbarkeitsziel wird angestrebt (99,9 %, 99,99 %)? (4) Welche Datenspeicherungs- und Aufbewahrungsanforderungen bestehen (Volumen, Zugriffsmuster, Compliance)? (5) Welche Budgetbeschränkungen gibt es? Mit diesen Antworten kann ich eine angemessene Architektur entwerfen. Ich würde mit einer minimalen tragfähigen Architektur beginnen, die die Kernanforderungen erfüllt, und verwaltete Dienste nutzen, um den Betriebsaufwand zu reduzieren (Aurora statt selbstverwaltetem PostgreSQL, ECS Fargate statt selbstverwalteten EC2-Clustern). Ich dokumentiere Skalierungsstrategien für jede Komponente, damit wir wachsen können, ohne neu zu architekturieren."

17. Ein Datenbank-Failover findet während der Spitzenzeiten statt, aber die Anwendung stellt die Verbindung nicht automatisch wieder her. Was untersuchen Sie?

Expertenantwort: „Häufige Ursachen: (1) DNS-Caching — die Anwendung löst den alten Datenbank-Endpunkt auf. Ich prüfe, ob der Connection Pool die DNS-TTL respektiert (Aurora DNS-TTL beträgt 5 Sekunden, aber viele Connection Pools cachen DNS auf OS- oder JVM-Ebene). (2) Connection-Pool-Erschöpfung — der Pool hält veraltete Verbindungen und validiert sie nicht vor der Nutzung. Ich prüfe Connection-Validierungsabfragen (SELECT 1) und Idle-Timeout-Einstellungen. (3) Anwendungsseitige Retry-Logik — wenn die Anwendung bei Verbindungsfehlern nicht wiederholt, verursacht ein einziges Failover dauerhafte Unterbrechung. Ich würde exponentielles Backoff mit Jitter implementieren. (4) Security-Group- oder Route-Änderungen während des Failovers. Für sofortige Lösung würde ich die Anwendungs-Pods/Instanzen neu starten. Langfristig würde ich Connection-Pool-Health-Checks, DNS-TTL-Awareness und korrekte Retry-Logik implementieren."

18. Ein Compliance-Audit verlangt den Nachweis, dass alle Daten im Ruhezustand verschlüsselt sind. Wie weisen Sie das nach?

Expertenantwort: „Ich würde Nachweise aus drei Quellen zusammentragen: (1) AWS Config Rules — ich würde die aktiven Regeln für encrypted-volumes, rds-storage-encrypted, s3-bucket-server-side-encryption-enabled und deren Compliance-Status zeigen. (2) Terraform-Code — ich würde die IaC-Module zeigen, die Verschlüsselung standardmäßig erzwingen (KMS-Schlüsselreferenzen in EBS-, RDS- und S3-Ressourcendefinitionen). (3) AWS Config Compliance-Zeitverlauf — der zeigt, dass diese Regeln während des Prüfungszeitraums kontinuierlich konform waren. Ich würde auch unsere Terraform-Sentinel- oder Checkov-Policies zeigen, die die Erstellung unverschlüsselter Ressourcen verhindern. Für den Prüfer würde ich ein Zusammenfassungsdokument erstellen, das jeden Datenspeicher seiner Verschlüsselungsmethode, Schlüsselverwaltungsrichtlinie und den Compliance-Nachweisen zuordnet."

Fragen an den Interviewer

1. Welche Cloud-Plattformen nutzt das Unternehmen, und gibt es eine Multi-Cloud-Strategie? (Bestimmt, welche Plattformkenntnisse am relevantesten sind.)
2. Wie ausgereift ist die Infrastructure-as-Code-Praxis — welcher Prozentsatz der Infrastruktur wird durch Code verwaltet? (Zeigt die betriebliche Reife.)
3. Wie sieht die On-Call-Rotation für Cloud-Infrastruktur aus? (Praktische Frage zur Work-Life-Balance und Vorfallhäufigkeit.)
4. Wie arbeitet das Cloud-Team mit den Anwendungsentwicklungsteams zusammen? (Bestimmt, ob Sie Platform Engineer oder Ticket-Bearbeiter sind.)
5. Wie hoch sind die monatlichen Cloud-Ausgaben, und gibt es eine FinOps-Praxis? (Zeigt, dass Ihnen Kosteneffizienz wichtig ist — eine Eigenschaft, die jeder Hiring Manager schätzt.)
6. Wie handhaben Sie Sicherheits- und Compliance-Anforderungen in der Cloud? (Zeigt die Sicherheitsreife und regulatorische Belastung.)
7. Was ist die größte Infrastrukturherausforderung, vor der das Team derzeit steht? (Zeigt, dass Sie zur Lösung realer Probleme beitragen möchten.)

Interviewformat

Cloud-Engineer-Interviews umfassen typischerweise 4-5 Runden über 1-2 Wochen [2]. Die erste Runde ist ein Recruiter-Screening (30 Minuten) zu Hintergrund und Cloud-Zertifizierungen. Die zweite Runde ist ein technisches Telefonscreening (45-60 Minuten) mit Fragen zu Cloud-Architektur und Netzwerken. Die dritte Runde ist eine Systemdesign-Übung, bei der Sie eine Cloud-Architektur am Whiteboard oder in einem geteilten Dokument entwerfen. Die vierte Runde ist eine praktische Übung — einige Unternehmen stellen eine Live-AWS/Azure-Umgebung bereit und bitten Sie, Infrastruktur zu troubleshooten oder aufzubauen. Verhaltensrunden sind durchgehend eingestreut. Einige Unternehmen fügen eine Coding-Runde hinzu (Python oder Go für Automatisierungsskripting). FAANG-Unternehmen ergänzen zusätzliche Systemdesign- und Coding-Runden.

Vorbereitung

• Lassen Sie sich zertifizieren. AWS Solutions Architect Associate, Azure Administrator oder GCP Associate Cloud Engineer Zertifizierungen demonstrieren Basiskompetenz und bestehen HR-Screenings [2].
• Üben Sie Systemdesign. Zeichnen Sie Architekturdiagramme für gängige Muster: mehrstufige Webanwendung, ereignisgesteuerte Pipeline, Multi-Region-DR. Üben Sie, Kompromisse zu erklären.
• Beherrschen Sie Netzwerke. VPC, Subnetze, Routentabellen, Security Groups, NACLs, DNS, Load Balancer — Netzwerkfragen kommen in jedem Cloud-Interview vor.
• Schreiben Sie Terraform. Haben Sie ein öffentliches GitHub-Repository mit Terraform-Modulen, die Sie erstellt haben. Ihren IaC-Ansatz mit Code-Beispielen besprechen zu können, ist überzeugend [3].
• Verstehen Sie Kostenoptimierung. Kennen Sie Savings Plans versus Reserved Instances, Right-Sizing-Strategien und häufige Verschwendungsmuster.
• Lernen Sie Kubernetes-Grundlagen. Auch wenn die Rolle nicht Kubernetes-fokussiert ist, wird das Verständnis von Pods, Services, Deployments und Ingress erwartet.
• Nutzen Sie ResumeGeni, um einen ATS-optimierten Lebenslauf zu erstellen, der Cloud-Zertifizierungen, spezifische Plattformerfahrung (AWS/Azure/GCP), IaC-Tools und quantifizierte Infrastrukturverbesserungen hervorhebt.

Häufige Interviewfehler

1. Servicenamen auswendig lernen, ohne die Architektur zu verstehen. Zu wissen, dass S3 Objektspeicher ist, reicht nicht — erklären Sie, wann S3 versus EFS versus EBS zu verwenden ist und die jeweiligen Kompromisse [2].
2. Kosten im Design ignorieren. Jede Architektur sollte Kosteneffizienz berücksichtigen. Eine Multi-Region-, Multi-AZ-, vollständig redundante Architektur für ein Startup mit 100 Nutzern zu entwerfen, zeigt schlechtes Urteilsvermögen.
3. Sicherheit nicht erwähnen. Wenn Ihr Architekturdesign weder IAM, Verschlüsselung noch Netzwerksegmentierung erwähnt, ist der Interviewer besorgt.
4. Plattform-monogam sein, ohne Alternativen zu verstehen. Wenn Sie nur AWS kennen, sollten Sie trotzdem die Azure- und GCP-Äquivalente auf hoher Ebene verstehen.
5. Betriebliche Aspekte vernachlässigen. Infrastruktur zu entwerfen, ohne Monitoring, Alerting, Logging und Incident Response zu besprechen, ist unvollständig.
6. IaC nicht erwähnen. Wenn Sie beschreiben, wie Sie manuell durch die Konsole klicken, ist das Interview für Senior-Rollen praktisch vorbei [3].
7. Auswirkungen nicht quantifizieren. „Ich habe AWS-Infrastruktur verwaltet" ist schwach. „Ich habe eine AWS-Umgebung mit 150.000 US-Dollar/Monat verwaltet, die 2 Millionen monatlich aktive Nutzer mit 99,95 % Verfügbarkeit bedient" demonstriert Umfang und Wirkung.

Wichtigste Erkenntnisse

• Cloud-Engineer-Interviews prüfen Plattformwissen, architektonisches Denken, Sicherheitsbewusstsein und betriebliche Reife — bereiten Sie sich auf alle Dimensionen vor.
• Systemdesign-Übungen sind die aussagekräftigste Runde — üben Sie, mehrstufige Multi-Region-Architekturen mit klaren Kompromisserklärungen zu diagrammieren.
• Infrastructure-as-Code und CI/CD für Infrastruktur sind Grunderwartungen für Mid-Level- und Senior-Rollen.
• Nutzen Sie ResumeGeni, um sicherzustellen, dass Ihr Lebenslauf Cloud-Zertifizierungen, Plattformexpertise und quantifizierte Infrastrukturmetriken hervorhebt.

FAQ

Welche Cloud-Zertifizierung sollte ich zuerst machen?

AWS Solutions Architect Associate ist die am weitesten anerkannte und hat die breiteste Anwendbarkeit. Wenn Ihr Zielunternehmen Azure oder GCP nutzt, priorisieren Sie die Associate-Level-Zertifizierung dieser Plattform. Die Zertifizierung selbst ist weniger wichtig als das beim Lernen erworbene Wissen [2].

Wie hoch ist die Gehaltsspanne für Cloud Engineers?

Mediangehälter liegen zwischen 130.000 und 143.000 US-Dollar je nach Plattformspezialisierung. AWS-Engineers verdienen durchschnittlich 140.000 US-Dollar, Azure-Engineers 141.619 US-Dollar und GCP-Engineers 143.000 US-Dollar. Senior und Principal Cloud Engineers bei Top-Unternehmen verdienen 180.000-250.000+ US-Dollar Gesamtvergütung [1].

Muss ich alle drei großen Cloud-Plattformen kennen?

Kennen Sie eine gründlich und die anderen zwei auf konzeptioneller Ebene. Die meisten Unternehmen nutzen eine primäre Plattform. Das Verständnis äquivalenter Dienste über Plattformen hinweg (EC2/Compute Engine/VMs, S3/Cloud Storage/Blob Storage) demonstriert Breite.

Wie wichtig ist Programmieren für Cloud Engineers?

Wichtig und zunehmend. Python-, Go- oder Bash-Scripting für Automatisierung wird erwartet. Vollständige Softwareentwicklungsfähigkeiten (Datenstrukturen, Algorithmen) sind typischerweise nicht erforderlich, es sei denn, die Rolle heißt „Cloud Platform Engineer" oder „SRE" bei einem Technologieunternehmen.

Sollte ich Terraform oder CloudFormation lernen?

Terraform. Es ist Cloud-agnostisch, hat eine größere Community und ist der De-facto-IaC-Standard branchenübergreifend. CloudFormation-Kenntnisse sind ein Bonus für AWS-lastige Umgebungen, aber weniger übertragbar [3].

Was ist der Unterschied zwischen Cloud Engineer und DevOps Engineer?

Erhebliche Überschneidung. Cloud Engineers konzentrieren sich stärker auf Infrastrukturdesign, -bereitstellung und -optimierung. DevOps Engineers konzentrieren sich stärker auf CI/CD-Pipelines, Entwickler-Tooling und die Brücke zwischen Entwicklung und Betrieb. Viele Rollen kombinieren beide Verantwortlichkeiten. Nutzen Sie ResumeGeni, um Ihren Lebenslauf für den spezifischen Titel zu positionieren, den Sie anstreben.

Wie wechsle ich von der Systemadministration zum Cloud Engineering?

Beginnen Sie mit einer Cloud-Zertifizierung und migrieren Sie ein persönliches oder kleines Arbeitsprojekt in die Cloud. Konzentrieren Sie sich früh auf IaC (Terraform) — es ist die größte Denkumstellung vom Klicken durch GUIs. Ihre Netzwerk- und Betriebssystemkenntnisse sind direkt übertragbar; ergänzen Sie Cloud-native Dienste und Automatisierung darauf.