Cloud Digital Leader — Questions d'entraînement et examen blanc

Cloud Trace est le service de traçage distribué de Google Cloud, qui suit les requêtes à travers les microservices et enregistre la latence à chaque étape (docs.cloud.google.com/trace/docs/overview). Il génère des visualisations en cascade montrant le temps que chaque service met à traiter une requête, ce qui rend les goulots d'étranglement faciles à repérer. Cloud Trace s'intègre à GKE, Cloud Run et App Engine, et prend en charge l'instrumentation OpenTelemetry. Pourquoi pas Cloud Monitoring ? Il suit des métriques comme l'utilisation du CPU ou de la mémoire, mais ne trace pas le parcours de chaque requête entre les services. Pourquoi pas Error Reporting ? Il identifie les erreurs et les exceptions applicatives, pas les goulots d'étranglement de latence. Pourquoi pas Cloud Logging ? Il collecte des entrées de journal, mais n'offre pas de traçage de latence au niveau des requêtes au-delà des frontières entre services. Astuce d'examen : identifier quel service précis provoque la latence dans une chaîne de requêtes distribuée = Cloud Trace.

AutoML sur Agent Platform automatise la sélection des algorithmes, le réglage des hyperparamètres et l'entraînement du modèle, sans demander d'expertise en ML ni de code (docs.cloud.google.com/vertex-ai/docs/start/training-methods). Pour des équipes peu expérimentées en ML et des jeux de données plus petits, AutoML produit plus vite des modèles de grande qualité, car il supprime le besoin d'écrire du code d'entraînement et de développer des pipelines de données. La comparaison officielle des méthodes d'entraînement le confirme : AutoML ne demande aucune expertise en data science et se passe de code. Pourquoi pas l'entraînement personnalisé ? Il exige une expertise en ML importante pour développer les applications d'entraînement—il ne produit pas toujours de meilleurs modèles quelle que soit l'expertise. Pourquoi pas uniquement des API pré-entraînées ? Les API pré-entraînées traitent des tâches courantes, mais ne peuvent pas s'entraîner sur ton propre jeu de données. Pourquoi pas « AutoML s'adresse uniquement aux grandes entreprises » ? AutoML est accessible à tous les utilisateurs, quelle que soit la taille de l'organisation. Astuce d'examen : peu d'expertise en ML + besoin de résultats rapides + petit jeu de données = AutoML.

Google Cloud chiffre les données en transit à la fois sur l'internet public et à l'intérieur de son réseau interne (docs.cloud.google.com/docs/security/encryption-in-transit). Le trafic externe est chiffré en TLS/QUIC via les Google Front Ends (GFE), tandis que le trafic interne entre services s'appuie sur ALTS (Application Layer Transport Security) pour l'authentification mutuelle et le chiffrement. Google utilise aussi le protocole de sécurité PSP pour le chiffrement au niveau réseau, avec déchargement sur SmartNIC. C'est automatique et cela ne demande aucune configuration côté client pour le trafic standard. Pourquoi pas uniquement avec le Premium Tier ? Le chiffrement en transit s'applique quel que soit le niveau de réseau. Pourquoi pas uniquement sur l'internet public ? La documentation indique explicitement que Google chiffre les données à l'intérieur de son réseau interne avec ALTS. Pourquoi pas une configuration TLS manuelle ? Google gère automatiquement le chiffrement pour ses services—aucun certificat géré par le client n'est nécessaire. Astuce d'examen : TLS = externe ; ALTS = interne. Les deux sont automatiques.

Le scaling à zéro est la propriété qui distingue le plus nettement une plateforme d’applications serverless d’un cluster que tu maintiens en fonctionnement. Cloud Run ajoute des instances en fonction des requêtes entrantes et les supprime quand la demande baisse ; par défaut, une révision qui ne reçoit aucun trafic est ramenée à zéro instance. Cela ne se produit pas dès la fin de la dernière requête : pour limiter les démarrages à froid, Cloud Run peut garder une instance inactive jusqu’à 15 minutes après qu’elle a fini de traiter des requêtes, et une instance inactive peut conserver des ressources comme des connexions ouvertes à une base de données. Pour les charges de travail qui connaissent de longues périodes d’inactivité, comme les outils internes ou les endpoints saisonniers, cela signifie qu’aucune instance ne reste active pendant la nuit. La contrepartie, c’est le démarrage à froid : la première requête après le passage de la révision à zéro attend pendant la création d’une nouvelle instance, ce qui peut ajouter une latence perceptible. Les équipes qui ne peuvent pas accepter cette latence configurent un nombre minimal d’instances pour en garder une à chaud, en acceptant délibérément un certain coût d’inactivité en échange d’un temps de réponse prévisible.