Vérification des connaissances - Intégration de services
Évaluez 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 au moins 60 % pour réussir.
Un développeur configure l'API TaskBoard pour qu'elle se connecte à son cluster IONOS CLOUD PostgreSQL. Il construit la chaîne de connexion à partir de la sortie Terraform et définit explicitement sslmode=disable, car l'application s'exécute dans le même VDC. Les connexions négocient néanmoins TLS, indépendamment de ce paramètre. Qu'est-ce qui explique ce comportement ?
IONOS CLOUD PostgreSQL utilise un mode SSL prefer que le client ne peut pas désactiver, de sorte que le chiffrement en transit est imposé, indépendamment de la demande sslmode=disable de l'application. Les options concernant le pilote et la sortie Terraform sont incorrectes, car ce comportement relève d'une politique côté serveur du cluster géré, et non d'un artefact lié à une bibliothèque client ou à un outil.
L'interface front-end du navigateur de TaskBoard doit permettre aux utilisateurs de téléverser des pièces jointes de grande taille directement vers IONOS CLOUD Object Storage, sans que le serveur API ne fasse de proxy des octets. Quelle approche boto3 implémente correctement cela avec IONOS CLOUD Object Storage ?
IONOS CLOUD Object Storage expose l'API AWS S3 et s'authentifie avec une clé d'accès et une clé secrète. Par conséquent, boto3 doit recevoir un endpoint_url explicite ainsi que ces identifiants, et les URL présignées permettent au navigateur de téléverser sans que l'API ne touche aux 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 consommateur Kafka au worker TaskBoard afin qu'il puisse réagir aux événements de modification de tâches. Une connexion depuis le code applicatif avec uniquement un nom d'utilisateur et un mot de passe échoue lors de l'authentification sur le plan de données Kafka d'IONOS CLOUD. Quelle configuration du client est requise pour une authentification correcte ?
Le plan de données Kafka d'IONOS CLOUD authentifie les clients via TLS mutuel, de sorte que le consommateur doit présenter un certificat client sur une connexion chiffrée. Le jeton Bearer ne s'applique qu'à l'API de gestion, le texte clair n'est jamais accepté, et les identifiants Access Key et Secret Key appartiennent à Object Storage, et non à Kafka.
TaskBoard utilise IONOS CLOUD In-Memory DB (Redis) comme cache de session et de lecture pour mettre à l'échelle les lectures, car le cluster PostgreSQL ne dispose d'aucune réplique de lecture pour décharger ce trafic. Sous une charge soutenue, le cache atteint sa limite de mémoire. Avec la configuration par défaut, que se passe-t-il pour les nouvelles écritures une fois la mémoire pleine ?
IONOS CLOUD In-Memory DB utilise par défaut la politique d'éviction allkeys-lru, de sorte que lorsque la mémoire est épuisée, elle évince les clés les moins récemment utilisées plutôt que de rejeter les écritures, ce qui est le comportement attendu pour un cache de lecture en mode cache-aside. Renvoyer des erreurs à chaque écriture est le comportement d'une politique noeviction, et le cluster ne met pas à l'échelle les nœuds automatiquement pour absorber la pression sur le cache.
L'API TaskBoard appelle IONOS CLOUD AI Model Hub pour résumer les descriptions de tâches. Lors d'une augmentation du trafic, les requêtes d'inférence commencent à renvoyer des réponses HTTP 429. Quelle modification gère correctement cette situation dans le code de production ?
AI Model Hub renvoie HTTP 429 Too Many Requests lorsque la limite de débit est dépassée, de sorte que le code de production doit appliquer un retour exponentiel et réduire le 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 la limitation de débit, l'API s'authentifie avec un jeton Bearer plutôt qu'avec une authentification Basic, et le service est un point de terminaison IONOS CLOUD, et non AWS Bedrock.