Domande da colloquio per Senior DevOps Engineer in produzione

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)
Come funziona:
- L'utente invia la distribuzione tramite kubectl
- L'API Server convalida e memorizza in etcd
- Lo Scheduler assegna i pod ai nodi
- kubelet sul nodo crea i container
- kube-proxy configura la rete
Frequenza: Molto Comune Difficoltà: Difficile
2. Come risolvi un pod bloccato in CrashLoopBackOff?
Risposta: Approccio di debug sistematico:
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:
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:
Ingress: Routing HTTP/HTTPS:
Network Policies: Controlla la comunicazione pod-to-pod:
Frequenza: Molto Comune Difficoltà: Difficile
4. Come implementi l'autoscaling in Kubernetes?
Risposta: Molteplici strategie di autoscaling:
Horizontal Pod Autoscaler (HPA):
Vertical Pod Autoscaler (VPA):
Cluster Autoscaler: Regola automaticamente le dimensioni del cluster in base ai pod in sospeso:
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:
State Locking:
Best Practices:
1. Non committare mai i file di stato su Git
2. Usa i workspace per gli ambienti
3. Importa le risorse esistenti
4. Manipolazione dello stato (usa con cautela)
5. Esegui il backup dello stato prima di modifiche importanti
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:
Esempio di Modulo:
Utilizzo dei Moduli:
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à:
Componenti Chiave:
1. DNS e Gestione del Traffico:
2. Replica del Database:
3. Replica dei Dati:
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:
- Configurazione dichiarativa in Git
- Sincronizzazione automatizzata
- Controllo della versione per tutte le modifiche
- Riconciliazione continua
Implementazione di ArgoCD:
Struttura delle Directory:
Kustomization:
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:
2. RBAC (Role-Based Access Control):
3. Network Policies:
4. Gestione dei Segreti:
5. Security Context:
6. Scansione delle Immagini:
Frequenza: Molto Comune Difficoltà: Difficile
Osservabilità e SRE
10. Progetta uno stack di osservabilità completo.
Risposta: Tre pilastri dell'osservabilità: Metriche, Log, Tracce
Architettura:
1. Metriche (Prometheus + Grafana):
2. Logging (Loki):
3. Tracing (Jaeger):
4. Regole di Avviso:
5. Monitoraggio SLO:
Frequenza: Comune Difficoltà: Difficile
Disaster Recovery
11. Come implementi il disaster recovery per un cluster Kubernetes?
Risposta: Strategia DR completa:
1. Strategia di Backup:
2. Backup di etcd:
3. Procedura di Ripristino:
4. Failover Multi-Region:
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:
Implementazione di Istio:
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.


