dicembre 21, 2025
15 min di lettura

Domande per il colloquio di Senior DevOps Engineer: Guida Completa

interview
career-advice
job-search
Domande per il colloquio di Senior DevOps Engineer: Guida Completa
MB

Milad Bonakdar

Autore

Padroneggia i concetti avanzati di DevOps con domande complete per il colloquio che coprono Kubernetes, Terraform, architettura cloud, GitOps, sicurezza, pratiche SRE e alta disponibilità per Senior DevOps Engineer.


Introduzione

I senior DevOps engineer devono essere in grado di progettare infrastrutture scalabili, implementare automazione avanzata, garantire sicurezza e conformità e promuovere la cultura DevOps all'interno delle organizzazioni. Questo ruolo richiede una profonda competenza nell'orchestrazione di container, nell'infrastructure as code, nell'architettura cloud e nella site reliability engineering.

Questa guida completa copre le domande di colloquio essenziali per i senior DevOps engineer, concentrandosi su concetti avanzati, sistemi di produzione e pensiero strategico. Ogni domanda include spiegazioni dettagliate ed esempi pratici.


Kubernetes Avanzato

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

Risposta: Kubernetes segue un'architettura master-worker:

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
Newsletter subscription

Consigli di carriera settimanali che funzionano davvero

Ricevi le ultime idee direttamente nella tua casella di posta

Decorative doodle

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.