décembre 21, 2025
15 min de lecture

Questions d'entretien pour Ingénieur DevOps Senior : Guide Complet

interview
career-advice
job-search
Questions d'entretien pour Ingénieur DevOps Senior : Guide Complet
Milad Bonakdar

Milad Bonakdar

Auteur

Maîtrisez les concepts DevOps avancés avec des questions d'entretien complètes couvrant Kubernetes, Terraform, l'architecture cloud, GitOps, la sécurité, les pratiques SRE et la haute disponibilité pour les ingénieurs DevOps seniors.


Introduction

On attend des ingénieurs DevOps seniors qu'ils conçoivent des infrastructures évolutives, mettent en œuvre une automatisation avancée, garantissent la sécurité et la conformité, et promeuvent une culture DevOps à travers les organisations. Ce rôle exige une expertise approfondie en orchestration de conteneurs, infrastructure as code, architecture cloud et ingénierie de la fiabilité des sites.

Ce guide complet couvre les questions d'entretien essentielles pour les ingénieurs DevOps seniors, en se concentrant sur les concepts avancés, les systèmes de production et la pensée stratégique. Chaque question comprend des explications détaillées et des exemples pratiques.


Kubernetes Avancé

1. Expliquez l'architecture de Kubernetes et le rôle des composants clés.

Réponse : Kubernetes suit une architecture maître-esclave :

Composants du plan de contrôle :

  • API Server : Interface pour le plan de contrôle Kubernetes, gère toutes les requêtes REST
  • etcd : Magasin clé-valeur distribué pour l'état du cluster
  • Scheduler : Attribue les pods aux nœuds en fonction des besoins en ressources
  • Controller Manager : Exécute les processus du contrôleur (réplication, points de terminaison, etc.)
  • Cloud Controller Manager : S'intègre aux API du fournisseur de cloud

Composants du nœud :

  • kubelet : Agent qui garantit que les conteneurs sont en cours d'exécution dans les pods
  • kube-proxy : Maintient les règles de réseau pour la communication des pods
  • Container Runtime : Exécute les conteneurs (Docker, containerd, CRI-O)
Loading diagram...

Comment ça marche :

  1. L'utilisateur soumet le déploiement via kubectl
  2. API Server valide et stocke dans etcd
  3. Scheduler attribue les pods aux nœuds
  4. kubelet sur le nœud crée des conteneurs
  5. kube-proxy configure le réseau

Fréquence : Très Courant Difficulté : Difficile


2. Comment dépannez-vous un pod bloqué dans CrashLoopBackOff ?

Réponse : Approche de débogage systématique :

# 1. Vérifiez l'état et les événements du pod
kubectl describe pod <nom-du-pod>
# Recherchez : les erreurs d'extraction d'image, les limites de ressources, les contrôles d'intégrité échoués

# 2. Vérifiez les logs
kubectl logs <nom-du-pod>
kubectl logs <nom-du-pod> --previous  # Logs du conteneur précédent

# 3. Vérifiez les contraintes de ressources
kubectl top pod <nom-du-pod>
kubectl describe node <nom-du-nœud>

# 4. Vérifiez les sondes de vivacité/disponibilité
kubectl get pod <nom-du-pod> -o yaml | grep -A 10 livenessProbe

# 5. Exécutez-vous dans le conteneur (s'il reste brièvement actif)
kubectl exec -it <nom-du-pod> -- /bin/sh

# 6. Vérifiez l'image
kubectl get pod <nom-du-pod> -o jsonpath='{.spec.containers[*].image}'
docker pull <image>  # Testez localement

# 7. Vérifiez les ConfigMaps/Secrets
kubectl get configmap
kubectl get secret

# 8. Examinez la spécification du déploiement/pod
kubectl get deployment <nom-du-déploiement> -o yaml

Causes courantes :

  • Plantage de l'application au démarrage
  • Variables d'environnement manquantes
  • Configuration incorrecte de la sonde de vivacité
  • Ressources insuffisantes (OOMKilled)
  • Erreurs d'extraction d'image
  • Dépendances manquantes

Exemple de correction :

# Augmentez les limites de ressources
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# Ajustez le timing de la sonde
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Donnez à l'application le temps de démarrer
  periodSeconds: 10
  failureThreshold: 3

Fréquence : Très Courant Difficulté : Moyenne


3. Expliquez le réseau Kubernetes : Services, Ingress et Network Policies.

Réponse : Couches de réseau Kubernetes :

Services : Types d'exposition de service :

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

# NodePort (accès externe via l'IP du nœud)
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer (équilibreur de charge cloud)
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress : Routage 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 : Contrôlez la communication pod-à-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

Fréquence : Très Courant Difficulté : Difficile


4. Comment implémentez-vous l'autoscaling dans Kubernetes ?

Réponse : Plusieurs stratégies d'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 : Ajuste automatiquement la taille du cluster en fonction des pods en attente :

# Exemple 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"

Fréquence : Courant Difficulté : Moyenne


Terraform Avancé

5. Expliquez la gestion de l'état de Terraform et les meilleures pratiques.

Réponse : L'état de Terraform suit l'infrastructure et est essentiel pour les opérations.

Configuration de l'état à distance :

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

Verrouillage d'état :

# Table DynamoDB pour le verrouillage d'état
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

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

Meilleures pratiques :

1. Ne jamais commiter les fichiers d'état dans Git

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

2. Utilisez des espaces de travail pour les environnements

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

terraform workspace select dev
terraform apply

3. Importez les ressources existantes

# Importez une instance EC2 existante
terraform import aws_instance.web i-1234567890abcdef0

# Vérifiez
terraform plan

4. Manipulation d'état (utilisez avec précaution)

# Listez les ressources dans l'état
terraform state list

# Affichez une ressource spécifique
terraform state show aws_instance.web

# Déplacez une ressource dans l'état
terraform state mv aws_instance.old aws_instance.new

# Supprimez une ressource de l'état (ne la supprime pas)
terraform state rm aws_instance.web

5. Sauvegardez l'état avant des changements majeurs

terraform state pull > backup.tfstate

Fréquence : Très Courant Difficulté : Difficile


6. Comment structurez-vous le code Terraform pour les grands projets ?

Réponse : Structure modulaire pour la maintenabilité :

Structure de répertoire :

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/

Exemple de module :

# 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 = "Bloc CIDR pour VPC"
  type        = string
}

variable "environment" {
  description = "Nom de l'environnement"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "Blocs CIDR pour les sous-réseaux privés"
  type        = list(string)
}

variable "availability_zones" {
  description = "Zones de disponibilité"
  type        = list(string)
}

variable "tags" {
  description = "Tags communs"
  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
}

Utilisation des modules :

# 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
}

Fréquence : Courant Difficulté : Difficile


Architecture Cloud

7. Concevez une architecture multirégionale à haute disponibilité sur AWS.

Réponse : Architecture multirégionale pour une haute disponibilité :

Loading diagram...

Composants clés :

1. DNS et gestion du trafic :

# Route 53 avec des contrôles d'intégrité
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. Réplication de la base de données :

# RDS avec une réplique de lecture interrégionale
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. Réplication des données :

# Réplication interrégionale S3
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"
    }
  }
}

Principes de conception :

  • Configuration actif-actif ou actif-passif
  • Basculement automatisé avec des contrôles d'intégrité
  • Réplication des données avec un minimum de latence
  • Déploiement cohérent dans toutes les régions
  • Surveillance et alerte pour les deux régions

Fréquence : Courant Difficulté : Difficile


GitOps et CI/CD

8. Expliquez GitOps et comment l'implémenter avec ArgoCD.

Réponse : GitOps utilise Git comme source unique de vérité pour l'infrastructure et les applications déclaratives.

Principes :

  1. Configuration déclarative dans Git
  2. Synchronisation automatisée
  3. Contrôle de version pour tous les changements
  4. Réconciliation continue

Implémentation ArgoCD :

# Manifeste d'application
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

Structure de répertoire :

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

Avantages :

  • Git comme piste d'audit
  • Rollbacks faciles (git revert)
  • État souhaité déclaratif
  • Détection automatisée de la dérive
  • Gestion multi-cluster

Fréquence : Courant Difficulté : Moyenne


Sécurité et Conformité

9. Comment implémentez-vous les meilleures pratiques de sécurité dans Kubernetes ?

Réponse : Approche de sécurité multicouche :

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) :

# Rôle pour les développeurs
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 :

# Refus par défaut de tout trafic entrant
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. Gestion des secrets :

# 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. Analyse des images :

# Contrôleur d'admission avec 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])
    }

Fréquence : Très Courant Difficulté : Difficile


Observabilité et SRE

10. Concevez une pile d'observabilité complète.

Réponse : Trois piliers de l'observabilité : Métriques, Logs, Traces

Architecture :

Loading diagram...

1. Métriques (Prometheus + Grafana) :

# ServiceMonitor pour les métriques de l'application
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) :

# Configuration Promtail pour la collecte de logs
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) :

# Instrumentation de l'application
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# Configuration du 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__)

# Utilisation dans le code
with tracer.start_as_current_span("process_request"):
    # Votre code ici
    pass

4. Règles d'alerte :

# 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: "High error rate detected"
        description: "Error rate is {{ $value | humanizePercentage }}"
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "High latency detected"

5. SLO Monitoring :

# Définition 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: "API requests should succeed"
      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

Fréquence : Courant Difficulté : Difficile


Reprise après sinistre

11. Comment implémentez-vous la reprise après sinistre pour un cluster Kubernetes ?

Réponse : Stratégie de reprise après sinistre complète :

1. Stratégie de sauvegarde :

# Planification de sauvegarde 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 days

2. Sauvegarde etcd :

#!/bin/bash
# Script de sauvegarde etcd automatisé

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

# Télécharger vers S3
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# Nettoyer les anciennes sauvegardes
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. Procédure de restauration :

# Restaurer etcd à partir d'un instantané
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

# Restaurer l'application avec Velero
velero restore create --from-backup daily-backup-20231125
velero restore describe <nom-de-restauration>

4. Basculement multirégional :

# Terraform pour la configuration multirégionale
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... configuration
}

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

# Contrôle d'intégrité et basculement Route 53
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

5. Objectifs RTO/RPO :

  • RTO (Recovery Time Objective) : < 1 heure
  • RPO (Recovery Point Objective) : < 15 minutes
  • Exercices de reprise après sinistre réguliers (mensuels)
  • Manuels d'exécution documentés
  • Basculement automatisé si possible

Fréquence : Courant Difficulté : Difficile


Service Mesh

12. Expliquez l'architecture du service mesh et quand l'utiliser.

Réponse : Un service mesh fournit une couche d'infrastructure pour la communication service à service.

Composants principaux :

Loading diagram...

Implémentation Istio :

# Virtual Service pour le routage du trafic
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
Newsletter subscription

Conseils de carrière hebdomadaires qui fonctionnent vraiment

Recevez les dernières idées directement dans votre boîte de réception

Créez un CV qui Vous Fait Embaucher 60% Plus Vite

En quelques minutes, créez un CV personnalisé et compatible ATS qui a prouvé obtenir 6 fois plus d'entretiens.

Créer un meilleur CV

Partager cet article

Réduisez Votre Temps de Rédaction de CV de 90%

Le chercheur d'emploi moyen passe plus de 3 heures à formater un CV. Notre IA le fait en moins de 15 minutes, vous permettant d'atteindre la phase de candidature 12 fois plus rapidement.