dicembre 21, 2025
15 min di lettura

Domande da colloquio per Senior DevOps Engineer in produzione

interview
career-advice
job-search
Domande da colloquio per Senior DevOps Engineer in produzione
Milad Bonakdar

Milad Bonakdar

Autore

Preparati con domande pratiche su Kubernetes, stato Terraform, GitOps, sicurezza, osservabilità, incident response e trade-off dei sistemi di produzione.


Cosa valuta un colloquio DevOps senior

Un colloquio DevOps senior valuta soprattutto la capacità di gestire sistemi in produzione, non solo di nominare strumenti. Aspettati scenari su guasti Kubernetes, sicurezza dello stato Terraform, rollout GitOps, resilienza cloud, controlli di sicurezza, osservabilità e gestione degli incidenti.

Usa questa guida per esercitarti con risposte che mostrano giudizio: cosa controlli per primo, quale rischio riduci, come validi la correzione e quale trade-off spieghi a engineering, security o product.


Kubernetes Avanzato

1. Spiega l'architettura di Kubernetes e il ruolo dei componenti chiave.

Risposta: Kubernetes usa un'architettura composta da control plane e nodi worker. Una risposta senior solida spiega sia i componenti sia come lo stato desiderato attraversa il sistema:

Componenti del Piano di Controllo:

  • API Server: Frontend per il piano di controllo di Kubernetes, gestisce tutte le richieste REST
  • etcd: Archivio chiave-valore distribuito per lo stato del cluster
  • Scheduler: Assegna i pod ai nodi in base ai requisiti di risorse
  • Controller Manager: Esegue i processi del controller (replica, endpoint, ecc.)
  • Cloud Controller Manager: Si integra con le API del provider cloud

Componenti del Nodo:

  • kubelet: Agente che garantisce che i container siano in esecuzione nei pod
  • kube-proxy: Mantiene le regole di rete per la comunicazione dei pod
  • Container Runtime: Esegue i container (Docker, containerd, CRI-O)
Loading diagram...

Come funziona:

  1. L'utente invia la distribuzione tramite kubectl
  2. L'API Server convalida e memorizza in etcd
  3. Lo Scheduler assegna i pod ai nodi
  4. kubelet sul nodo crea i container
  5. kube-proxy configura la rete

Frequenza: Molto Comune Difficoltà: Difficile


2. Come risolvi un pod bloccato in CrashLoopBackOff?

Risposta: Approccio di debug sistematico:

# 1. Controlla lo stato del pod e gli eventi
kubectl describe pod <nome-pod>
# Cerca: Errori di pull dell'immagine, limiti di risorse, controlli di integrità non riusciti

# 2. Controlla i log
kubectl logs <nome-pod>
kubectl logs <nome-pod> --previous  # Log del container precedente

# 3. Controlla i vincoli delle risorse
kubectl top pod <nome-pod>
kubectl describe node <nome-nodo>

# 4. Controlla i probe di liveness/readiness
kubectl get pod <nome-pod> -o yaml | grep -A 10 livenessProbe

# 5. Esegui l'accesso al container (se rimane attivo brevemente)
kubectl exec -it <nome-pod> -- /bin/sh

# 6. Controlla l'immagine
kubectl get pod <nome-pod> -o jsonpath='{.spec.containers[*].image}'
docker pull <immagine>  # Testa localmente

# 7. Controlla ConfigMap/Secrets
kubectl get configmap
kubectl get secret

# 8. Rivedi la specifica di deployment/pod
kubectl get deployment <nome-deployment> -o yaml

Cause comuni:

  • L'applicazione si arresta in modo anomalo all'avvio
  • Variabili d'ambiente mancanti
  • Configurazione errata del probe di liveness
  • Risorse insufficienti (OOMKilled)
  • Errori di pull dell'immagine
  • Dipendenze mancanti

Esempio di correzione:

# Aumenta i limiti delle risorse
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# Regola i tempi del probe
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Dai all'app il tempo di avviarsi
  periodSeconds: 10
  failureThreshold: 3

Frequenza: Molto Comune Difficoltà: Media


3. Spiega il networking di Kubernetes: Services, Ingress e Network Policies.

Risposta: Livelli di networking di Kubernetes:

Services: Tipi di esposizione del servizio:

# ClusterIP (solo interno)
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

# NodePort (accesso esterno tramite IP del nodo)
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer (load balancer cloud)
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress: Routing HTTP/HTTPS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls

Network Policies: Controlla la comunicazione pod-to-pod:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Frequenza: Molto Comune Difficoltà: Difficile


4. Come implementi l'autoscaling in Kubernetes?

Risposta: Molteplici strategie di autoscaling:

Horizontal Pod Autoscaler (HPA):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

Vertical Pod Autoscaler (VPA):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"  # or "Recreate", "Initial", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Cluster Autoscaler: Regola automaticamente le dimensioni del cluster in base ai pod in sospeso:

# Esempio AWS
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  min-nodes: "2"
  max-nodes: "10"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"

Frequenza: Comune Difficoltà: Media


Terraform Avanzato

5. Spiega la gestione dello stato di Terraform e le best practice.

Risposta: Lo stato di Terraform tiene traccia dell'infrastruttura ed è fondamentale per le operazioni.

Configurazione dello Stato Remoto:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

State Locking:

# Tabella DynamoDB per il state locking
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Best Practices:

1. Non committare mai i file di stato su Git

# .gitignore
*.tfstate
*.tfstate.*
.terraform/

2. Usa i workspace per gli ambienti

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

terraform workspace select dev
terraform apply

3. Importa le risorse esistenti

# Importa l'istanza EC2 esistente
terraform import aws_instance.web i-1234567890abcdef0

# Verifica
terraform plan

4. Manipolazione dello stato (usa con cautela)

# Elenca le risorse nello stato
terraform state list

# Mostra una risorsa specifica
terraform state show aws_instance.web

# Sposta la risorsa nello stato
terraform state mv aws_instance.old aws_instance.new

# Rimuovi la risorsa dallo stato (non la elimina)
terraform state rm aws_instance.web

5. Esegui il backup dello stato prima di modifiche importanti

terraform state pull > backup.tfstate

Frequenza: Molto Comune Difficoltà: Difficile


6. Come strutturi il codice Terraform per progetti di grandi dimensioni?

Risposta: Struttura modulare per la manutenibilità:

Struttura delle Directory:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks/
│   ├── rds/
│   └── s3/
└── global/
    ├── iam/
    └── route53/

Esempio di Modulo:

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-vpc"
    }
  )
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# modules/vpc/variables.tf
variable "vpc_cidr" {
  description = "Blocco CIDR per VPC"
  type        = string
}

variable "environment" {
  description = "Nome dell'ambiente"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "Blocchi CIDR per le subnet private"
  type        = list(string)
}

variable "availability_zones" {
  description = "Availability zone"
  type        = list(string)
}

variable "tags" {
  description = "Tag comuni"
  type        = map(string)
  default     = {}
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

Utilizzo dei Moduli:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr             = "10.0.0.0/16"
  environment          = "prod"
  private_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  availability_zones   = ["us-east-1a", "us-east-1b", "us-east-1c"]

  tags = {
    Project   = "MyApp"
    ManagedBy = "Terraform"
  }
}

module "eks" {
  source = "../../modules/eks"

  cluster_name    = "prod-cluster"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  node_group_size = 3
}

Frequenza: Comune Difficoltà: Difficile


Architettura Cloud

7. Progetta un'architettura multi-region ad alta disponibilità su AWS.

Risposta: Architettura multi-region per l'alta disponibilità:

Loading diagram...

Componenti Chiave:

1. DNS e Gestione del Traffico:

# Route 53 con health check
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

2. Replica del Database:

# RDS con replica di lettura cross-region
resource "aws_db_instance" "primary" {
  identifier           = "prod-db-primary"
  engine               = "postgres"
  instance_class       = "db.r5.xlarge"
  multi_az             = true
  backup_retention_period = 7

  provider = aws.us-east-1
}

resource "aws_db_instance" "replica" {
  identifier             = "prod-db-replica"
  replicate_source_db    = aws_db_instance.primary.arn
  instance_class         = "db.r5.xlarge"
  auto_minor_version_upgrade = false

  provider = aws.us-west-2
}

3. Replica dei Dati:

# S3 cross-region replication
resource "aws_s3_bucket_replication_configuration" "replication" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD"
    }
  }
}

Principi di Progettazione:

  • Configurazione attivo-attivo o attivo-passivo
  • Failover automatizzato con health check
  • Replica dei dati con ritardo minimo
  • Distribuzione coerente tra le regioni
  • Monitoraggio e avvisi per entrambe le regioni

Frequenza: Comune Difficoltà: Difficile


GitOps e CI/CD

8. Spiega GitOps e come implementarlo con ArgoCD.

Risposta: GitOps utilizza Git come unica fonte di verità per l'infrastruttura e le applicazioni dichiarative.

Principi:

  1. Configurazione dichiarativa in Git
  2. Sincronizzazione automatizzata
  3. Controllo della versione per tutte le modifiche
  4. Riconciliazione continua

Implementazione di ArgoCD:

# Manifest dell'applicazione
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/app-manifests
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Struttura delle Directory:

app-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patches/
    ├── staging/
    └── production/
        ├── kustomization.yaml
        ├── replicas.yaml
        └── resources.yaml

Kustomization:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

replicas:
- name: myapp
  count: 5

resources:
- ingress.yaml

patches:
- path: resources.yaml
  target:
    kind: Deployment
    name: myapp

Vantaggi:

  • Git come audit trail
  • Facili rollback (git revert)
  • Stato desiderato dichiarativo
  • Rilevamento automatico della deriva
  • Gestione multi-cluster

Frequenza: Comune Difficoltà: Media


Sicurezza e Conformità

9. Come implementi le best practice di sicurezza in Kubernetes?

Risposta: Approccio di sicurezza a più livelli:

1. Pod Security Standards:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. RBAC (Role-Based Access Control):

# Ruolo per gli sviluppatori
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

3. Network Policies:

# Nega per impostazione predefinita tutto l'ingresso
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. Gestione dei Segreti:

# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
    creationPolicy: Owner
  data:
  - secretKey: database-password
    remoteRef:
      key: prod/database
      property: password

5. Security Context:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

6. Scansione delle Immagini:

# Admission controller con OPA
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      image := input.request.object.spec.containers[_].image
      not startswith(image, "registry.company.com/")
      msg := sprintf("Image %v is not from approved registry", [image])
    }

Frequenza: Molto Comune Difficoltà: Difficile


Osservabilità e SRE

10. Progetta uno stack di osservabilità completo.

Risposta: Tre pilastri dell'osservabilità: Metriche, Log, Tracce

Architettura:

Loading diagram...

1. Metriche (Prometheus + Grafana):

# ServiceMonitor per le metriche dell'app
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

2. Logging (Loki):

# Configurazione di Promtail per la raccolta dei log
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
    
    clients:
      - url: http://loki:3100/loki/api/v1/push
    
    scrape_configs:
      - job_name: kubernetes-pods
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_app]
            target_label: app
          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

3. Tracing (Jaeger):

# Strumentazione dell'applicazione
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# Imposta il tracing
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger-agent",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

tracer = trace.get_tracer(__name__)

# Usa nel codice
with tracer.start_as_current_span("process_request"):
    # Il tuo codice qui
    pass

4. Regole di Avviso:

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
spec:
  groups:
  - name: app
    interval: 30s
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
        > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Rilevato un alto tasso di errore"
        description: "Il tasso di errore è {{ $value | humanizePercentage }}"
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Rilevata un'alta latenza"

5. Monitoraggio SLO:

# Definizione SLO
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: api-availability
spec:
  service: "api"
  labels:
    team: "platform"
  slos:
    - name: "requests-availability"
      objective: 99.9
      description: "Le richieste API dovrebbero avere successo"
      sli:
        events:
          errorQuery: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
          totalQuery: sum(rate(http_requests_total[{{.window}}]))
      alerting:
        pageAlert:
          labels:
            severity: critical
        ticketAlert:
          labels:
            severity: warning

Frequenza: Comune Difficoltà: Difficile


Disaster Recovery

11. Come implementi il disaster recovery per un cluster Kubernetes?

Risposta: Strategia DR completa:

1. Strategia di Backup:

# Pianificazione del backup di Velero
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"  # 2 AM daily
  template:
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    storageLocation: aws-s3
    volumeSnapshotLocations:
    - aws-ebs
    ttl: 720h  # 30 giorni

2. Backup di etcd:

#!/bin/bash
# Script di backup automatizzato di etcd

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# Carica su S3
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# Pulisci i vecchi backup
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. Procedura di Ripristino:

# Ripristina etcd dallo snapshot
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
  --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-0=https://10.0.1.10:2380 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Ripristina l'applicazione con Velero
velero restore create --from-backup daily-backup-20231125
velero restore describe <nome-ripristino>

4. Failover Multi-Region:

# Terraform per la configurazione multi-region
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... configuration
}

module "dr_cluster" {
  source = "./modules/eks"
  region = "us-west-2"
  # ... configuration
}

# Route 53 health check e failover
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

5. Obiettivi RTO/RPO:

  • RTO (Recovery Time Objective): < 1 ora
  • RPO (Recovery Point Objective): < 15 minuti
  • Esercitazioni DR regolari (mensili)
  • Runbook documentati
  • Failover automatizzato ove possibile

Frequenza: Comune Difficoltà: Difficile


Service Mesh

12. Spiega l'architettura del service mesh e quando usarlo.

Risposta: Un service mesh fornisce un livello di infrastruttura per la comunicazione service-to-service.

Componenti Principali:

Loading diagram...

Implementazione di Istio:

# Virtual Service per il routing del traffico
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v2
      weight: 20

# Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Quando usarlo:

  • Comunicazione complessa tra microservizi
  • mTLS, autorizzazione e regole di traffico coerenti
  • Canary release, traffic splitting e migliore isolamento dei guasti
  • Osservabilità condivisa per le chiamate service-to-service

Attenzione: Un service mesh aggiunge complessità, latenza e carico operativo. In un colloquio senior, spiega perché il beneficio giustifica questi costi nel sistema specifico.


Conclusione

Non preparare solo definizioni di strumenti. Per ogni risposta, mostra come isoleresti un problema di produzione, come daresti priorità ai rischi, come valideresti la correzione e come trasformeresti l'apprendimento in un miglioramento duraturo.

Newsletter subscription

Consigli di carriera settimanali che funzionano davvero

Ricevi le ultime idee direttamente nella tua casella di posta

Crea un Curriculum che Ti Faccia Assumere il 60% Più Velocemente

In pochi minuti, crea un curriculum personalizzato e compatibile con ATS che ha dimostrato di ottenere 6 volte più colloqui.

Crea un curriculum migliore

Condividi questo post

Batti il Tasso di Rifiuto ATS del 75%

3 curriculum su 4 non raggiungono mai un occhio umano. La nostra ottimizzazione delle parole chiave aumenta il tuo tasso di successo fino all'80%, assicurando che i reclutatori vedano effettivamente il tuo potenziale.