Vérification des connaissances - Intégration de services
Testez votre compréhension des concepts clés du Module 4. Sélectionnez la meilleure réponse pour chaque question, puis soumettez pour voir vos résultats. Vous devez obtenir un score d'au moins 60 % pour réussir.
Un développeur relie le TaskBoard API à son IONOS PostgreSQL Cluster. Il construit la chaîne de connexion à partir de la sortie Terraform et définit explicitement sslmode=disable car l'application s'exécute à l'intérieur du même centre de données virtuel. Les connexions négocient toujours TLS, quel que soit ce paramètre. Qu'est-ce qui explique ce comportement ?
IONOS PostgreSQL utilise un mode SSL de prefer que le client ne peut pas désactiver, donc le chiffrement en transit est imposé, quel que soit la demande sslmode=disable d'une application. Les distracteurs du pilote et de la sortie Terraform sont incorrects car le comportement est une politique serveur du Cluster géré, et non une bibliothèque cliente ou un artefact d'outillage.
Le frontend du navigateur TaskBoard doit permettre aux utilisateurs de télécharger de grands fichiers joints directement sur IONOS Object Storage sans que le serveur API fasse de proxy pour les octets. Quelle approche boto3 implémente correctement cela contre IONOS Object Storage ?
IONOS Object Storage expose l'API S3 d'AWS API et s'authentifie avec une clé d'accès et une clé secrète, donc boto3 doit recevoir un endpoint_url explicite ainsi que ces informations d'identification, et les URL pré-signées permettent au navigateur de télécharger sans que le serveur API touche les octets. Les jetons Bearer et les rôles IAM n'authentifient pas Object Storage, et NFS est un produit de stockage distinct et sans rapport.
Un développeur ajoute un Kafka consommateur au worker TaskBoard afin qu'il puisse réagir aux événements de modification de tâche. La connexion à partir du code d'application avec uniquement un nom d'utilisateur et un mot de passe échoue à l'authentification contre le plan de données IONOS Kafka. Qu'est-ce que la configuration correcte du client nécessite ?
Le plan de données IONOS Kafka authentifie les clients avec une authentification mutuelle TLS, donc le consommateur doit présenter un certificat client sur une connexion chiffrée. Le jeton Bearer s'applique uniquement au API de gestion, le texte brut n'est jamais accepté, et les informations d'identification de clé d'accès et de clé secrète appartiennent à Object Storage, et non à Kafka.
TaskBoard utilise IONOS In-Memory DB (Redis) comme cache de session et de lecture pour mettre à l'échelle les lectures, puisque le PostgreSQL Cluster n'a pas de réplicas de lecture pour décharger ce trafic. Sous une charge soutenue, le cache se remplit jusqu'à sa limite de mémoire. Avec la configuration par défaut, qu'est-ce qui arrive aux nouvelles écritures une fois que la mémoire est pleine ?
IONOS In-Memory DB utilise par défaut la politique d'éviction allkeys-lru, donc lorsque la mémoire est épuisée, elle supprime les clés les moins récemment utilisées plutôt que de refuser les écritures, ce qui est le comportement attendu pour un cache de lecture. Le renvoi d'erreurs pour chaque écriture est le comportement d'une politique noeviction, et le Cluster ne met pas automatiquement à l'échelle les nœuds pour absorber la pression du cache.
Le TaskBoard API appelle IONOS AI Model Hub pour résumer les descriptions de tâches. Lors d'un pic de trafic, les requêtes d'inférence commencent à renvoyer des réponses HTTP 429. Quel changement gère correctement cela dans le code de production ?
AI Model Hub renvoie HTTP 429 Trop de requêtes lorsqu'une limite de taux est dépassée, donc le code de production doit reculer de manière exponentielle et réduire Volume en mettant en cache les résultats d'inférence, par exemple dans In-Memory DB. Les boucles de réessai serrées aggravent le contrôle du débit, le API s'authentifie avec un jeton Bearer plutôt qu'avec une authentification de base, et le service est un point de terminaison IONOS, et non AWS Bedrock.