L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.
Le capstone vérifie que vous savez lire seul une architecture complète que
vous n'avez jamais vue : reconnaître chaque famille, suivre les flux, classer
l'état, repérer les points faibles, prédire les pannes et juger
l'exploitation. C'est la synthèse des six modules, sur un système plus riche
que les checkpoints : une plateforme de livraison de repas. Il ne demande
aucune commande ni aucun produit par cœur : chaque réponse se déduit du
diagramme et de la grille de lecture de la formation, et une erreur renvoie à
la leçon qui traite le point manqué.
Une architecture de cette taille ne tient pas lisiblement sur un seul
schéma : elle se lit en deux vues, celle des flux applicatifs et celle de la
plateforme et de l'exploitation. C'est la pratique courante des documents
d'architecture, qui découpent le système par point de vue plutôt que de tout
superposer. Les deux vues décrivent le même système : l'API de la première
vue fait partie des charges applicatives de la seconde, et la base PostgreSQL
apparaît dans les deux.
Un client commande depuis son téléphone : la requête traverse un CDN avec
pare-feu applicatif, un répartiteur et un ingress, puis une API en trois
copies qui lit et écrit ses données et publie deux messages. L'API garde les
commandes dans PostgreSQL, répliqué et indexé dans OpenSearch pour la
recherche de restaurants ; les sessions et les menus en cache vivent dans
Redis, les photos dans un stockage objet. Elle dépose dans RabbitMQ un
paiement à faire, que des workers transmettent au prestataire, et publie dans
Kafka l'événement « commande validée », lu par un service de notifications.
Un ordonnanceur purge chaque nuit les commandes abandonnées.
Première vue du capstone : les flux applicatifs d'une plateforme de livraison de repas.Source · SVG
Les charges applicatives tournent dans un cluster Kubernetes en région A,
avec son DNS interne, et dépendent de services partagés : Keycloak pour les
jetons, OpenBao pour les secrets, déverrouillé par le KMS du cloud, et Harbor
pour les images. Hors du cluster, une zone d'exploitation porte le bastion
avec second facteur, le SIEM et la supervision qui reçoit la télémétrie. La
base est copiée chaque nuit, avec son journal en continu, vers une
sauvegarde verrouillée en région B.
Vue plateforme et exploitation : dans un cluster Kubernetes en région A, l'API, les workers et les notifications résolvent les noms par un DNS interne ; ils dépendent en pointillé de la clé publique de Keycloak, des secrets d'OpenBao, déverrouillé par le KMS du cloud, et des images de Harbor, regroupés en services partagés. Le cluster envoie sa télémétrie à la supervision et ses journaux de sécurité au SIEM, dans une zone d'exploitation hors cluster où l'administrateur entre par un bastion avec second facteur, dont les sessions vont aussi au SIEM. Les charges écrivent en SQL dans PostgreSQL, copié chaque nuit avec son journal en continu vers une sauvegarde verrouillée en région B.AdministrateurExploitation, hors clusterCluster Kubernetes, région AServices partagésPostgreSQLprimaireKMSdu cloudRégion BBastionMFASIEMSupervisionalertesAPI, workerset notificationsDNSinterneKeycloakOpenBaosecretsHarborregistreSauvegardeverrouilléerésolutionSSH, MFAadministrationclé publiquesecretsdéverrouillageimagestélémétriejournaux de sécuritésessionsSQLchaque nuitjournal en continu
Seconde vue du capstone : la plateforme d'exécution, les services partagés et l'exploitation.Source · SVG
Pour chaque question, appliquez la méthode de la formation dans l'ordre :
reconnaître la brique, la situer sur le chemin d'une requête ou hors de lui,
classer son état, puis raisonner sur sa panne. Le trait rouge dit ce que
le client attend ; les flèches pleines vers une file ou un journal marquent
l'asynchrone ; les pointillés, les dépendances transverses, dont la panne se
révèle souvent au redémarrage. Les zones marquent les domaines de panne et
les frontières de confiance.
Les questions sont tirées au hasard dans une banque qui couvre les six
modules : reconnaître, classer, suivre les flux, analyser les dépendances, les
pannes et l'exploitation. Le seuil de réussite est de 70 %, et la
durée indicative de 25 minutes : prenez le temps de relire les deux vues avant
de répondre.
Réussir le capstone, c'est savoir lire une architecture ; la concevoir, et
installer chacune de ses briques, sont deux capacités qui s'appuient sur
celle-ci. Chaque leçon a cité les guides et les formations spécialisées
qui prennent le relais : PostgreSQL, Kubernetes, l'observabilité, la gestion
des secrets ou les accès d'administration. Le meilleur exercice reste celui
de votre propre système : dessinez-le, appliquez-lui la grille, et cherchez
ce que votre schéma ne montre pas.
Une architecture complète se lit par vues : les flux, puis la
plateforme et l'exploitation.
Chaque brique se lit par sa famille, sa place sur le chemin et son état.
Ce que le client attend casse tout de suite ; ce qui sert au démarrage
casse au redémarrage.
La sauvegarde vise les sources de vérité, avec ce qui les déverrouille.
Chaque brique ajoutée échange un problème contre d'autres.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
15 questions
25 min.
70% requis
Informations
Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
⏱️--:--
0 / 15
Vérification
(0/0)
--:--
0%
0Correctes
0À revoir
0:00Temps
-Niveau
Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Nouveau quiz complet avec des questions aléatoires