Vérification des connaissances - Fondements de la programmation
Évaluez 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 au moins 60 % pour réussir.
Le script d'un développeur crée un serveur avec un POST vers /cloudapi/v6/datacenters/{dcId}/servers, puis émet immédiatement un second appel pour attacher un volume à ce serveur. L'appel du volume échoue de manière intermittente avec un 404. Quelle est la correction appropriée ?
Le provisionnement IONOS CLOUD est asynchrone : un POST renvoie 202 Accepted avec la ressource dans l'état BUSY, et un 404 juste après la création signifie « pas encore prêt », et non « introuvable ». Vous devez interroger l'URL d'état de la requête de l'en-tête Location jusqu'à DONE avant tout appel dépendant. Les réessais serrés gaspillent le budget de limitation de débit sans traiter 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 nouveau jeton porteur à 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, de sorte qu'un script qui crée un nouveau jeton à chaque exécution finit par épuiser le quota. Le modèle correct consiste à émettre un jeton à portée limitée et à durée de vie courte par service ou par environnement, à le capturer lors de sa création (la valeur n'est affichée qu'une seule fois), et à le réutiliser jusqu'à son expiration, puis à le faire tourner. Un jeton partagé à longue durée de vie viole le principe du moindre privilège, et les durées de vie des jetons sont choisies dans un ensemble fixe allant de 1 heure à 365 jours, et non une durée fixe de 1 heure.
Un développeur liste des ressources avec GET /cloudapi/v6/datacenters et traite les éléments retournés, mais découvre plus tard que certaines ressources n'ont jamais été vues par le script. La collection contient plus de 1000 entrées. Qu'est-ce qui s'est passé et comment faut-il le gérer ?
Les points d'entrée de liste retournent des collections paginées avec un limit par défaut de 1000 et un offset par défaut de 0, de sorte qu'un seul appel ne voit que la première page. La correction consiste à itérer, en augmentant offset de la taille de la page jusqu'à ce qu'une page retourne moins de limit éléments. Le paramètre depth contrôle la quantité de l'arborescence de ressources imbriquées qui est inline par élément, et non le nombre d'éléments retournés, et 429 est la réponse de limitation de débit, sans rapport avec la pagination.
Un développeur ajoute un bucket IONOS CLOUD Object Storage en tant qu'arrière-plan d'état distant pour Terraform, mais terraform init échoue avec des erreurs concernant le Security Token Service et un identifiant de compte manquant. Quelle modification corrige le bloc d'arrière-plan ?
L'arrière-plan S3 suppose qu'il s'agit d'AWS et tente des appels spécifiques à AWS (STS, recherche d'identifiant de compte) que IONOS CLOUD Object Storage n'implémente pas. Les options skip_* ainsi qu'un point de terminaison IONOS CLOUD explicite (par exemple https://s3.eu-central-1.ionoscloud.com) sont donc nécessaires. IONOS CLOUD Object Storage est compatible avec S3 et fonctionne correctement en tant qu'arrière-plan, mais il s'authentifie avec une clé d'accès et une clé secrète, et non avec un jeton porteur. IONOS CLOUD ne fournit pas de table de verrouillage DynamoDB, il n'est donc pas possible d'en ajouter une.
Un développeur souhaite placer sous gestion Terraform un serveur créé précédemment par un script curl, sans le recréer. Quelle approche est correcte ?
Les importations IONOS CLOUD utilisent un identifiant composé qui associe l'identifiant du datacenter et l'identifiant de la ressource (dc_id/server_id), et le processus consiste à rédiger un bloc ionoscloud_server correspondant, à importer, puis à ajuster le HCL jusqu'à ce que terraform plan ne signale plus de modifications. Terraform n'adopte pas automatiquement les ressources existantes lors de apply, et terraform refresh ne met à jour l'état que pour les ressources déjà gérées. Supprimer et recréer le serveur contrevient à l'objectif de conserver le serveur existant.