8.4 Vérification des connaissances - Architecture conforme aux bonnes pratiques

1.

Un niveau FinCorp doit effectuer une mise à l'échelle horizontale automatique sous charge variable. Un architecte configure un groupe VM Auto Scaling avec un seuil de mise à l'échelle horizontale à 70 % de CPU et un seuil de réduction à 50 % de CPU, en s'attendant à ce que la bande de 20 points maintienne le groupe stable. La plateforme rejette la politique. Quelle règle a été violée, et quel est le principe de conception correct ?

A VM Auto Scaling exige que les seuils de réduction et de mise à l'échelle horizontale soient séparés d'au moins 40 points de pourcentage ; la bande de 20 points est rejetée car une bande morte trop étroite permet à une seule lecture de métrique bruitée de déclencher une mise à l'échelle horizontale suivie d'une réduction immédiate. B Les seuils doivent être identiques pour que le groupe se mette à l'échelle de manière symétrique ; tout écart, même minime, est rejeté comme ambigu. C Le seuil de réduction doit être supérieur au seuil de mise à l'échelle horizontale, de sorte que 50 % et 70 % sont inversés. D Une politique à métrique unique ne peut utiliser que les octets réseau, et non l'utilisation du CPU, de sorte que la politique est rejetée sur la métrique plutôt que sur les seuils.

2.

Un architecte a produit une conception fonctionnellement complète pour le traitement conteneurisé réglementé de FinCorp, en l'exécutant sur Managed Kubernetes, et applique désormais le filtre de souveraineté et d'attestation. Le contrat de la charge de travail exige contractuellement une couverture BSI C5. Que révèle le filtre, et quelle est la conclusion correcte ?

A Managed Kubernetes ne fait pas partie du périmètre d'attestation C5, de sorte que bien que le choix soit fonctionnellement pertinent, il ne passe pas le filtre de périmètre ; la charge de travail exigeant C5 doit être déployée sur un service couvert par C5, tel que Compute Engine. B Managed Kubernetes bénéficie de C5 car IONOS CLOUD détient l'attestation C5, de sorte que l'accréditation à l'échelle de la plateforme couvre tous les services managés et la conception passe sans modification. C Le filtre est appliqué en premier, de sorte que la conception aurait dû commencer par le périmètre C5 ; comme ce n'est pas le cas, l'ensemble de l'architecture doit être abandonné et reconstruit à partir de zéro. D C5 et IT-Grundschutz couvrent le même ensemble de services, de sorte que puisque Managed Kubernetes relève d'IT-Grundschutz, il satisfait automatiquement à la exigence C5 également.

3.

Dans l'architecture de référence, le chemin de la requête est délibérément hiérarchisé : un équilibreur de charge public à la périphérie et un équilibreur de charge privé devant la couche de données. Un ingénieur propose un unique NLB de couche 4 aux deux positions pour standardiser, et propose d'entourer chaque équilibreur de charge managé par un Network Security Group pour le filtrage. Pourquoi le design de référence rejette-t-il les deux propositions ?

A Un unique ALB de couche 7 devrait être placé aux deux positions à la place, car le routage de contenu de couche 7 est nécessaire de manière égale à la périphérie et sur le chemin interne est-ouest vers la base de données. B Les propositions sont solides ; la séparation en deux niveaux et le choix de la couche de l'équilibreur de charge sont interchangeables, et un NSG attaché à un équilibreur de charge managé est l'endroit correct pour le filtrage. C La couche 7 appartient à la périphérie publique pour le routage conscient du contenu et la terminaison TLS, tandis que la couche 4 appartient au réseau interne pour une passation TCP rapide, le backend conservant son certificat ; et aucun équilibreur de charge managé n'accepte un NSG ni une liste d'autorisation IP, donc le filtrage doit résider sur les cibles situées derrière eux. D Les deux équilibreurs de charge devraient être remplacés par le routage de vérification d'état de Cloud DNS, car DNS effectue l'équilibrage de charge et applique les règles de Network Security Group au niveau du résolveur.

4.

La construction finale assemble les éléments de chaque module en un seul VDC. Une équipe provisionne les ressources dans cet ordre : elle crée d'abord le NLB de couche 4 privé, puis les serveurs de la couche de données qu'il doit servir, ensuite une passerelle NAT, et elle s'attend à ce que les charges de travail privées accèdent à Internet dès que la passerelle NAT existe. Quelle évaluation de leur séquence est correcte ?

A La séquence est correcte, car la plateforme réorganise le travail automatiquement et un équilibreur de charge peut être créé avant ses cibles sans conséquence. B Seule l'étape NAT est incorrecte ; le NLB peut être créé en toute sécurité avant ses cibles, car il les détecte automatiquement dès qu'elles apparaissent. C Les deux étapes sont correctes, à condition que la passerelle NAT dispose d'une adresse IP publique réservée, car la route par défaut est configurée par la plateforme chaque fois qu'une passerelle est attachée. D Les deux étapes sont incorrectes : un équilibreur de charge a besoin de ses cibles d'abord, donc les serveurs de la couche de données doivent exister avant le NLB qui les sert, et une passerelle NAT ne fournit aucun trafic sortant tant que la route par défaut du LAN privé n'est pas redirigée vers elle, car la plateforme n'effectue pas cette modification de routage à votre place.

5.

L'auditeur de FinCorp demande à l'architecte de montrer, service par service, quelle reconnaissance BSI couvre chaque composant de la conception déployée. L'architecte doit répondre avec précision plutôt que d'affirmer que la plateforme est certifiée. Quelle affirmation reflète le mappage de conformité par service correct ?

A Les deux reconnaissances BSI sont applicables à l'ensemble de la plateforme, de sorte que chaque service managé dans un centre de données allemand est couvert à la fois par C5 et IT-Grundschutz, et l'on peut informer l'auditeur que la plateforme est certifiée. B C5 couvre Managed Kubernetes et Backup, tandis qu'IT-Grundschutz couvre Cloud Cubes, de sorte que les deux reconnaissances ne se chevauchent jamais sur aucun service. C C5 couvre exactement Compute Engine, Cloud Cubes et Object Storage ; IT-Grundschutz couvre exactement Compute Engine, Object Storage, Backup et Managed Kubernetes ; les périmètres divergent, de sorte que Cubes sont couverts par C5 mais pas par IT-Grundschutz, tandis que Managed Kubernetes et Backup sont couverts par IT-Grundschutz mais pas par C5. D La conformité est identique pour chaque service, de sorte que mentionner une accréditation, un service et un emplacement de centre de données n'apporte rien dont l'auditeur ait besoin.