Vérification des connaissances - Fondements programmatiques
Testez votre compréhension des concepts clés du Module 1. 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 script de développeur crée un serveur avec un POST à /cloudapi/v6/datacenters/{dcId}/servers, puis émet immédiatement un deuxième appel pour attacher un Volume à ce serveur. L'appel Volume échoue intermittamment avec un 404. Quel est la solution correcte ?
La mise à disposition d'IONOS est asynchrone : un POST renvoie 202 Accepted avec la ressource dans l'état BUSY, et un 404 immédiatement après la création signifie « pas encore prêt », et non « manquant ». Vous devez interroger l'URL de statut de la demande à partir de l'en-tête Location jusqu'à ce que DONE soit atteint avant tout appel dépendant. Les réessais serrés gaspillent le budget de limitation de taux sans résoudre la cause, et depth ne contrôle que la taille de la charge utile de la réponse.
Un travail planifié qui génère un jeton porteur frais à chaque exécution commence à échouer avec des erreurs d'authentification après plusieurs semaines, et le Token Manager affiche des dizaines de jetons. Quelle est la limite sous-jacente et le modèle correct ?
Un utilisateur peut générer jusqu'à 100 jetons d'authentification, donc un script qui crée un nouveau jeton à chaque exécution épuise éventuellement la quote-part. Le modèle correct est d'émettre un jeton étendu à TTL court par service ou environnement, de le capturer lors de sa création (la valeur n'est affichée qu'une seule fois) et de le réutiliser jusqu'à son expiration, puis de le faire pivoter. Un jeton à longue durée de vie partagé unique viole le principe de privilège minimal, et les TTL des jetons sont choisis dans un ensemble fixe allant de 1 heure à 365 jours, et non une heure fixe.
Un développeur liste les ressources avec GET /cloudapi/v6/datacenters et traite les éléments renvoyés, mais découvre plus tard que certaines ressources n'ont jamais été vues par le script. La collection comporte plus de 1000 entrées. Que s'est-il passé et comment doit-il être géré ?
Les points de terminaison de liste renvoient des collections paginées avec une limite par défaut de limit de 1000 et une limite par défaut de offset de 0, donc un seul appel ne voit que la première page. La solution consiste à itérer, en augmentant offset de la taille de la page jusqu'à ce qu'une page renvoie moins de limit éléments. Le paramètre depth contrôle la quantité de l'arbre de ressources imbriquées qui est intégrée par élément, et non le nombre d'éléments renvoyés, et 429 est la réponse de limitation de débit, sans rapport avec la pagination.
Un développeur ajoute un seau IONOS Object Storage en tant que backend d'état distant Terraform, mais terraform init échoue avec des erreurs concernant le Security Token Service et un ID de compte manquant. Quel changement corrige le bloc backend ?
Le backend S3 suppose AWS et tente des appels spécifiques à AWS (STS, recherche d'ID de compte) que IONOS Object Storage n'implémente pas, donc les indicateurs skip_* plus un point de terminaison IONOS explicite (par exemple https://s3.eu-central-1.ionoscloud.com) sont nécessaires. IONOS Object Storage est compatible avec S3 et fonctionne correctement en tant que backend, mais il s'authentifie avec une clé d'accès et une clé secrète, et non avec un jeton porteur. IONOS ne fournit pas de table de verrouillage DynamoDB, donc l'ajout d'une table n'est pas une option.
Un développeur souhaite placer un serveur créé précédemment avec un script curl sous la gestion de Terraform sans le recréer. Quelle approche est correcte ?
Les imports IONOS utilisent un ID composé reliant l'ID de centre de données et l'ID de ressource (dc_id/server_id), et le flux de travail consiste à écrire un bloc ionoscloud_server correspondant, à importer, puis à ajuster le HCL jusqu'à ce que terraform plan ne signale aucune modification. Terraform n'adopte pas automatiquement les ressources existantes sur apply, et terraform refresh ne met à jour l'état que pour les ressources déjà gérées. La suppression et la recréation contredisent l'objectif de préserver le serveur existant.