CompTIA Cloud+ — Questions d'entraînement et examen blanc

L'idempotence garantit qu'exécuter plusieurs fois la même requête d'API produit des résultats identiques, sans effets de bord supplémentaires. D'après la RFC 7231 S4.2.2, les méthodes HTTP GET, PUT et DELETE sont idempotentes par nature, tandis que POST demande une implémentation explicite via des idempotency keys. Quand un client subit un timeout, il ne peut pas savoir si le serveur a traité la requête. Sans idempotence, les tentatives de renvoi risquent de dupliquer des opérations (par exemple un double débit). En pratique, l'implémentation consiste à ce que le client envoie une idempotency key unique ; le serveur stocke le résultat et le renvoie pour les requêtes dupliquées. Pourquoi pas les autres ? La cohérence éventuelle décrit un modèle de réplication de données, pas la sûreté des requêtes. Le circuit breaking évite les défaillances en cascade en interrompant les appels vers les services défaillants. Le throttling des requêtes limite le débit d'appels mais ne garantit pas des renvois sûrs. Réf. : RFC 7231 S4.2.2 ; documentation Stripe sur l'idempotence de l'API ; CompTIA Cloud+ CV0-004 Obj 3.3.

L’un des plus grands défis d’une migration vers le cloud consiste à gérer les niveaux applicatifs avec état. Lorsque les données de session résident dans la mémoire du serveur, les utilisateurs doivent toujours atteindre le même serveur (affinité de session), ce qui limite la mise à l’échelle et met en danger la session de chaque utilisateur si ce serveur tombe en panne. La solution cloud-native consiste à externaliser l’état dans un stockage partagé et distribué comme Redis ou Memcached. Dès que les sessions résident dans un cache externe, les serveurs d’applications deviennent sans état : n’importe quel serveur peut traiter n’importe quelle requête, et on peut ajouter ou retirer des serveurs librement. Les sticky sessions (affinité de session) sur le répartiteur de charge sont un contournement qui attache les utilisateurs à des serveurs précis. Elles permettent une certaine montée en charge horizontale, mais elles peuvent déséquilibrer la répartition de la charge, compliquer les déploiements et signifient qu’une panne de serveur fait perdre les sessions de tous les utilisateurs qui y sont attachés. Augmenter la mémoire relève de la mise à l’échelle verticale, ce n’est pas une voie vers l’évolutivité horizontale. Passer à WebSocket concerne le type de connexion, pas la gestion de l’état. Conseil pour l’examen : une migration « avec état vers sans état » signifie généralement externaliser l’état dans un cache distribué.

Dépanner DHCP, c’est suivre l’échange DISCOVER, OFFER, REQUEST, ACK et chercher où il s’arrête. L’absence totale d’OFFER signifie soit que le DISCOVER n’a jamais atteint le serveur, soit que le serveur a choisi de ne pas répondre. Le premier cas vient de la configuration du relais, du routage ou d’un filtrage pare-feu de UDP 67/68. Le second vient de causes côté serveur, comme l’absence d’étendue pour le sous-réseau, un pool épuisé ou une politique administrative. Un OFFER suivi d’un DHCPDECLINE du client indique un conflit d’adresses, généralement détecté par ARP. Un DHCPNAK indique qu’un client demande une adresse incorrecte pour son réseau actuel ou dont le bail a expiré, généralement après un passage d’un sous-réseau à un autre. L’étape à laquelle l’échange s’interrompt permet de localiser la panne.