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

1.

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

A Les standbys peuvent servir des lectures, mais uniquement en mode de réplication strictement synchrone, donc le Cluster doit d'abord être commuté sur ce mode avant que le trafic de reporting ne soit acheminé vers un standby. B Managed PostgreSQL n'a pas de réplicas de lecture et les standbys n'existent que pour le basculement, donc la mise à l'échelle des lectures provient d'un In-Memory DB cache placé devant le Cluster, avec un pooler de connexions géré pour multiplexer les connexions. C Les réplicas de lecture existent, mais sont limités au décompte d'instances d'un à cinq du Cluster, donc l'architecte devrait provisionner les cinq standbys maximum et équilibrer les lectures à travers eux. D Le trafic de reporting devrait être servi à partir d'un Block Storage Snapshot de la base de données Volume, restauré dans un second Cluster en lecture seule sur un calendrier.

2.

Un architecte conçoit la continuité des données pour le patrimoine de FinCorp, qui comprend des machines virtuelles migrées, des volumes Block Storage, un Managed PostgreSQL Cluster, et un Managed MongoDB Cluster. Un membre de l'équipe 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 patrimoine. Quel est le défaut décisif ?

A Le Backup Service ne peut pas protéger les machines virtuelles sur site ou dans d'autres nuages, il ne peut donc pas servir un patrimoine 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 que les bases de données requièrent. C Le Backup Service peut protéger les bases de données, mais seulement si chaque base de données Volume est d'abord convertie en stockage DAS NVMe. D Le Backup Service couvre les machines virtuelles et les Block Storage, mais ne sauvegarde explicitement pas les bases de données gérées, les clusters PostgreSQL et MongoDB ont donc besoin de leur propre continuité native (PITR plus dump/restore logique vers Object Storage) plutôt que d'un agent de sauvegarde.

3.

FinCorp doit conserver son archive d'audit pluriannuelle dans Object Storage en tant que rétention tamper-evident, écriture unique qui ne peut être raccourcie ou supprimée par personne, même un administrateur de contrat, avant la date de rétention. L'architecte met en place un bucket appartenant à un contrat dans une région allemande, télécharge les premières exportations, puis tente d'activer Object Lock en mode COMPLIANCE. La console n'offre aucune option pour l'activer. Qu'est-ce qui s'est mal passé, et quelle est la conception correcte ?

A Object Lock ne peut être activé que lorsque le bucket est créé, et non ajouté par la suite, donc 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é à API, donc le verrou doit être activé via le S3 API plutôt que le Data Center Designer, mais il peut toujours être ajouté au bucket existant. C Object Lock nécessite que la versioning soit désactivée au préalable ; une fois la versioning désactivée, 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é, donc l'architecte devrait configurer GOVERNANCE sur le bucket existant, puis le mettre à niveau.

4.

Le flux de transactions à haute Volume de FinCorp passe par Event Streams for Apache Kafka. L'exigence est que tous les événements pour un compte donné soient traités dans l'ordre où ils se sont produits, tandis que les différents comptes sont traités de manière concurrente, et que les partitions se répartissent uniformément sur les trois courtiers de Cluster. Quel design de sujet satisfait aux trois contraintes à la fois ?

A Créer le sujet avec une seule partition pour garantir l'ordre global, puis exécuter de nombreux consommateurs dans un groupe pour gagner de la parallélisme entre les comptes. B Créer le sujet avec 5 partitions et compter sur la production round-robin, en acceptant que l'ordre soit maintenu par sujet plutôt que par compte. C Définir une clé de partition sur l'identifiant de compte et commencer avec 3 partitions (un multiple des trois courtiers), en mettant à l'échelle à 6 ou 9 seulement lorsque le débit mesuré le justifie, dimensionné à l'avance car l'ajout de partitions plus tard réorganise les clés et rompt l'ordre par clé. D Créer le sujet avec autant de partitions que de consommateurs attendus au pic, indépendamment du nombre de courtiers, puisque plus de partitions améliorent toujours le débit sans inconvénient.

5.

Les bases de données gérées de FinCorp n'exposent pas un flux de capture de données modifiées que les systèmes en aval peuvent souscrire, pourtant l'entrepôt d'analyse, le modèle de fraude et un index de recherche doivent tous réagir à chaque modification. L'architecture doit également permettre au niveau IA de ré-lire l'historique des modifications à partir d'une position validée lorsque le modèle est ré-entraîné. Quelle approche est le substitut natif sur IONOS ?

A Suivre le journal d'écriture anticipé de PostgreSQL directement à partir de chaque consommateur en aval, puisque le WAL est le flux de modification intégré de la plateforme. B Planifier un dump logique périodique de la base de données vers Object Storage et faire en sorte que chaque système en aval détecte les modifications en comparant les dumps successifs. C Activer la réplication de flux de modification gérée MongoDB vers une deuxième Cluster et pointer l'entrepôt, le modèle de fraude et l'index de recherche vers cette réplique. D Faire en sorte que l'application publie un événement de domaine sur 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 à partir de son propre décalage validé.

6.

FinCorp a besoin d'une copie à l'épreuve de falsification, à long terme, de ses données Managed PostgreSQL qui survive en dehors du Cluster et qui peut être conservée pendant des années, séparément de la fenêtre de récupération ponctuelle de 7 jours du Cluster. Quelle composition répond à cette exigence tout en respectant les limites de la plateforme ?

A Étendre la rétention PITR du PostgreSQL à son maximum et traiter le magasin de sauvegarde immutable du Cluster comme l'archive portable à long terme. B Effectuer des dumps logiques planifiés avec pg_dump et les stocker dans un seau Object Storage avec un verrou d'objet en mode COMPLIANCE, puisque PITR est lié à la fenêtre et au Cluster tandis qu'un dump est une copie portable et tolérante aux versions, et que le verrou d'objet fournit la preuve de non-falsification. C Effectuer des snapshots réguliers Block Storage de la base de données Volume et les copier dans Object Storage, en comptant sur les snapshots comme sauvegarde à long terme cohérente avec la base de données. D Diriger l'agent Backup Service vers l'hôte de la base de données et envoyer sa sortie à un seau verrouillé d'objets pour la copie à long terme.