AWS vs. Azure vs. GCP: Skill-Tests für Cloud-Plattformen — der Leitfaden
Das Cloud-Plattform-Hiring-Problem
Du brauchst eine Senior-DevOps-Engineerin. Du hast fünf großartige Bewerberinnen. Zwei tief in AWS; eine stark in Azure; eine nutzt GCP; eine ist Cloud-agnostisch, aber mit weniger operativer Tiefe.
Wen stellst du ein? Es kommt drauf an. Aber die meisten Teams machen das falsch: Sie stellen entweder für die spezifische Plattform ein und schaffen Lock-in-Risiko — oder sie stellen die Generalistin ein und stellen fest, dass die Plattform-Wissenslücke tiefer ist als erwartet.
Die richtige Antwort ist, beides zu prüfen: plattformspezifisches operatives Wissen und übertragbares Systemdenken.
Wann plattformspezifische Skills testen
Teste auf AWS-/Azure-/GCP-Tiefe, wenn:
- Dein bestehender Stack auf diese Plattform festgelegt ist
- Dein Hiring-Ziel ist, Expertise in dieser Cloud zu vertiefen
- Vertragliche oder Compliance-Anforderungen eine bestimmte Cloud verlangen
Teste auf cloud-agnostische Grundlagen, wenn:
- Du multi-cloud bist oder migrieren könntest
- Du Systemdenken über Tool-Beherrschung einstellst
- Die Bewerberin plattformübergreifend arbeiten wird
Die meisten Teams sollten beides prüfen: „Kann sie AWS gut betreiben?" UND „Kann sie plattformunabhängig über Architektur reasonen?"
AWS-Bewertungs-Framework
Zu testende Skills
-
IAM und Sicherheitsmodellierung
- Kann sie Least-Privilege-Zugriff für eine Microservices-Architektur entwerfen?
- Versteht sie SCPs vs. Inline-Policies vs. Managed Policies?
- Kann sie erklären, warum man keine Root-Credentials nutzen sollte?
-
Netzwerk und Konnektivität
- VPC-Design: Subnetze, Routing, NACLs, Security Groups
- Wann Direct Connect vs. VPN vs. Internet Gateway nutzen
- Trade-offs bei cross-account oder cross-region Networking
-
Storage und Datenbanken
- EBS-Optimierung: gp3 vs. io2, provisioned throughput
- RDS-Failover- und Backup-Strategien
- S3-Lifecycle-Policies und Versioning für Datenaufbewahrung
-
Compute-Skalierung
- EC2 Auto Scaling Groups vs. Spot Instances
- ECS vs. EKS Trade-offs
- Lambda-Cold-Start-Auswirkungen auf Produktionslasten
Beispielfragen
Take-home-Szenario:
„Entwirf ein System, das täglich 10 GB Logs von 100 EC2-Instanzen aufnimmt, langlebig speichert und mit Sub-Sekunden-Latenz abfragt. Budget: 2.000 $/Monat. Nur AWS. Begründe deine Wahl."
Eine gute Antwort berücksichtigt:
- CloudWatch Logs für die Sammlung (managed) vs. Firehose + S3 + Athena (kostenoptimiert)
- Log-Retention-Policies zum Kostenmanagement
- Indexierungsstrategie (Athena-Partitionierung oder Elasticsearch)
- Abfragemuster und ob Sub-Sekunden-Latenz tatsächlich gefordert oder angenommen ist
Eine schwache Antwort springt zu Elasticsearch, ohne zu hinterfragen, ob es nötig ist.
Live-Troubleshooting:
„Deine RDS-Instanz hat 80 % CPU erreicht und deine auto-skalierenden ECS-Tasks können sich 2 Minuten pro Stunde, immer zur selben Zeit, nicht zur Datenbank verbinden. Erkläre, wie du das debuggen würdest."
Die Bewerberin sollte denken an:
- ECS-Verbindungsspitzen mit RDS-Last korrelieren
- Slow Queries via Enhanced Monitoring prüfen
- Connection Leaks suchen (App schließt Verbindungen nicht)
- Erwägen, ob zu dieser Stunde etwas anderes läuft (Backups, Reports)
Azure-Bewertungs-Framework
Zu testende Skills
-
Identität und Zugriff (Azure AD / Entra)
- Managed Identity vs. Service Principals
- Rollenbasierte Zugriffskontrolle (RBAC) mit Custom Roles
- Conditional-Access-Policies für Sicherheit
-
Netzwerk und Sicherheit
- NSGs, UDRs und Peering
- Azure Firewall vs. NVA
- Private Endpoints und Service Endpoints
-
Storage und Compute
- Managed Disks, Premium SSD, ephemeral OS Disks
- App Service vs. Container Instances vs. AKS
- Azure-SQL-Failover-Gruppen vs. Read Replicas
-
Observability
- Application Insights vs. Azure Monitor
- Log-Analytics-Abfragen (KQL)
- Diagnostic Settings und Retention
Beispielfragen
Take-home-Szenario:
„Du migrierst eine On-Premises-Anwendung nach Azure. Die App benötigt eine feste IP, hat strenge Compliance-Anforderungen und muss von anderen Tenants isoliert sein. Entwirf die Netzwerk- und Identitätsarchitektur."
Gute Antworten enthalten:
- Dediziertes Subnetz mit NSG-Regeln
- Private Endpoint für Datenbanken
- Managed Identity für App-Authentifizierung
- Network Policies zur Verkehrssteuerung
Live-Gespräch:
„Deine Azure Web App ist langsam, aber Azure Monitor zeigt normale CPU. Latenz stieg sprunghaft nach dem Deploy neuen Codes. Was prüfst du zuerst?"
Die Bewerberin sollte denken an:
- Application-Insights-Traces und Abhängigkeiten
- App-Service-Plan-CPU vs. App-Level-Bottlenecks
- Code-Änderungen (neue Queries, blockierende Aufrufe)
- Datenbank-Connection-Pooling
- Latenz von Drittanbieter-Abhängigkeiten
GCP-Bewertungs-Framework
Zu testende Skills
-
IAM und Organisationshierarchie
- Service Accounts und Key Management
- Custom Roles und Least Privilege
- Organization Policies und Constraints
-
Compute und Orchestrierung
- Compute-Engine-Zonen und -Regionen
- GKE-Cluster-Design und Autoscaling
- Cloud Run für Serverless-Workloads
-
Daten und Storage
- Cloud-Storage-Buckets, Versioning, Lifecycle
- BigQuery für Data Warehousing
- Cloud-SQL- und Cloud-Spanner-Failover
-
Observability (Google Cloud Operations)
- Cloud Logging und Log Routing
- Cloud Trace und Profiling
- Cloud Monitoring und Custom Metrics
Beispielfragen
Take-home-Szenario:
„Du hast einen Batch-Job, der täglich auf Compute Engine läuft, 1 TB Daten verarbeitet und 2 Stunden braucht. Du willst Kosten senken und die SLA halten. Entwirf eine Lösung."
Gute Antworten könnten erwägen:
- Preemptible VMs (kosteneffizient, akzeptabel für Batch)
- BigQuery für Abfragen (schneller als Verarbeitung in Compute Engine)
- Cloud Run, falls parallelisierbar
- Spot VMs für fehlertolerante Workloads
Live-Debugging:
„Dein Cloud-Run-Service läuft bei manchen Requests in Timeouts. Logs sind sauber. P99-Latenz stieg nach einem Deploy von 50 ms auf 2 s. Spür dem nach."
Die Bewerberin sollte denken an:
- Traces prüfen, welche Operation langsam ist
- Neue Abhängigkeiten untersuchen (Datenbank, externe APIs)
- Datenbank-Verbindungslimits prüfen
- Speicherzuweisung überprüfen (braucht Cloud Run mehr?)
- Cold-Start-Muster suchen
Plattformübergreifende Bewertung (plattformagnostisch)
Für Bewerberinnen, die mehrere Clouds genutzt haben, teste übertragbare Skills:
Frage:
„Du hast Systeme auf AWS und Azure entworfen. Welche Design-Patterns übertragen sich? Was ist grundsätzlich anders?"
Eine gute Antwort erkennt an:
- Kernkonzepte (VPCs, IAM, managed Datenbanken) sind ähnlich
- Implementierungsdetails unterscheiden sich erheblich
- Kostenmodelle unterscheiden sich (Reserved Instances vs. Commitment)
- Die Lernkurve für jede Plattform ist flach, sobald man die erste verstanden hat
Das signalisiert: Sie ist nicht dogmatisch und kann zwischen Clouds wechseln.
Bewertungsstruktur für Cloud-Hiring
- 30-minütige Take-home (plattformspezifisches Szenario mit Constraints)
- 30-minütiges Live-Troubleshooting (auf ihrer Expertise-Plattform)
- 15-minütiges Architekturgespräch (testet, ob sie Plattform-Trade-offs versteht)
Wann Multi-Cloud vs. Plattform-Spezialistinnen einstellen
Stelle Multi-Cloud-Generalistinnen ein, wenn:
- Du zwischen Plattformen migrierst
- Du Flexibilität bei Vertragsverhandlungen brauchst
- Du portable Infrastructure-as-Code aufbaust
Stelle Plattform-Spezialistinnen ein, wenn:
- Deine Plattformentscheidung fix ist
- Du tiefes operatives Wissen über die Edge Cases dieser Plattform brauchst
- Du Kosten auf einer bestimmten Cloud optimierst
Die meisten gesunden Engineering-Orgs brauchen beides: ein paar tiefe Spezialistinnen und mehr Generalistinnen, die plattformübergreifend operieren können.
Faire plattformübergreifende Prüfungen aufbauen
Wenn du sowohl AWS- als auch Azure-Bewerberinnen prüfst, strukturiere deine Fragen konsistent. Bitte jede Bewerberin, dasselbe System zu entwerfen, nur eben auf ihrer Plattform. Vergleiche dann: haben die Architekturen gleichwertiges Trade-off-Denken? Oder hat eine Bewerberin Abkürzungen genommen?
Bereit, deine Cloud-Hiring-Prüfung aufzubauen? Sieh dir DevOps- und Cloud-Engineering-Ressourcen an und wie du die Ergebnisse interpretierst.