5.8 Vérification des connaissances - Données et stockage

1.

Le portail client de FinCorp fournit des vues de récapitulatif de compte et d'historique des transactions qui sont lues beaucoup plus souvent qu'elles ne sont écrites, le tout à partir d'un cluster Managed PostgreSQL réglementé sur la couche de données privée. Un architecte propose d'ajouter des répliques de lecture à ce cluster et de diriger le trafic de reporting vers un serveur de secours. Pourquoi est-ce le mauvais point de départ, et quel est le modèle natif ?

A Les serveurs de secours peuvent servir des lectures, mais uniquement en mode de réplication strictement synchrone, de sorte que le cluster doit d'abord être basculé dans ce mode avant que le trafic de reporting ne soit routé vers un serveur de secours. B Managed PostgreSQL ne dispose pas de répliques de lecture et les serveurs de secours existent uniquement pour la bascule, de sorte que la mise à l'échelle de la lecture provient d'une couche de cache In-Memory DB placée devant le cluster, avec un pooler de connexions managé pour multiplexer les connexions. C Les répliques de lecture existent mais sont limitées au nombre d'instances du cluster, qui est de un à cinq, de sorte que l'architecte devrait provisionner le maximum de cinq serveurs de secours et équilibrer les lectures entre eux. D Le trafic de reporting devrait être servi à partir d'une image de Block Storage du volume de base de données, restaurée dans un second cluster en lecture seule selon un horaire.

2.

Un architecte conçoit la continuité des données pour le parc de FinCorp, qui comprend des VM migrées, des volumes Block Storage, un cluster Managed PostgreSQL et un cluster Managed MongoDB. Un collègue propose un plan unique : installer l'agent Backup Service basé sur Acronis partout, y compris sur les hôtes de base de données, afin qu'une seule console couvre l'ensemble du parc. Quel est le défaut déterminant ?

A Le Backup Service ne peut pas protéger les VM sur site ou dans d'autres clouds, il ne peut donc pas servir un parc hybride pendant la migration. B Le Backup Service fournit des sauvegardes immuables par défaut, ce qui entrerait en conflit avec l'expiration du cycle de vie requise par les bases de données. C Le Backup Service peut protéger les bases de données, mais uniquement si chaque volume de base de données est d'abord converti en stockage DAS NVMe. D Le Backup Service couvre les VM et le Block Storage, mais ne sauvegarde explicitement pas les bases de données gérées, de sorte que les clusters PostgreSQL et MongoDB ont besoin de leur propre continuité native (PITR plus déchargement/restauration logique vers Object Storage) plutôt que d'un agent de sauvegarde.

3.

FinCorp doit conserver son archive d'audit pluriannuelle dans Object Storage avec une rétention infalsifiable et en écriture unique, qu'aucun administrateur de contrat ne peut raccourcir ni supprimer avant la date de rétention. L'architecte provisionne un bucket appartenant au contrat dans une région allemande, téléverse les premiers exports, puis tente d'activer Object Lock en mode COMPLIANCE. La console n'offre aucune option pour l'activer. Qu'est-ce qui s'est passé, et quelle est la conception correcte ?

A Object Lock ne peut être activé que lors de la création du bucket, et ne peut jamais être ajouté ultérieurement, de sorte que l'archive doit être placée dans un nouveau bucket créé avec Object Lock en mode COMPLIANCE dès le départ. B Le mode COMPLIANCE est réservé à l'API, de sorte que le verrouillage doit être activé via l'API S3 plutôt que par Data Center Designer, mais il peut toujours être ajouté au bucket existant. C Object Lock exige d'abord que le versioning soit désactivé ; une fois le versioning désactivé, le mode COMPLIANCE devient disponible sur le bucket existant. D Le mode GOVERNANCE doit être activé avant que le mode COMPLIANCE puisse être sélectionné, de sorte que l'architecte doit définir GOVERNANCE sur le bucket existant puis le mettre à niveau.

4.

Le flux de transactions à fort volume de FinCorp transite par Event Streams for Apache Kafka. L'exigence est que tous les événements d'un compte donné soient traités dans l'ordre où ils se sont produits, que les différents comptes soient traités de manière concurrente, et que les partitions soient réparties uniformément sur les trois brokers du cluster. Quelle conception de sujet satisfait simultanément aux trois contraintes ?

A Créer le sujet avec une seule partition afin de garantir un ordre global, puis exécuter de nombreux consommateurs dans un même groupe pour obtenir de la parallélisation entre les comptes. B Créer le sujet avec 5 partitions et compter sur une production en rotation, en acceptant que l'ordre soit respecté par sujet et non par compte. C Définir une clé de partition sur l'identifiant du compte et démarrer avec 3 partitions (un multiple des trois brokers), en passant à 6 ou 9 uniquement lorsque le débit mesuré le justifie, en dimensionnant dès le départ car l'ajout de partitions ultérieurement recalcule les clés et rompt l'ordre par clé. D Créer le sujet avec autant de partitions que le nombre maximal de consommateurs prévu, indépendamment du nombre de brokers, car plus il y a de partitions, meilleur est le débit, sans inconvénient.

5.

Les bases de données gérées de FinCorp n'exposent pas de flux de capture des modifications (change-data-capture) auquel les systèmes en aval peuvent s'abonner, et pourtant l'entrepôt analytique, le modèle de détection de fraude et l'index de recherche doivent tous réagir à chaque modification. L'architecture doit également permettre à la couche IA de relire l'historique des modifications à partir d'une position confirmée lors d'une nouvelle formation d'un modèle. Quelle est l'alternative native sur IONOS CLOUD ?

A Suivre directement le journal d'avance d'écriture (Write-Ahead Log) de PostgreSQL depuis chaque consommateur en aval, car le WAL constitue le flux de modifications intégré de la plateforme. B Planifier un déchargement logique périodique de la base de données vers Object Storage et faire en sorte que chaque système en aval compare les déchargements successifs pour détecter les modifications. C Activer la réplication des flux de modifications gérée par MongoDB vers un second cluster et orienter l'entrepôt analytique, le modèle de détection de fraude et l'index de recherche vers cette réplique. D Faire en sorte que l'application publie un événement de domaine dans un sujet Kafka au moment où elle effectue chaque modification, chaque système en aval consommant le sujet en tant que groupe de consommateurs indépendant lisant depuis son propre décalage confirmé.

6.

FinCorp a besoin d'une copie longue durée de ses données Managed PostgreSQL, infalsifiable, qui existe en dehors du cluster et peut être conservée pendant des années, indépendamment de la fenêtre de récupération instantanée (PITR) de 7 jours propre au cluster. Quelle composition répond à cette exigence tout en respectant les limites de la plateforme ?

A Prolonger la rétention PITR de PostgreSQL à sa valeur maximale et considérer le magasin de sauvegardes immuable du cluster comme l'archive portable à long terme. B Effectuer des déchargements logiques planifiés avec pg_dump et les stocker dans un bucket Object Storage avec verrouillage d'objets en mode COMPLIANCE, car le PITR est limité par une fenêtre temporelle et lié au cluster, tandis qu'un déchargement constitue une copie portable et tolérante aux versions, et que le verrouillage d'objets fournit une preuve d'infalsifiabilité. C Prendre régulièrement des instantanés Block Storage du volume de base de données et les copier dans Object Storage, en s'appuyant sur ces instantanés comme sauvegarde à long terme cohérente au niveau de la base de données. D Orienter l'agent Backup Service vers l'hôte de la base de données et envoyer sa sortie vers un bucket verrouillé par objet pour la copie longue durée.