Cloud-Architect-Interviewfragen: Architektur, Migration, Sicherheit

Einführung

In Cloud-Architect-Interviews geht es meist darum, wie Sie Abwägungen treffen: Zuverlässigkeit gegen Kosten, Managed Services gegen Portabilität, zentrale Standards gegen Teamautonomie und Sicherheitskontrollen gegen Liefergeschwindigkeit. Eine starke Antwort erklärt Geschäftsziel, Einschränkungen, Zielarchitektur, Risiken und das Betriebsmodell nach dem Go-live.

Nutzen Sie diesen Leitfaden, um typische Fragen zu Multi-Cloud-Strategie, Migrationsplanung, Microservices, Service Mesh, Disaster Recovery, Zero Trust und Kostenoptimierung zu üben.

Multi-Cloud-Strategie

1. Wie entwerfen Sie eine Multi-Cloud-Strategie?

Antwort: Multi-Cloud nutzt mehrere Cloud-Anbieter für Ausfallsicherheit, Kostenoptimierung und zur Vermeidung von Vendor-Lock-in.

Wichtige Überlegungen:

Architekturmuster:

1. Active-Active:

• Workloads laufen gleichzeitig auf mehreren Clouds
• Lastverteilung über verschiedene Anbieter
• Maximale Verfügbarkeit

2. Active-Passive:

• Primäre Cloud für die Produktion
• Sekundäre Cloud für die Notfallwiederherstellung
• Kosteneffektiv

3. Cloud-Agnostische Services:

• Verwendung von Kubernetes für Portabilität
• Terraform für IaC über verschiedene Clouds hinweg
• Standardisierte CI/CD-Pipelines

Herausforderungen:

• Komplexität im Management
• Datenübertragungskosten
• Qualifikationsanforderungen
• Einheitliche Sicherheitsrichtlinien

Seltenheit: Häufig Schwierigkeit: Schwer

2. Wie planen und führen Sie eine Cloud-Migration durch?

Antwort: Die Cloud-Migration erfordert sorgfältige Planung, Risikobewertung und eine schrittweise Ausführung.

Die 7 R's der Migration:

Migrationsstrategien:

1. Rehost (Lift and Shift):

• Anwendung mit minimalen Änderungen verschieben
• Sinnvoll für schnelle Rechenzentrums-Exits
• Benötigt oft Optimierung nach der Migration

2. Relocate:

• Plattform oder virtualisierten Workload ohne Anwendungsänderung verschieben
• Sinnvoll, wenn der Ziel-Cloud-Anbieter einen passenden Relocation-Pfad bietet
• Netzwerk, Identität, Backup und Lizenzen prüfen

3. Replatform:

• Begrenzte Änderungen, etwa Umstieg auf Managed Database oder Container-Plattform
• Ausgewogen zwischen Geschwindigkeit und Betriebsverbesserung

4. Refactor/Re-architect:

• Für Cloud-native Skalierung, Resilienz oder Liefergeschwindigkeit neu entwerfen
• Höchster Aufwand, daher für wertvolle Kernsysteme reservieren

5. Repurchase:

• Anwendung durch SaaS ersetzen
• Beispiel: Eigenes CRM durch eine Managed-CRM-Plattform ersetzen

6. Retire:

• Anwendungen stilllegen, die keinen geschäftlichen Wert mehr liefern

7. Retain:

• System aus Compliance-, Latenz-, Kosten- oder Sequenzierungsgründen vorerst behalten

Migrationsphasen:

# Migration assessment tool
class MigrationAssessment:
    def __init__(self, application):
        self.app = application
        self.score = 0
    
    def assess_cloud_readiness(self):
        factors = {
            'architecture': self.check_architecture(),
            'dependencies': self.check_dependencies(),
            'data_volume': self.check_data_volume(),
            'compliance': self.check_compliance(),
            'performance': self.check_performance_requirements()
        }
        
        # Calculate migration complexity
        complexity = sum(factors.values()) / len(factors)
        
        if complexity < 3:
            return "Rehost - Geringe Komplexität"
        elif complexity < 6:
            return "Replatform - Mittlere Komplexität"
        else:
            return "Refactor - Hohe Komplexität"
    
    def generate_migration_plan(self):
        return {
            'phase_1': 'Bewertung und Planung',
            'phase_2': 'Proof of Concept',
            'phase_3': 'Datenmigration',
            'phase_4': 'Anwendungsmigration',
            'phase_5': 'Test und Validierung',
            'phase_6': 'Cutover und Go-Live',
            'phase_7': 'Optimierung'
        }

Migrationsausführung:

1. Bewertung:

• Inventarisierung von Anwendungen und Abhängigkeiten
• Analyse der Kosten (TCO)
• Identifizierung von Risiken und Einschränkungen

2. Planung:

• Auswahl der Migrationsstrategie pro Anwendung
• Definition von Erfolgskriterien
• Erstellung von Rollback-Plänen

3. Pilotmigration:

• Beginn mit einer nicht-kritischen Anwendung
• Validierung des Ansatzes
• Verfeinerung der Prozesse

4. Datenmigration:

# Beispiel: Datenbankmigration mit AWS DMS
aws dms create-replication-instance \
    --replication-instance-identifier migration-instance \
    --replication-instance-class dms.t2.medium

# Create migration task
aws dms create-replication-task \
    --replication-task-identifier db-migration \
    --source-endpoint-arn arn:aws:dms:region:account:endpoint/source \
    --target-endpoint-arn arn:aws:dms:region:account:endpoint/target \
    --migration-type full-load-and-cdc

5. Cutover-Strategie:

• Big Bang: Alles auf einmal (risikoreich)
• Phased: Schrittweise Migration (sicherer)
• Parallel Run: Beide Umgebungen laufen parallel

Risikominderung:

• Umfassende Tests
• Automatisierte Rollback-Prozeduren
• Performance-Baselines
• Sicherheitsvalidierung
• Kostenüberwachung

Seltenheit: Sehr Häufig Schwierigkeit: Mittel-Schwer

Microservices-Architektur

3. Wie entwerfen Sie eine Microservices-Architektur?

Antwort: Microservices zerlegen Anwendungen in kleine, unabhängige Services.

Architektur:

Wichtige Prinzipien:

1. Service-Unabhängigkeit:

• Jeder Service besitzt seine Daten
• Unabhängige Bereitstellung
• Technologische Vielfalt erlaubt

2. Kommunikation:

# Synchronous (REST API)
import requests

def get_user(user_id):
    response = requests.get(f'http://user-service/api/users/{user_id}')
    return response.json()

# Asynchronous (Message Queue)
import pika

def publish_order_event(order_data):
    connection = pika.BlockingConnection(pika.ConnectionParameters('rabbitmq'))
    channel = connection.channel()
    channel.queue_declare(queue='orders')
    channel.basic_publish(
        exchange='',
        routing_key='orders',
        body=json.dumps(order_data)
    )
    connection.close()

3. API Gateway:

• Single Entry Point
• Authentifizierung/Autorisierung
• Ratenbegrenzung
• Request Routing

4. Service Discovery:

• Dynamische Service-Registrierung
• Health Checks
• Load Balancing

Vorteile:

• Unabhängige Skalierung
• Technologische Flexibilität
• Fehlerisolation
• Schnellere Bereitstellung

Herausforderungen:

• Komplexität verteilter Systeme
• Datenkonsistenz
• Testkomplexität
• Operativer Overhead

Seltenheit: Sehr Häufig Schwierigkeit: Schwer

4. Wie implementieren Sie ein Service Mesh in Microservices?

Antwort: Ein Service Mesh bietet eine Infrastrukturschicht für die Service-to-Service-Kommunikation, die Traffic-Management, Sicherheit und Observability übernimmt.

Architektur:

Hauptmerkmale:

1. Traffic Management:

• Load Balancing
• Circuit Breaking
• Retries und Timeouts
• Canary Deployments
• A/B-Testing

2. Sicherheit:

• mTLS-Verschlüsselung
• Authentifizierung
• Autorisierungsrichtlinien

3. Observability:

• Distributed Tracing
• Metrikenerfassung
• Zugriffsprotokollierung

Istio-Implementierung:

# Virtual Service for traffic routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        user-type:
          exact: premium
    route:
    - destination:
        host: reviews
        subset: v2
      weight: 100
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

---
# Destination Rule for load balancing
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Circuit Breaker-Konfiguration:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

mTLS-Sicherheit:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-read
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend"]
    to:
    - operation:
        methods: ["GET"]

Observability mit Kiali:

# Install Istio with observability addons
istioctl install --set profile=demo

# Deploy Kiali, Prometheus, Grafana, Jaeger
kubectl apply -f samples/addons/

# Access Kiali dashboard
istioctl dashboard kiali

Service Mesh Vergleich:

Wann zu verwenden:

• Microservice-Umgebungen, in denen gemeinsame Traffic-, Identitäts- und Observability-Richtlinien den Betriebsaufwand rechtfertigen
• Bedarf an erweitertem Traffic-Management
• Sicherheitsanforderungen (mTLS)
• Multi-Cluster-Bereitstellungen
• Observability-Anforderungen

Seltenheit: Häufig Schwierigkeit: Schwer

Design Patterns

5. Erläutern Sie das Circuit Breaker-Pattern und wann es verwendet werden sollte.

Antwort: Circuit Breaker verhindert kaskadierende Fehler in verteilten Systemen.

Zustände:

1. Closed: Normaler Betrieb
2. Open: Fehler erkannt, Anfragen schlagen schnell fehl
3. Half-Open: Testen, ob der Service wiederhergestellt wurde

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"
    OPEN = "open"
    HALF_OPEN = "half_open"

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60, success_threshold=2):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.success_threshold = success_threshold
        self.failures = 0
        self.successes = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
                self.successes = 0
            else:
                raise Exception("Circuit breaker ist OPEN")
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            raise e
    
    def on_success(self):
        self.failures = 0
        if self.state == CircuitState.HALF_OPEN:
            self.successes += 1
            if self.successes >= self.success_threshold:
                self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN

# Usage
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

Anwendungsfälle:

• Externe API-Aufrufe
• Datenbankverbindungen
• Microservice-Kommunikation
• Integrationen von Drittanbietern

Seltenheit: Häufig Schwierigkeit: Mittel-Schwer

Event-Driven-Architektur

6. Erläutern Sie die Event-Driven-Architektur und wann sie verwendet werden sollte.

Antwort: Event-Driven Architecture (EDA) verwendet Ereignisse, um zwischen entkoppelten Services zu triggern und zu kommunizieren.

Architektur:

Kernkonzepte:

1. Event:

• Unveränderliche Tatsache, die passiert ist
• Enthält relevante Daten
• Mit Zeitstempel versehen

2. Event Producer:

• Veröffentlicht Ereignisse
• Kennt keine Konsumenten

3. Event Consumer:

• Abonniert Ereignisse
• Verarbeitet asynchron

4. Event Bus/Broker:

• Leitet Ereignisse weiter
• Beispiele: Kafka, RabbitMQ, AWS EventBridge

Kafka-Implementierung:

from kafka import KafkaProducer, KafkaConsumer
import json
from datetime import datetime

# Event Producer
class OrderEventProducer:
    def __init__(self):
        self.producer = KafkaProducer(
            bootstrap_servers=['localhost:9092'],
            value_serializer=lambda v: json.dumps(v).encode('utf-8')
        )
    
    def publish_order_created(self, order_id, customer_id, items, total):
        event = {
            'event_type': 'OrderCreated',
            'event_id': str(uuid.uuid4()),
            'timestamp': datetime.utcnow().isoformat(),
            'data': {
                'order_id': order_id,
                'customer_id': customer_id,
                'items': items,
                'total': total
            }
        }
        self.producer.send('order-events', value=event)
        self.producer.flush()

# Event Consumer
class InventoryEventConsumer:
    def __init__(self):
        self.consumer = KafkaConsumer(
            'order-events',
            bootstrap_servers=['localhost:9092'],
            value_deserializer=lambda m: json.loads(m.decode('utf-8')),
            group_id='inventory-service'
        )
    
    def process_events(self):
        for message in self.consumer:
            event = message.value
            if event['event_type'] == 'OrderCreated':
                self.reserve_inventory(event['data'])
    
    def reserve_inventory(self, order_data):
        # Reserve inventory logic
        print(f"Reserving inventory for order {order_data['order_id']}")
        # Publish InventoryReserved event

Event-Sourcing-Pattern:

# Store events instead of current state
class EventStore:
    def __init__(self):
        self.events = []
    
    def append(self, event):
        self.events.append(event)
    
    def get_events(self, aggregate_id):
        return [e for e in self.events if e['aggregate_id'] == aggregate_id]

# Rebuild state from events
class OrderAggregate:
    def __init__(self, order_id):
        self.order_id = order_id
        self.status = 'pending'
        self.items = []
        self.total = 0
    
    def apply_event(self, event):
        if event['type'] == 'OrderCreated':
            self.items = event['data']['items']
            self.total = event['data']['total']
        elif event['type'] == 'OrderPaid':
            self.status = 'paid'
        elif event['type'] == 'OrderShipped':
            self.status = 'shipped'
    
    def rebuild_from_events(self, events):
        for event in events:
            self.apply_event(event)

CQRS (Command Query Responsibility Segregation):

Vorteile:

• Lose Kopplung
• Skalierbarkeit
• Flexibilität
• Audit-Trail (Event Sourcing)
• Echtzeitverarbeitung

Herausforderungen:

• Eventuelle Konsistenz
• Event-Schema-Evolution
• Debugging-Komplexität
• Doppelte Event-Verarbeitung

Anwendungsfälle:

• E-Commerce-Auftragsabwicklung
• Echtzeit-Analysen
• IoT-Datenverarbeitung
• Microservices-Kommunikation
• Audit- und Compliance-Systeme

Seltenheit: Häufig Schwierigkeit: Schwer

Disaster Recovery

7. Wie entwerfen Sie eine Disaster-Recovery-Strategie?

Antwort: DR stellt die Geschäftskontinuität bei Ausfällen sicher.

Wichtige Metriken:

• RTO (Recovery Time Objective): Maximal akzeptable Ausfallzeit
• RPO (Recovery Point Objective): Maximal akzeptabler Datenverlust

DR-Strategien:

Implementierungsbeispiel:

Automatisierung:

# Automated failover script
def initiate_failover():
    # 1. Stop writes to primary
    stop_primary_writes()
    
    # 2. Promote secondary database
    promote_secondary_to_primary()
    
    # 3. Update DNS
    update_route53_failover()
    
    # 4. Start DR region services
    start_dr_services()
    
    # 5. Verify health
    verify_dr_health()
    
    # 6. Notify team
    send_alert("Failover completed to DR region")

Testen:

• Regelmäßige DR-Übungen je nach Kritikalität des Workloads
• Automatisierte Tests
• Dokumentierte Runbooks
• Post-Incident Reviews

Seltenheit: Sehr Häufig Schwierigkeit: Schwer

Sicherheit & Compliance

8. Wie implementieren Sie Zero-Trust-Sicherheit in der Cloud-Architektur?

Antwort: Zero Trust geht von keinem impliziten Vertrauen aus, sondern verifiziert alles.

Prinzipien:

1. Explizit verifizieren
2. Least Privilege Access
3. Von einer Sicherheitsverletzung ausgehen

Implementierung:

Komponenten:

1. Identity & Access:

# Example: Conditional access policy
policies:
  - name: "Require MFA for sensitive apps"
    conditions:
      applications: ["finance-app", "hr-system"]
      users: ["all"]
    controls:
      - require_mfa: true
      - require_compliant_device: true
      - allowed_locations: ["corporate-network", "vpn"]

2. Netzwerksegmentierung:

• Mikrosegmentierung
• Service Mesh (Istio, Linkerd)
• Netzwerkrichtlinien

3. Verschlüsselung:

• Daten im Ruhezustand
• Daten während der Übertragung
• End-to-End-Verschlüsselung

4. Kontinuierliche Überwachung:

• Echtzeit-Bedrohungserkennung
• Verhaltensanalysen
• Automatisierte Reaktion

Seltenheit: Häufig Schwierigkeit: Schwer

Kostenoptimierung

9. Wie optimieren Sie die Kosten über mehrere Cloud-Anbieter hinweg?

Antwort: Multi-Cloud-Kostenoptimierungsstrategien:

1. Workload-Platzierung:

• Analyse der Preismodelle
• Berücksichtigung der Datenübertragungskosten
• Nutzung regionaler Preisunterschiede

2. Reservierte Kapazität:

• AWS Reserved Instances
• Azure Reserved VM Instances
• GCP Committed Use Discounts

3. Spot/Preemptible Instances:

# Kostenvergleich: aktuelle Werte aus Cloud-Rechnern eintragen
def compare_options(options):
    return sorted(options, key=lambda option: (
        option["monthly_cost"],
        option["operational_risk"],
        option["commitment_months"]
    ))

4. Überwachung & Governance:

• Einheitliche Kosten-Dashboards
• Budget-Alerts
• Tag-basierte Kostenallokation
• Automatisierte Ressourcenbereinigung

5. Architektur-Optimierung:

• Serverless für variable Workloads
• Auto-Scaling-Richtlinien
• Storage Tiering
• CDN für statische Inhalte

Seltenheit: Sehr Häufig Schwierigkeit: Mittel-Schwer

Schlussfolgerung

Cloud-Architect-Interviews belohnen praktische Entscheidungsfähigkeit mehr als auswendig gelernte Diagramme. Bereiten Sie vor, wie Sie Folgendes erklären:

1. Multi-Cloud: Warum ein Workload mehr als einen Provider braucht und welche Komplexität dadurch entsteht
2. Migration: 7R-Optionen, Abhängigkeitsanalyse, phasenweiser Cutover, Rollback und Optimierung nach der Migration
3. Microservices: Grenzen, Datenhoheit, API-Verträge, Resilienz und Betriebskosten
4. Service Mesh: Wann mTLS, Traffic Policies und Observability die zusätzliche Plattformschicht rechtfertigen
5. Design Patterns: Circuit Breaker, Saga, CQRS, Idempotenz, Retries und Timeouts
6. Event-Driven Systems: Event-Verträge, Reihenfolge, Duplikate, Schemaentwicklung und eventual consistency
7. Disaster Recovery: RTO/RPO, Regionsstrategie, Runbooks, Tests und Nachweise zur Wiederherstellung
8. Sicherheit: Identitätsbasierter Zugriff, Least Privilege, Verschlüsselung, Segmentierung, Logging und Assume-Breach-Denken
9. Kostenoptimierung: Rightsizing, Commitments, Tagging, Aufräumen ungenutzter Ressourcen, Datentransfer und FinOps-Governance

Beginnen Sie Ihre Antwort mit der geschäftlichen Einschränkung, nennen Sie den Trade-off und erklären Sie, wie Sie das Design in Produktion validieren würden.