[{"data":1,"prerenderedAt":614},["ShallowReactive",2],{"deck:devops":3},{"deck":4,"reason":612,"status":613},{"id":5,"stem":6,"matiere":7,"name":8,"punchline":9,"deckStatus":10,"customMessages":11,"sources":21,"cards":31},"devops","decks/devops","informatique","DevOps","Qui crée quoi, dans quel ordre","publié",{"low":12,"medium":15,"high":18},[13,14],"CI, CD, artefact : on pose la chaîne","Qui crée quoi, c'est la question",[16,17],"Terraform en bas, Helm en haut, Git au milieu","Les couches se dessinent",[19,20],"Push, pull, promotion, rollback : tu lis la plateforme d'un coup d'œil","Synced, Healthy",[22,25,28],{"title":23,"url":24},"DORA — DevOps capabilities (Google)","https://dora.dev/capabilities/",{"title":26,"url":27},"Kubernetes Documentation","https://kubernetes.io/docs/",{"title":29,"url":30},"Terraform Documentation (HashiCorp)","https://developer.hashicorp.com/terraform/docs",[32,43,54,64,74,83,93,104,117,128,134,142,150,157,165,174,182,190,202,210,219,230,238,250,257,264,277,290,302,309,319,329,341,356,365,372,380,387,399,407,418,430,439,451,460,467,475,487,494,502,510,519,528,541,551,562,570,582,590,597],{"id":33,"tags":34,"question":37,"quick_answer":38,"details":39,"dependsOn":40,"difficulty":42},"k8s-010",[7,35,36],"kubernetes","concepts","Que signifie « Kubernetes est **déclaratif** » ?","On décrit l'état désiré, pas les actions ; le cluster converge vers cet état tout seul","On n'écrit pas « lance 3 conteneurs », on écrit `replicas: 3`. Si un Pod meurt, Kubernetes constate 2 ≠ 3 et en recrée un, sans qu'on intervienne. C'est la **boucle de réconciliation**.\n\nConséquence pratique : on applique des fichiers YAML (`kubectl apply`) plutôt que d'enchaîner des commandes impératives.",[41],"k8s-001",5,{"id":44,"tags":45,"question":48,"quick_answer":49,"details":50,"dependsOn":51,"difficulty":53},"tfm-001",[7,46,47],"terraform","iac","Qu'est-ce que **Terraform** ?","Un outil d'infrastructure as code déclaratif : on décrit l'infra en HCL, il applique les changements","Créé par HashiCorp en 2014. Multi-fournisseurs : le même langage pour AWS, GCP, Azure, Cloudflare, Kubernetes, GitHub… via des providers.\n\nOn n'écrit pas « crée une VM », on écrit « il existe une VM avec ces attributs ». Terraform compare à ce qui existe et fait le nécessaire.",[52],"tfm-047",3,{"id":55,"tags":56,"question":58,"quick_answer":59,"details":60,"dependsOn":61,"difficulty":63},"tfm-010",[7,46,57],"state","Qu'est-ce que le **state** Terraform ?","Le fichier qui associe chaque ressource de la config à son identifiant réel chez le fournisseur","`terraform.tfstate`, du JSON. Sans lui, Terraform ne sait pas que `aws_instance.web` est l'instance `i-0abc…` : il en créerait une deuxième.\n\nIl stocke aussi les attributs lus (IP, ARN) et les dépendances. C'est la mémoire de Terraform entre deux exécutions.",[62],"tfm-004",4,{"id":65,"tags":66,"question":67,"quick_answer":68,"details":69,"dependsOn":70,"difficulty":73},"tfm-046",[7,46,57],"Pourquoi **découper** un gros state en plusieurs ?","Un plan plus rapide, un rayon d'explosion limité, et des équipes qui n'attendent pas le même verrou","Un state unique de 2 000 ressources met des minutes à rafraîchir, et une erreur de config dans un module peut bloquer l'apply de tout le monde.\n\nDécoupe classique par couche et par environnement : `network/`, `cluster/`, `data/`, `apps/`, chacun avec son backend. Les liens passent par `terraform_remote_state` ou des data sources.",[71,72],"tfm-043","tfm-012",7,{"id":75,"tags":76,"question":78,"quick_answer":79,"details":80,"dependsOn":81,"difficulty":63},"k8s-042",[7,35,77],"outils","Qu'est-ce que **Helm** ?","Le gestionnaire de paquets de Kubernetes : des charts, templates YAML paramétrables","Un **chart** regroupe tous les manifestes d'une application avec des valeurs par défaut (`values.yaml`). `helm install monredis bitnami/redis --set auth.password=…` déploie Redis en une commande.\n\nAlternative sans templating : **Kustomize**, intégré à kubectl (`kubectl apply -k`), qui superpose des patches sur des YAML de base.",[82],"k8s-022",{"id":84,"tags":85,"question":88,"quick_answer":89,"details":90,"dependsOn":91,"difficulty":63},"dkr-044",[7,86,87],"docker","images","Comment garantir qu'on déploie **exactement** la même image qu'en test, indépendamment des tags ?","La référencer par son digest : image@sha256:…","Un tag peut être réécrit (quelqu'un repousse `app:1.2`). Le digest est le hash du contenu de l'image : immuable par construction. `docker pull nginx@sha256:abc…` ou `docker images --digests` pour les lire.\n\nC'est ce que font les outils de supply chain et les lockfiles d'images.",[92],"dkr-018",{"id":94,"tags":95,"question":99,"quick_answer":100,"details":101,"dependsOn":102,"difficulty":42},"aws-005",[7,96,97,98],"aws","iam","securite","Qu'est-ce qu'un **rôle IAM** ?","Une identité sans clé fixe, assumée par un service ou un utilisateur pour des identifiants temporaires","On attache un rôle à une instance EC2, une fonction Lambda ou un pod EKS : le code y récupère automatiquement des identifiants qui expirent et tournent.\n\nC'est la bonne pratique numéro un : **jamais de clé d'accès en dur** dans le code ou dans une image Docker. Un rôle se définit par sa **trust policy** (qui peut l'assumer) et ses **permission policies** (ce qu'il peut faire).",[103],"aws-004",{"id":105,"tags":106,"question":108,"quick_answer":109,"details":110,"dependsOn":111,"difficulty":63,"sources":113},"aws-049",[7,96,107],"conteneurs","Qu'est-ce qu'**EKS** ?","Kubernetes managé par AWS : control plane hébergé et opéré par AWS, nœuds à toi (ou Fargate)","Elastic Kubernetes Service. Un cluster EKS est un Kubernetes standard : manifests, Helm, operators fonctionnent tels quels, donc portabilité. En échange : plus de complexité qu'ECS et un coût fixe par cluster (environ 0,10 $/h) en plus des nœuds.\n\nLes identités IAM se mappent aux ServiceAccounts Kubernetes (IRSA / Pod Identity).",[41,112],"aws-031",[114],{"title":115,"url":116},"AWS — EKS pricing","https://aws.amazon.com/eks/pricing/",{"id":118,"tags":119,"question":122,"quick_answer":123,"details":124,"dependsOn":125,"difficulty":42},"auth-031",[7,120,121],"auth","oidc","Qu'est-ce qu'**OpenID Connect** (OIDC) ?","Une couche d'identité au-dessus d'OAuth 2.0 : elle ajoute l'authentification et l'ID token","OAuth dit « cette app peut accéder à ça ». OIDC ajoute « et voici **qui** est l'utilisateur connecté », de façon standardisée : ID token (un JWT), endpoint `/userinfo`, document de découverte, scopes `openid profile email`.\n\n« Se connecter avec Google / Microsoft / GitHub » = OIDC en pratique.",[126,127],"auth-020","auth-008",{"id":129,"tags":130,"question":131,"quick_answer":132,"details":133,"difficulty":53},"dvo-001",[7,5,36],"Qu'est-ce que le **DevOps** ?","Une façon de travailler où dev et ops partagent outils, responsabilités et boucle de feedback","Pas un poste ni un outil : une réponse au mur entre « dev » (qui veut livrer) et « ops » (qui veut la stabilité). Livrer souvent, par petits lots, avec de l'automatisation et de la mesure.\n\nLe reste du deck ne décrit pas les briques une par une (c'est le rôle des decks Docker, Kubernetes, AWS, Terraform) mais la façon dont elles s'emboîtent.",{"id":135,"tags":136,"question":138,"quick_answer":139,"details":140,"dependsOn":141,"difficulty":53},"dvo-002",[7,5,137],"ci","Qu'est-ce que l'**intégration continue** (CI) ?","Chaque commit poussé est automatiquement construit et testé","Lint, tests unitaires, build de l'image : un pipeline qui dit « ce commit est sain » en quelques minutes. Le but : détecter la casse tout de suite, pas à la fin du sprint.\n\nOutils : GitHub Actions, GitLab CI, Jenkins. La CI produit un **artefact** (une image), elle ne le déploie pas forcément.",[129],{"id":143,"tags":144,"question":146,"quick_answer":147,"details":148,"dependsOn":149,"difficulty":63},"dvo-003",[7,5,145],"cd","Qu'est-ce que le **continuous delivery** ?","L'artefact est toujours prêt à être déployé en production ; le déploiement reste une décision humaine","Après la CI, le pipeline déploie automatiquement en staging et prépare la prod. Un bouton ou une approbation déclenche la mise en prod.\n\nCe que ça exige : des déploiements automatisés et répétables, donc sans étape manuelle « sur le serveur ».",[135],{"id":151,"tags":152,"question":153,"quick_answer":154,"details":155,"dependsOn":156,"difficulty":63},"dvo-004",[7,5,145],"Qu'est-ce que le **continuous deployment** ?","Chaque commit qui passe le pipeline part en production, sans intervention humaine","Un cran au-dessus du delivery : plus de bouton. Ça suppose une grande confiance dans les tests, des déploiements progressifs (canary) et un rollback automatique.\n\nLes deux se notent « CD », d'où les confusions.",[143],{"id":158,"tags":159,"question":161,"quick_answer":162,"details":163,"dependsOn":164,"difficulty":42},"dvo-005",[7,5,160],"artefacts","Pourquoi construire l'image **une seule fois** et la promouvoir de staging à prod, plutôt que de la reconstruire par environnement ?","Pour déployer en prod exactement ce qui a été testé : même digest, zéro variation de build","Un rebuild par environnement peut tirer une dépendance différente, une base image mise à jour, un flag oublié. Ce qui a passé les tests en staging n'est plus ce qui tourne en prod.\n\nLa règle : un artefact immuable identifié par digest, et seule la **configuration** change d'un environnement à l'autre.",[84,143],{"id":166,"tags":167,"question":169,"answer":170,"details":171,"dependsOn":172,"difficulty":42},"dvo-006",[7,5,137,168],"pipeline","Quelles sont les trois étapes types d'un pipeline qui livre une application conteneurisée ?","1. **Build** : `docker build` de l'image, tests, tag par SHA du commit\n2. **Push** : l'image part dans le registre (ECR, GHCR)\n3. **Deploy** : la config de déploiement (manifest, Helm values) est mise à jour pour pointer vers le nouveau tag, puis appliquée au cluster","La troisième étape est celle qui varie : un `kubectl apply` ou `helm upgrade` lancé par la CI (push), ou un commit dans un repo de config qu'un agent GitOps tire (pull).",[135,173],"aws-033",{"id":175,"tags":176,"question":178,"quick_answer":179,"details":180,"dependsOn":181,"difficulty":42},"dvo-007",[7,5,46,35,177],"agencement","Dans une stack Terraform + Kubernetes + Helm, que crée **Terraform** ?","L'infrastructure sous le cluster : réseau, cluster lui-même, nœuds, IAM, bases, DNS, registre","VPC et sous-réseaux, cluster EKS et ses node groups, rôles IAM, RDS, buckets, zone Route 53, dépôts ECR. Tout ce qui existe **avant** qu'une application puisse tourner.\n\nTerraform s'arrête à la porte du cluster : il ne déploie pas les applications.",[44,41],{"id":183,"tags":184,"question":186,"quick_answer":187,"details":188,"dependsOn":189,"difficulty":42},"dvo-008",[7,5,35,185,177],"helm","Dans une stack Terraform + Kubernetes + Helm, qui déploie les **applications** sur le cluster ?","Helm (ou kubectl, Kustomize, Argo CD) : des manifests Kubernetes, pas du Terraform","Les Deployments, Services, Ingress d'une application vivent en YAML, templatés par Helm, et sont appliqués par la CI ou un agent GitOps.\n\nLe cycle de vie d'une appli (plusieurs déploiements par jour) n'est pas celui de l'infra (quelques changements par mois) : des outils différents pour des rythmes différents.",[175,75],{"id":191,"tags":192,"question":194,"quick_answer":195,"details":196,"dependsOn":197,"difficulty":73,"sources":198},"dvo-009",[7,5,46,35,193],"pieges","Pourquoi ne pas créer le cluster **et** y déployer des ressources Kubernetes dans le même apply Terraform ?","Le provider se configure depuis des attributs du cluster inconnus au plan : ça marche parfois, puis casse","Le provider `kubernetes` ou `helm` prend l'endpoint et le certificat du cluster en arguments. Quand ces valeurs viennent d'une ressource du même module, l'ordre d'évaluation provider / ressources n'est pas garanti : premier apply souvent OK, puis erreurs intermittentes au refresh, au replace du cluster ou au destroy (le provider ne joint plus le cluster pour gérer ses ressources). La doc HashiCorp le dit en toutes lettres : ne pas faire.\n\nRemède : deux states, `cluster/` puis `platform/`, le second lisant les outputs du premier.",[175,65],[199],{"title":200,"url":201},"Kubernetes provider — Stacking with managed cluster resources","https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs",{"id":203,"tags":204,"question":205,"answer":206,"details":207,"dependsOn":208,"difficulty":209},"dvo-010",[7,5,177],"Comment organiser l'infra en **couches**, du bas vers le haut ?","1. **Réseau** : VPC, sous-réseaux, DNS (Terraform)\n2. **Cluster** : EKS, nœuds, IAM (Terraform)\n3. **Plateforme** : ingress controller, cert-manager, external-dns, monitoring (Helm, souvent via Terraform ou Argo)\n4. **Applications** : les services métier (Helm / GitOps)","Chaque couche a son propre state ou dépôt, change à son rythme et ne dépend que de celles du dessous. Une appli ne touche jamais au réseau ; le réseau ne connaît aucune appli.",[175,183],6,{"id":211,"tags":212,"question":214,"details":215,"dependsOn":216,"difficulty":209,"quick_answer":218},"dvo-011",[7,5,213,177],"config","Où vit la **configuration** d'une application selon sa nature ?","- Dans l'**image** : le code et ses dépendances, identique partout\n- Dans les **values Helm** par environnement : réplicas, ressources, URL de la base, rendus en ConfigMap et Secret pour le pod\n- Dans **Terraform** : rien d'applicatif, seulement l'infra que l'appli consomme\n\nLe test : « si je change ça, est-ce que je dois rebuilder l'image ? ». Si non, ça ne doit pas être dans l'image.",[158,217],"k8s-020","Hors de l'image si ça change sans rebuild ; dans les values si ça dépend de l'environnement",{"id":220,"tags":221,"question":222,"quick_answer":223,"details":224,"dependsOn":225,"difficulty":63,"sources":226},"dvo-013",[7,5,185],"Qu'est-ce qu'une **release** Helm ?","Une instance installée d'un chart dans un namespace, avec un historique de révisions","`helm list` montre les releases ; `helm history api` leurs révisions ; `helm rollback api 3` revient à une version précédente. Helm stocke cet historique dans des Secrets du namespace.\n\nMême chart installé deux fois = deux releases (`api-blue`, `api-green`).",[75],[227],{"title":228,"url":229},"Helm Docs — helm rollback","https://helm.sh/docs/helm/helm_rollback/",{"id":231,"tags":232,"question":233,"quick_answer":234,"details":235,"dependsOn":236,"difficulty":73},"dvo-014",[7,5,46,185,177],"Comment une valeur créée par Terraform (endpoint RDS, ARN de rôle) arrive-t-elle jusqu'à l'application ?","Terraform l'expose en output, le pipeline ou le state suivant la lit et l'injecte dans les values Helm","Chaîne type : `output \"db_endpoint\"` → `terraform output -raw` dans le pipeline, ou `terraform_remote_state` dans le state `platform/` → `--set db.host=…` ou un fichier de values généré → ConfigMap → variable d'environnement du pod.\n\nL'alternative sans pipeline : Terraform écrit la valeur dans un Secret Manager, et External Secrets la tire dans le cluster.",[237,211],"tfm-016",{"id":239,"tags":240,"question":242,"quick_answer":243,"details":244,"dependsOn":245,"difficulty":42,"sources":246},"dvo-015",[7,5,241],"gitops","Qu'est-ce que le **GitOps** ?","L'état désiré du cluster vit dans Git ; un agent dans le cluster réconcilie en continu avec ce qui est commité","Argo CD ou Flux surveillent un dépôt de manifests ou de charts. Un commit = un déploiement ; un `git revert` = un rollback ; une modification à la main dans le cluster est écrasée si le self-heal est activé (`syncPolicy.automated.selfHeal`, désactivé par défaut).\n\nC'est la boucle de réconciliation de Kubernetes, étendue à Git comme source de vérité.",[33,183],[247],{"title":248,"url":249},"Argo CD Docs — Automated sync, self-heal","https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/",{"id":251,"tags":252,"question":253,"quick_answer":254,"details":255,"dependsOn":256,"difficulty":209},"dvo-016",[7,5,241,98],"Déploiement **push** ou **pull** : quelle différence de sécurité ?","En push, la CI détient les identifiants du cluster ; en pull, l'agent n'a besoin que de lire Git","**Push** : le pipeline fait `kubectl apply` ou `helm upgrade`, donc le runner CI a un accès en écriture au cluster, souvent un kubeconfig admin. Une CI compromise = cluster compromis.\n\n**Pull** (GitOps) : rien n'entre dans le cluster depuis l'extérieur ; Argo tire le dépôt. La CI ne touche qu'au registre d'images et au dépôt de config.",[239,166],{"id":258,"tags":259,"question":260,"quick_answer":261,"details":262,"dependsOn":263,"difficulty":42},"dvo-017",[7,5,145],"Comment se fait la **promotion** d'une version de staging vers prod en GitOps ?","Par un commit qui change le tag d'image dans les values de prod, souvent via une pull request","`values-prod.yaml : image.tag: sha-a1b2c3`. La PR est le point de contrôle : revue, tests de non-régression, approbation. L'agent déploie au merge.\n\nLe même digest d'image a déjà tourné en staging ; seule la cible change.",[239,158],{"id":265,"tags":266,"question":268,"quick_answer":269,"details":270,"dependsOn":271,"difficulty":209,"sources":273},"dvo-018",[7,5,267,177],"reseau","Qui crée le **load balancer AWS** devant un cluster EKS : Terraform ou Kubernetes ?","Kubernetes, via le AWS Load Balancer Controller, à la création d'un Service LoadBalancer ou d'un Ingress","Le AWS Load Balancer Controller (add-on de la couche plateforme, installé par Helm ; sans lui, un Service LoadBalancer ne donne qu'un Classic LB via l'ancien cloud provider) lit les Services et Ingress et appelle l'API AWS pour créer NLB ou ALB. Ces LB n'existent dans aucun state Terraform.\n\nConséquence : un `terraform destroy` du cluster peut échouer parce que des LB et des ENI créés par Kubernetes traînent encore dans le VPC. On supprime les Services avant le cluster.",[272,175],"k8s-017",[274],{"title":275,"url":276},"AWS Docs — AWS Load Balancer Controller (EKS)","https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html",{"id":278,"tags":279,"question":281,"quick_answer":282,"details":283,"dependsOn":284,"difficulty":42,"sources":286},"dvo-019",[7,5,267,280],"plateforme","Que fait **external-dns** ?","Il crée les enregistrements DNS (Route 53…) à partir des Ingress et Services du cluster","Un Ingress avec `host: api.example.com` → external-dns écrit l'enregistrement qui pointe vers le load balancer. Le DNS suit les applications sans que personne ne touche à Route 53.\n\nLa zone DNS, elle, est créée par Terraform ; external-dns n'y écrit que des enregistrements, avec un rôle IAM limité à cette zone.",[265,285],"aws-027",[287],{"title":288,"url":289},"external-dns — Documentation","https://kubernetes-sigs.github.io/external-dns/latest/",{"id":291,"tags":292,"question":293,"quick_answer":294,"details":295,"dependsOn":296,"difficulty":63,"sources":298},"dvo-020",[7,5,98,280],"Que fait **cert-manager** ?","Il obtient et renouvelle automatiquement les certificats TLS (Let's Encrypt ou autre) pour les Ingress","Une annotation sur l'Ingress ou un objet `Certificate` suffit : cert-manager fait le défi ACME, stocke le certificat dans un Secret, et le renouvelle avant expiration.\n\nBrique de la couche plateforme, installée par Helm, une fois par cluster.",[297],"k8s-018",[299],{"title":300,"url":301},"cert-manager — Documentation","https://cert-manager.io/docs/",{"id":303,"tags":304,"question":305,"quick_answer":306,"details":307,"dependsOn":308,"difficulty":209},"dvo-021",[7,5,267,98],"Où se **termine le TLS** dans une stack Kubernetes typique ?","Au load balancer ou à l'ingress controller ; derrière, les pods parlent en HTTP clair sur le réseau interne","Le certificat public est géré au bord (ALB avec ACM, ou ingress controller avec cert-manager). Les services internes ne gèrent pas de certificat.\n\nQuand le chiffrement interne est exigé (conformité), un **service mesh** (Istio, Linkerd) ajoute du mTLS automatique entre pods, sans toucher au code.",[291,265],{"id":310,"tags":311,"question":313,"answer":314,"details":315,"dependsOn":316,"difficulty":209},"dvo-022",[7,5,312,177],"scaling","Quelles sont les **couches d'autoscaling** d'un cluster Kubernetes dans le cloud ?","1. **HPA** : plus de pods quand la charge monte\n2. **Cluster Autoscaler / Karpenter** : plus de nœuds quand des pods restent Pending faute de place\n3. **Auto Scaling Group / API EC2** : les machines réellement créées","Chaque couche réagit à la précédente. Un HPA sans autoscaler de nœuds plafonne à la capacité des machines existantes ; un autoscaler de nœuds sans requests correctes ne sait pas quand ajouter.",[317,318],"k8s-038","aws-026",{"id":320,"tags":321,"question":323,"answer":324,"details":325,"dependsOn":326,"difficulty":73},"dvo-023",[7,5,98,322,177],"secrets","Quel est le **chemin d'un secret** du coffre jusqu'au pod ?","Secrets Manager / Vault → **External Secrets Operator** (dans le cluster, avec un rôle IAM en lecture) → objet **Secret** Kubernetes → variable d'env ou fichier dans le pod","Ce qui ne doit jamais arriver : le secret en clair dans les values Helm commitées, dans un manifest, ou dans une variable de CI copiée à la main.\n\nTerraform peut créer le secret dans le coffre (valeur générée par `random_password`) ; après ça, seul le coffre le détient.",[327,328],"k8s-021","aws-037",{"id":330,"tags":331,"question":332,"quick_answer":333,"details":334,"dependsOn":335,"difficulty":73,"sources":337},"dvo-024",[7,5,98,120,137],"Comment une **CI** (GitHub Actions) s'authentifie-t-elle auprès d'AWS sans clé stockée ?","Par OIDC : le job présente un jeton signé par GitHub, échangé contre les identifiants temporaires d'un rôle","GitHub est déclaré comme fournisseur d'identité OIDC dans IAM ; la trust policy du rôle n'accepte que les jetons dont le `sub` correspond au dépôt et à la branche (`repo:org/app:ref:refs/heads/main`). Le job fait `sts:AssumeRoleWithWebIdentity`.\n\nZéro secret longue durée dans les variables de CI. Même mécanisme avec GitLab, et avec GCP ou Azure côté cloud.",[118,94,336],"aws-043",[338],{"title":339,"url":340},"GitHub Docs — OpenID Connect in AWS","https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws",{"id":342,"tags":343,"question":344,"quick_answer":345,"details":346,"dependsOn":347,"difficulty":209,"sources":349},"dvo-025",[7,5,98,35,96],"Comment un **pod** EKS obtient-il des droits AWS (lire un bucket) sans clé ?","Par IRSA ou Pod Identity : son ServiceAccount est associé à un rôle IAM","Le pod reçoit un jeton de ServiceAccount projeté ; il est échangé contre des identifiants du rôle, par le SDK (`AssumeRoleWithWebIdentity`) en **IRSA**, par l'agent du nœud en **Pod Identity**, le SDK lisant alors `169.254.170.23`. Chaque application a son rôle, limité à ses ressources : le pod `uploader` lit et écrit un bucket, rien d'autre.\n\nSans ça, les pods héritent du rôle du nœud, donc tous les pods ont tous les droits de la machine.",[348,94],"k8s-044",[350,353],{"title":351,"url":352},"AWS Docs — How EKS Pod Identity works","https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html",{"title":354,"url":355},"AWS Docs — IAM roles for service accounts","https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html",{"id":357,"tags":358,"question":360,"quick_answer":361,"details":362,"dependsOn":363,"difficulty":42},"dvo-026",[7,5,359],"deploiement","Qu'est-ce qu'un déploiement **blue/green** ?","Deux environnements complets ; on bascule le trafic de l'ancien (blue) vers le nouveau (green) d'un coup","Le retour arrière est instantané : on rebascule. Coût : deux fois les ressources pendant la bascule.\n\nSous Kubernetes : deux Deployments et un Service dont on change le selector, ou deux releases Helm et un Ingress.",[364],"k8s-011",{"id":366,"tags":367,"question":368,"quick_answer":369,"details":370,"dependsOn":371,"difficulty":42},"dvo-027",[7,5,359],"Qu'est-ce qu'un déploiement **canary** ?","La nouvelle version reçoit une petite part du trafic (1 à 10 %) ; on mesure, puis on augmente ou on annule","Les erreurs touchent peu d'utilisateurs, et une mesure réelle (taux d'erreur, latence) décide de la suite. Nécessite un routage pondéré (ingress, service mesh, ALB) et des métriques comparables entre versions.\n\nArgo Rollouts ou Flagger automatisent la progression.",[357],{"id":373,"tags":374,"question":375,"quick_answer":376,"details":377,"dependsOn":378,"difficulty":209},"dvo-028",[7,5,359,193],"Pourquoi le **rollback** d'une application ne suffit-il pas si elle a migré sa base de données ?","L'ancienne version ne sait pas lire le nouveau schéma : la migration doit rester compatible avec N-1","Un rollback d'image est trivial (`rollout undo`, `helm rollback`, revert Git). Un rollback de schéma, non. D'où la règle **expand / contract** : ajouter une colonne (compatible avec l'ancien code), déployer, puis seulement plus tard retirer l'ancienne.\n\nLa migration et le code se déploient en deux temps, jamais en un.",[379],"k8s-039",{"id":381,"tags":382,"question":383,"quick_answer":384,"details":385,"dependsOn":386,"difficulty":53},"dvo-029",[7,5,359],"Qu'est-ce qu'un **feature flag** ?","Un interrupteur de configuration qui active une fonctionnalité sans redéployer","Le code est en prod mais éteint. On l'allume pour 5 % des utilisateurs, pour une équipe, pour tout le monde. Désactiver = un clic, pas un rollback.\n\nIl découple **déployer** (mettre le code en prod) et **livrer** (le rendre visible). Outils : LaunchDarkly, Unleash, OpenFeature.",[151],{"id":388,"tags":389,"question":391,"quick_answer":392,"details":393,"dependsOn":394,"difficulty":63,"sources":395},"dvo-030",[7,5,390],"git","Qu'est-ce que le **trunk-based development** ?","Tout le monde commite sur une branche principale unique, via des branches qui vivent des heures","Pas de branche `develop`, pas de branche de release qui vit un mois. Les intégrations fréquentes évitent les merges douloureux ; les fonctionnalités incomplètes se cachent derrière des feature flags.\n\nC'est une des pratiques que les études DORA associent à la performance de livraison, avec la CI, les petits lots et le déploiement continu.",[135,381],[396],{"title":397,"url":398},"DORA — Trunk-based development","https://dora.dev/capabilities/trunk-based-development/",{"id":400,"tags":401,"question":403,"quick_answer":404,"details":405,"dependsOn":406,"difficulty":63},"dvo-031",[7,5,402],"observabilite","Qu'est-ce que l'**observabilité** ?","La capacité à comprendre l'état interne d'un système à partir de ce qu'il émet : métriques, logs, traces","**Métriques** : des nombres dans le temps (Prometheus). **Logs** : des événements (Loki, Elasticsearch). **Traces** : le parcours d'une requête à travers les services (Jaeger, Tempo).\n\nLe monitoring dit « ça va mal » ; l'observabilité permet de répondre à « pourquoi » sans redéployer avec plus de logs.",[129],{"id":408,"tags":409,"question":410,"quick_answer":411,"details":412,"dependsOn":413,"difficulty":63,"sources":414},"dvo-032",[7,5,402],"Qu'est-ce qu'**OpenTelemetry** ?","Le standard ouvert (CNCF) pour instrumenter une application : métriques, logs et traces","Le code émet via le SDK OTel, un **collector** reçoit et exporte vers le backend choisi (Prometheus, Grafana, Datadog…). On change de backend sans réinstrumenter.\n\nLes traces distribuées reposent sur la propagation d'un identifiant dans les en-têtes HTTP entre services (`traceparent`, standard W3C Trace Context, propagateur par défaut d'OTel).",[400],[415],{"title":416,"url":417},"OpenTelemetry Docs — Context propagation","https://opentelemetry.io/docs/concepts/context-propagation/",{"id":419,"tags":420,"question":422,"quick_answer":423,"details":424,"dependsOn":425,"difficulty":42,"sources":426},"dvo-033",[7,5,421],"sre","Qu'est-ce qu'un **SLO** ?","Un objectif chiffré de fiabilité sur une métrique vue par l'utilisateur, sur une période donnée","Exemple : 99,9 % des requêtes réussies en moins de 300 ms sur 30 jours glissants. Le **SLI** est la mesure (part des requêtes réussies), le **SLO** l'objectif, le **SLA** le contrat avec pénalités. Un SLO se fixe en dessous de 100 % : la fiabilité parfaite coûte infiniment cher et personne ne la remarque.\n\nVient du SRE de Google.",[400],[427],{"title":428,"url":429},"Google SRE Book — Embracing risk","https://sre.google/sre-book/embracing-risk/",{"id":431,"tags":432,"question":433,"quick_answer":434,"details":435,"dependsOn":436,"difficulty":42,"sources":437},"dvo-034",[7,5,421],"Qu'est-ce qu'un **error budget** ?","La marge d'indisponibilité que le SLO autorise : avec 99,9 % sur 30 jours, 43 minutes de panne","Tant que le budget n'est pas consommé, on déploie et on prend des risques. Budget épuisé : on gèle les mises en prod et on travaille la fiabilité.\n\nC'est la règle qui réconcilie dev (vitesse) et ops (stabilité) avec un chiffre plutôt qu'un rapport de force.",[419],[438],{"title":428,"url":429},{"id":440,"tags":441,"question":443,"quick_answer":444,"details":445,"dependsOn":446,"difficulty":53,"sources":447},"dvo-035",[7,5,442],"mesure","Que mesure le **lead time for changes** (DORA) ?","Le temps entre un commit et sa mise en production","Une des métriques DORA, quatre à l'origine (avec la fréquence de déploiement, le taux d'échec des changements et le temps de rétablissement d'un déploiement raté), cinq depuis le rapport 2024 (taux de rework). Les équipes « elite » du rapport comptent en heures ; les autres en semaines ou mois.\n\nUn lead time long signale des files d'attente : revue, QA manuelle, fenêtres de déploiement.",[151],[448],{"title":449,"url":450},"DORA — History of DORA metrics","https://dora.dev/guides/dora-metrics/history/",{"id":452,"tags":453,"question":454,"quick_answer":455,"details":456,"dependsOn":457,"difficulty":53,"sources":458},"dvo-036",[7,5,442],"Que mesure le **change failure rate** (DORA) ?","La part des déploiements en production qui provoquent un incident ou un rollback","Contre-poids de la fréquence de déploiement : déployer dix fois par jour ne vaut rien si un déploiement sur trois casse. Les équipes performantes tiennent les deux à la fois, parce que des lots plus petits cassent moins et se réparent plus vite.",[440],[459],{"title":449,"url":450},{"id":461,"tags":462,"question":463,"quick_answer":464,"details":465,"dependsOn":466,"difficulty":42},"dvo-037",[7,5,98,137],"Qu'est-ce que le **shift-left** en sécurité ?","Déplacer les contrôles de sécurité dans la CI, au plus près du commit, plutôt qu'en audit final","Scan de vulnérabilités de l'image (Trivy, Grype), scan de l'IaC (Checkov, Trivy), détection de secrets commités (gitleaks), SBOM générée au build. Le pipeline échoue sur une CVE critique.\n\nUne faille trouvée au commit coûte une correction ; trouvée en prod, un incident.",[135],{"id":468,"tags":469,"question":470,"quick_answer":471,"details":472,"dependsOn":473,"difficulty":42},"dvo-038",[7,5,137],"Qu'est-ce qu'un **runner** de CI ?","La machine (ou le conteneur) qui exécute les jobs du pipeline","Hébergé par la plateforme (GitHub-hosted) ou par soi (self-hosted, souvent dans Kubernetes). Un runner **éphémère** est détruit après chaque job : pas de résidu entre deux builds, pas de secret qui traîne.\n\nConstruire une image Docker dans un runner lui-même conteneurisé pose la question du démon : Docker-in-Docker, ou BuildKit en mode rootless, sans démon Docker (Kaniko, l'autre option historique, est archivé depuis 2025).",[135,474],"dkr-036",{"id":476,"tags":477,"question":478,"quick_answer":479,"details":480,"dependsOn":481,"difficulty":63,"sources":483},"dvo-039",[7,5,213],"Pourquoi la config d'une appli conteneurisée passe-t-elle par des **variables d'environnement** ?","C'est le seul canal que tous les environnements fournissent sans rebuild : règle III des 12 facteurs","Compose, Kubernetes (ConfigMap, Secret), Lambda, ECS : tous injectent des variables d'env. Un fichier de config dans l'image impose un rebuild ; un fichier monté impose un volume.\n\nLes **12 factors** (Heroku, 2011) restent la référence : config en env, processus sans état, logs sur stdout, dépendances déclarées.",[211,482],"dkr-045",[484],{"title":485,"url":486},"The Twelve-Factor App — III. Config","https://12factor.net/config",{"id":488,"tags":489,"question":490,"quick_answer":491,"details":492,"dependsOn":493,"difficulty":53},"dvo-040",[7,5,36],"Que veut dire « **cattle, not pets** » ?","Les serveurs sont interchangeables et remplaçables, pas soignés un par un","Un « pet » a un nom, un historique de modifications à la main, et sa mort est un incident. Du « cattle » se remplace par une machine identique sortie du même template.\n\nC'est la justification de l'infra immuable, des images, de Terraform et des Deployments : rien ne se répare sur place, tout se recrée.",[129],{"id":495,"tags":496,"question":497,"quick_answer":498,"details":499,"dependsOn":500,"difficulty":42},"dvo-041",[7,5,47],"Qu'est-ce que l'**infrastructure immuable** ?","On ne modifie jamais un serveur en place : on construit une nouvelle image et on remplace","Mise à jour de l'OS ? Nouvelle AMI (Packer), nouveau launch template, rotation des instances par l'ASG. Nouvelle version de l'appli ? Nouvelle image Docker, nouveaux pods.\n\nPlus de dérive entre machines, plus de « ça marche sur le serveur 3 mais pas le 4 ». Le prix : une chaîne de build d'images à entretenir.",[488,501],"tfm-027",{"id":503,"tags":504,"question":505,"quick_answer":506,"details":507,"dependsOn":508,"difficulty":42},"dvo-042",[7,5,47],"Que reste-t-il à **Ansible** dans une stack Terraform + conteneurs ?","Presque rien : Terraform provisionne, image et manifests configurent ; Ansible reste aux serveurs mutables","Terraform : « il existe 3 VM, un LB, une base ». Ansible : « sur ces VM, nginx est installé avec cette config ». Les deux se complètent sur de l'infra mutable classique.\n\nAvec des conteneurs, la configuration est dans l'image (Dockerfile) et les manifests Kubernetes : il n'y a plus de serveur à configurer, sauf les nœuds eux-mêmes, et une AMI prête (Packer) ou un OS minimal (Bottlerocket) règle ça.",[44,509],"tfm-034",{"id":511,"tags":512,"question":514,"quick_answer":515,"details":516,"dependsOn":517,"difficulty":63},"dvo-043",[7,5,513],"environnements","Pourquoi utiliser **Compose en local** et **Kubernetes en prod** avec la même image ?","La même image garantit le même comportement ; seul l'orchestrateur change, adapté à l'échelle","Compose suffit à lancer l'API, la base et le cache sur un portable. Kubernetes apporte ce dont le local n'a pas besoin : haute dispo, scaling, rolling update.\n\nLe contrat : l'application lit sa config en variables d'env et ne suppose rien sur son orchestrateur. Pour tester les manifests Kubernetes en local : kind, k3d, minikube.",[518,476],"dkr-030",{"id":520,"tags":521,"question":522,"quick_answer":523,"details":524,"dependsOn":525,"difficulty":209},"dvo-044",[7,5,513,177],"Un **namespace par environnement** ou un **cluster par environnement** ?","Namespaces pour les environnements de même criticité ; un cluster séparé pour la prod","Les namespaces isolent les noms, les quotas et le RBAC, pas le control plane ni les nœuds : une mise à jour de version de Kubernetes ou une saturation touche tout le monde.\n\nCompromis courant : un cluster `nonprod` avec les namespaces `dev`, `staging`, `review-*`, et un cluster `prod` à part, dans un compte AWS séparé.",[526,527],"k8s-019","aws-044",{"id":529,"tags":530,"question":532,"details":533,"dependsOn":534,"difficulty":42,"quick_answer":536,"sources":537},"dvo-045",[7,5,531],"versions","Pourquoi référencer une action de CI par **SHA** plutôt que par tag (`@v4`) ?","`uses: actions/checkout@v4` suit un tag mobile ; `uses: actions/checkout@\u003Csha>` fige le code exécuté avec les secrets du job. La compromission de `tj-actions/changed-files` (mars 2025) a réécrit les tags pour exfiltrer des secrets de CI.\n\nMême logique partout : image par digest, chart par `version`, providers et modules par lockfile. Un bot (Renovate, Dependabot) propose les mises à jour en PR.",[84,535],"tfm-036","Un tag peut être déplacé par son auteur, ou par un attaquant : le SHA, non",[538],{"title":539,"url":540},"GitHub Docs — Secure use reference (pin actions to a SHA)","https://docs.github.com/en/actions/reference/security/secure-use",{"id":542,"tags":543,"question":544,"quick_answer":545,"details":546,"dependsOn":547,"difficulty":42,"sources":549},"dvo-046",[7,5,241,193],"Quelqu'un modifie un Deployment à la main avec kubectl edit : que se passe-t-il en GitOps ?","L'agent détecte l'écart avec Git et remet le manifest en place (self-heal), le changement manuel disparaît","C'est le drift de Terraform appliqué au cluster, avec la correction automatique en plus. Argo CD affiche `OutOfSync` puis resynchronise si `selfHeal` est activé.\n\nLa bonne façon de faire une modification : une PR. Le hotfix à la main en prod n'existe plus, et c'est le but.",[239,548],"tfm-014",[550],{"title":248,"url":249},{"id":552,"tags":553,"question":555,"quick_answer":556,"details":557,"dependsOn":558,"difficulty":73,"sources":560},"dvo-047",[7,5,554,177],"sante","Comment une **readiness probe** se propage-t-elle jusqu'au load balancer cloud ?","Pod prêt → endpoint du Service → cible saine de l'ingress ou du LB ; pod pas prêt → retiré de toute la chaîne","Le kubelet exécute la probe ; le contrôleur EndpointSlice ajoute ou retire l'IP du pod ; en `target-type: ip`, le AWS LB Controller met à jour les cibles du LB (en mode `instance`, les cibles sont les nœuds et c'est kube-proxy qui filtre sur les endpoints prêts). Le LB cloud a souvent son propre health check en plus, sur le même endpoint.\n\nUn déploiement sans coupure dépend de toute cette chaîne : une probe absente = du trafic envoyé à un pod qui démarre encore.",[559,265],"k8s-027",[561],{"title":275,"url":276},{"id":563,"tags":564,"question":566,"quick_answer":567,"details":568,"dependsOn":569,"difficulty":53},"dvo-048",[7,5,565],"culture","Qu'est-ce qu'un **postmortem sans blâme** ?","L'analyse d'un incident centrée sur les causes systémiques et les actions, pas sur la faute d'une personne","Chronologie, impact, causes, ce qui a aidé, ce qui a gêné, actions avec responsable et date. La question n'est pas « qui a tapé la commande » mais « pourquoi le système laissait taper cette commande ».\n\nSans ça, les gens cachent les incidents, et on perd l'information qui évite le suivant.",[129],{"id":571,"tags":572,"question":573,"quick_answer":574,"details":575,"dependsOn":576,"difficulty":73,"sources":578},"dvo-049",[7,5,98,35,96,177],"Comment une identité IAM (humain, CI) obtient-elle des **droits dans l'API Kubernetes** d'un cluster EKS ?","Par une access entry EKS, créée par Terraform, qui associe le rôle IAM à des droits RBAC Kubernetes","IAM authentifie (`aws eks get-token` signe une requête STS), Kubernetes autorise via RBAC. Le pont : les **access entries** (2023, remplacent le ConfigMap `aws-auth`) mappent un ARN IAM vers un groupe RBAC ou une policy managée (`AmazonEKSClusterAdminPolicy`).\n\nC'est Terraform qui les crée, dans le state `cluster/` : le rôle de la CI reçoit `edit` sur ses namespaces, les admins reçoivent cluster-admin.",[330,577],"k8s-043",[579],{"title":580,"url":581},"AWS Docs — EKS access entries","https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html",{"id":583,"tags":584,"question":585,"quick_answer":586,"details":587,"dependsOn":588,"difficulty":209},"dvo-050",[7,5,107,96,177],"Qui a le droit de **tirer l'image** depuis ECR quand un pod démarre sur EKS ?","Le nœud, via son rôle IAM (lecture ECR) ; pour un registre tiers, un imagePullSecret dans le namespace","Le kubelet tire l'image avec les identifiants du nœud : le rôle du node group porte `AmazonEC2ContainerRegistryReadOnly`. Rien à configurer côté pod pour ECR du même compte.\n\nPour GHCR ou Docker Hub privé : un Secret de type `kubernetes.io/dockerconfigjson` référencé par `imagePullSecrets`, souvent injecté par External Secrets. Un `ImagePullBackOff` sur une image privée, c'est presque toujours ça.",[166,589],"k8s-032",{"id":591,"tags":592,"question":593,"quick_answer":594,"details":595,"dependsOn":596,"difficulty":209},"dvo-051",[7,5,241,137,177],"En GitOps, **qui écrit le nouveau tag d'image** dans le dépôt de config après un build ?","La CI commite dans le dépôt de config, ou un outil du cluster (Image Updater, Flux) qui surveille le registre","**Par la CI** : après le push, le job modifie `values-staging.yaml` et commite (avec un token limité à ce dépôt). Simple, explicite, visible dans l'historique.\n\n**Par le cluster** : l'outil détecte la nouvelle image dans le registre selon une règle (dernier tag `sha-*`, semver), écrit le commit lui-même. Moins de couplage avec la CI, mais une règle de sélection à bien borner. Dans les deux cas, Git reste la source de vérité : jamais de déploiement sans commit.",[239,258],{"id":598,"tags":599,"question":600,"quick_answer":601,"details":602,"dependsOn":603,"difficulty":209,"sources":605},"dvo-052",[7,5,359,177],"Qui exécute la **migration de schéma** et à quel moment du rollout ?","Un Job lancé avant le rollout par un hook (Helm pre-upgrade, Argo PreSync), jamais l'appli au démarrage","Un Job dédié tourne une fois, avec la nouvelle image, et le rollout n'avance que s'il réussit. Dans Helm : annotation `helm.sh/hook: pre-upgrade` ; dans Argo CD : `argocd.argoproj.io/hook: PreSync`.\n\nLancer la migration au démarrage de chaque pod, c'est N réplicas qui tentent la même migration en même temps. Et la règle expand/contract reste : le schéma migré doit encore servir l'ancienne version pendant le rollout.",[373,604],"k8s-037",[606,609],{"title":607,"url":608},"Helm Docs — Chart hooks","https://helm.sh/docs/topics/charts_hooks/",{"title":610,"url":611},"Argo CD Docs — Resource hooks","https://argo-cd.readthedocs.io/en/stable/user-guide/resource_hooks/","ok",null,1792059302721]