Vérification des connaissances - Opérations de production
Évaluez votre compréhension des concepts clés du Module 5. 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 déploie TaskBoard sur Managed Kubernetes, puis ouvre Grafana du Logging Service, en s'attendant à voir les journaux des pods et du plan de contrôle du cluster. La vue est vide. Quelle est la correction appropriée ?
Les événements du plan de contrôle Kubernetes ne transitent PAS automatiquement par le Logging Service d'IONOS CLOUD ; la plateforme n'envoie pas les journaux du cluster à votre place. Vous devez les transmettre vous-même à l'aide d'un DaemonSet Fluent Bit ou en activant la Central Logging. Les valeurs de rétention et la contrainte JSON uniquement s'appliquent à la source HTTP, et non au chemin de transfert Kubernetes, et il n'existe aucun drapeau loggingEnabled au moment de la création qui résolve ce problème.
Un développeur crée un pipeline Monitoring Service, observe une réponse 201 réussie, puis ferme le terminal sans lire le corps de la réponse. Le lendemain, son agent de métriques renvoie 401 à chaque poussée vers /api/v1/push et il ne parvient pas à trouver un moyen de récupérer la clé d'ingestion. Que s'est-il passé ?
Le Monitoring Service renvoie la clé d'ingestion propre à chaque pipeline une seule fois, dans metadata.key lors de la création, et ne la renvoie plus jamais par la suite pour des raisons de sécurité. Si le corps de la réponse n'est pas capturé, la clé ne peut pas être récupérée et vous devez provisionner un nouveau pipeline ou effectuer une rotation de la clé. Prometheus, Grafana Agent et OpenTelemetry s'authentifient tous avec l'en-tête APIKEY, le format de l'en-tête est donc correct ; il n'y a pas de durée de vie quotidienne pour la clé.
Un développeur dépanne une défaillance de connectivité entre les niveaux de TaskBoard. Les journaux d'application sont silencieux, il doit donc confirmer au niveau réseau si le trafic est bloqué. Il ajoute un Flow Log sur la NIC, puis se rend compte qu'il a défini la direction de capture incorrecte. Quelle est la bonne méthode pour la modifier ?
La configuration du Flow Log est immuable après sa création, et il y a un seul flow log par ressource. Pour modifier un paramètre, y compris la direction de capture, vous supprimez le flow log existant et en créez un nouveau ; il n'existe aucune voie de mise à jour sur place via PATCH ou Terraform, et vous ne pouvez pas attacher un second flow log à la même ressource.
Un développeur a besoin que le pipeline CI de TaskBoard s'authentifie à l'API IONOS CLOUD et souhaite qu'une fuite de cette information d'authentification soit contenue et récupérable rapidement. Quelle approche de jeton est correcte ?
Le modèle sûr consiste à utiliser un jeton par service et par environnement (jusqu'à 100 par utilisateur) avec la durée de vie la plus courte tolérable parmi l'ensemble fixe, en effectuant une rotation par révocation après génération afin qu'il n'y ait jamais de lacune. Un jeton partagé à l'échelle du contrat signifie qu'une seule fuite met tout à terre, l'authentification de base est en cours de suppression et ne doit pas être utilisée dans l'automatisation, et la valeur du jeton est affichée exactement une fois, sans endpoint de relecture.
Un développeur expose TaskBoard sur MKS avec un Service de type: LoadBalancer. En production, il constate que tout le trafic est dirigé vers un seul nœud de travail, que l'adresse IP source du client est perdue et que le débit plafonne autour de 2 Gbit/s. Quelle affirmation explique correctement ce phénomène et la correction à apporter en production ?
Sur MKS, un Service type: LoadBalancer attribue une adresse IP publique réservée en tant qu'IP secondaire à un seul nœud d'entrée et kube-proxy effectue le NAT vers le pod, ce qui entraîne la perte de l'adresse IP source (corrigée avec externalTrafficPolicy: Local) et limite le débit au plafond de 2 Gbit/s de ce nœud. Le trafic de production doit transiter par un Managed ALB provisionné séparément depuis la couche Terraform. Les NSG ne sont pas liés aux équilibreurs de charge managés ni aux nœuds MKS, et un PodDisruptionBudget protège la disponibilité lors des reconstructions plutôt que d'influencer le routage.