Vérification des connaissances - Opérations de production
Vérifiez 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 un score d'au moins 60 % pour réussir.
Un développeur déploie TaskBoard sur Managed Kubernetes, puis ouvre le Logging Service Grafana, en s'attendant à voir les journaux du pod et du plan de contrôle de Cluster. La vue est vide. Quelle est la solution correcte ?
Les événements de plan de contrôle de Kubernetes NE passent PAS automatiquement par l'IONOS Logging Service ; la plateforme ne transmet PAS les journaux de Cluster pour vous. Vous devez les transmettre vous-même avec un DaemonSet Fluent Bit ou en activant la journalisation centralisée. Les valeurs de rétention et la contrainte JSON-seulement s'appliquent à la source HTTP, et non au chemin de transmission de Kubernetes, et il n'y a pas de flag loggingEnabled de création qui résout ce problème.
Un développeur crée un Monitoring Service pipeline, voit une réponse 201 réussie, puis ferme le terminal sans lire le corps. Le lendemain, son agent de métriques renvoie 401 pour chaque push vers /api/v1/push et il ne peut 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 par pipeline uniquement une fois, en metadata.key lors de la création, et plus jamais 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 pipeline frais ou faire pivoter la clé. Prometheus, Grafana Agent et OpenTelemetry s'authentifient tous avec l'en-tête APIKEY, donc le format d'en-tête est correct ; il n'y a pas de durée de vie de clé quotidienne.
Un développeur débogue une défaillance de connectivité entre les couches de TaskBoard. Les journaux d'application sont silencieux, il doit donc confirmer au niveau du réseau si le trafic est bloqué. Il ajoute un Flow Log sur la carte réseau, puis se rend compte qu'il a défini la direction de capture incorrecte. Quelle est la bonne façon de la modifier ?
La configuration du Flow Log est immuable après sa création, et il n'y a qu'un journal de flux par ressource. Pour modifier un paramètre, y compris la direction de capture, vous supprimez le journal de flux existant et en créez un nouveau ; il n'y a pas de chemin de mise à jour en place via PATCH ou Terraform, et vous ne pouvez pas attacher un second journal de flux à la même ressource.
Un développeur a besoin que le pipeline CI TaskBoard s'authentifie auprès de l'IONOS API et souhaite que toute fuite de ces informations d'identification soit contenue et récupérable rapidement. Quelle approche de jeton est correcte ?
Le modèle sécurisé est un jeton par service par environnement (jusqu'à 100 par utilisateur) avec la durée de vie la plus courte tolérable à partir de l'ensemble fixe, tourné générer-then-révocation afin qu'il n'y ait jamais d'interruption. Un jeton partagé au niveau du contrat signifie qu'une seule fuite peut tout détruire, 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 point de terminaison de relecture.
Un développeur expose TaskBoard sur MKS avec un Service de type: LoadBalancer. En production, ils observent que tout le trafic atterrit sur un worker Node, la source client IP est perdue, et le débit plat autour de 2 Gbit/s. Quel énoncé explique correctement cela et la solution de production ?
Sur MKS, un Service type: LoadBalancer attribue une adresse IP publique réservée IP comme adresse IP secondaire IP à une seule entrée Node et kube-proxy NAT à la capsule, donc la source IP est perdue (corrigée avec externalTrafficPolicy: Local) et le débit est limité à 2 Gbit/s. Le trafic de production doit passer par un ALB géré séparément à partir de la couche Terraform. Les NSG ne sont pas liés aux équilibreurs de charge gérés ou aux nœuds MKS, et un PodDisruptionBudget protège la disponibilité pendant les réinitialisations plutôt que d'affecter l'acheminement.