6.7 Vérification des connaissances - Conteneurs et plateforme IA

1.

Une équipe qui migre une couche web publique vers un cluster public Managed Kubernetes déclare un Service de type LoadBalancer et suppose qu'elle dispose désormais d'un équilibreur de charge externe hautement disponible, préservant l'adresse IP source, équivalent au Managed Network Load Balancer utilisé ailleurs dans l'infrastructure. L'architecte fait objection. Pourquoi cette supposition est-elle erronée, et quelle est la bonne méthode pour mettre en avant la charge de travail ?

A Un Service de type LoadBalancer n'est pas un équilibreur de charge externe managé ; IONOS CLOUD réserve une adresse IP publique statique et l'assigne comme IP secondaire à un seul nœud worker qui agit en tant que nœud d'entrée, de sorte que l'entrée en production doit être constituée d'un équilibreur de charge provisionné séparément et d'un contrôleur d'entrée au sein du cluster. B Un Service de type LoadBalancer est un équilibreur de charge L4 entièrement managé, mais il ne devient hautement disponible qu'une fois qu'au moins trois nœuds sont présents dans le pool, de sorte que la correction consiste simplement à mettre le pool de nœuds à l'échelle de trois. C Le type de Service fonctionne comme prévu ; la seule correction nécessaire est de définir externalTrafficPolicy: Cluster afin que le trafic soit équilibré automatiquement sur tous les nœuds. D Le manifeste du cluster provisionne automatiquement un Managed Network Load Balancer en arrière-plan, de sorte que l'équipe devrait supprimer le Service explicite et laisser le contrôleur le créer.

2.

Une équipe soucieuse des coûts, exécutant des travaux par lots sur un cluster Managed Kubernetes, souhaite que le pool de Node descende à zéro Node la nuit lorsque aucun travail ne s'exécute. Elle souhaite également que les événements du plan de contrôle du cluster soient acheminés vers le Logging Service centralisé, aux côtés de leurs journaux d'application. L'architecte explique que ces deux attentes entrent en conflit avec les limites de la plateforme. Quelle affirmation décrit correctement ces limites ?

A Les pools de Node peuvent passer à zéro, et les événements du plan de contrôle sont livrés par défaut au Logging Service dès que le cluster est créé. B Les pools de Node ne peuvent passer à zéro que sur les clusters privés, tandis que les événements du plan de contrôle atteignent le Logging Service uniquement sur les clusters publics. C L'auto-échelle du Cluster a un plancher d'un Node chaud et ne peut pas passer à zéro, et les événements du plan de contrôle n'atteignent pas le Logging Service, si bien que l'équipe doit concevoir autour d'un Node toujours actif et obtenir la visibilité sur le plan de contrôle par un autre moyen. D Les pools de Node peuvent passer à zéro si l'analyse des vulnérabilités est d'abord désactivée, et les événements du plan de contrôle atteignent le Logging Service une fois la journalisation d'audit vers S3 activée.

3.

Un architecte conçoit un cluster Managed Kubernetes privé pour une charge de travail soumise à des réglementations et énumère les prérequis. La construction concerne un cluster privé dont le plan de données doit être isolé, dont le serveur API ne doit être accessible que par l'équipe d'exploitation, et dont les nœuds doivent communiquer à travers un second VDC. Quel ensemble de décisions est correct ?

A Les clusters privés isolent le point d'accès API lui-même, de sorte qu'aucune liste d'autorisation n'est nécessaire ; le trafic sortant et le trafic inter-VDC fonctionnent sans aucune ressource réseau supplémentaire. B Provisionner une passerelle NAT et un Cross-Connect après le démarrage du cluster, et s'appuyer sur un groupe de sécurité lié à l'objet du cluster pour restreindre le serveur API. C Choisir le type de pool de nœuds de manière souple, car il peut être modifié ultérieurement, et protéger l'API en plaçant le plan de contrôle dans une région des États-Unis pour la redondance. D Un cluster privé isole le plan de données, mais pas le point d'accès API, il faut donc protéger l'API à l'aide d'une liste d'autorisation IP ; provisionner d'abord la passerelle NAT pour le trafic sortant et le Cross-Connect pour le trafic inter-VDC des nœuds ; conserver le plan de contrôle dans la même région pour la souveraineté et définir le type de pool de nœuds dès le départ, car il est immuable après la création.

4.

Une équipe plateforme souhaite gouverner l'accès à son Container Registry de la même manière qu'elle gère ses comptes cloud, en définissant des rôles tels que développeur en lecture seule, pipeline-pusher et administrateur, et en associant les utilisateurs et groupes humains à ces rôles. Elle souhaite également un niveau de tirage public anonyme pour les images open source. L'architecte explique que le registre ne fonctionne pas ainsi. Quel est le modèle de gouvernance correct ?

A Le registre prend en charge les rôles RBAC associés à des utilisateurs et des groupes, mais un niveau de tirage public doit être activé séparément pour chaque dépôt. B La gouvernance est gérée en désactivant les jetons lorsqu'une étape du pipeline est mise à la retraite, et un niveau de tirage public est disponible pour les images marquées comme open source. C Le registre hérite automatiquement des rôles IAM du compte cloud, de sorte que les associations de rôles existantes s'appliquent sans configuration supplémentaire. D Le registre ne dispose d'aucun RBAC ; l'accès est uniquement basé sur des jetons, la gouvernance provient donc de la discipline des jetons (un jeton à portée restreinte par étape du pipeline, avec une date d'expiration, une rotation régulière et une suppression plutôt qu'une désactivation), et il n'existe aucun niveau de tirage public.

5.

Une entreprise souhaite ajouter l'IA générative à une application réglementée, hébergée dans le pays, et doit conserver l'ensemble du traitement en Allemagne, éviter l'exploitation et la correction des vulnérabilités de l'infrastructure GPU, et s'intégrer à l'aide de ses bibliothèques de client OpenAI existantes. Elle a également besoin d'une récupération d'informations sur un corpus privé. Quelle approche correspond à la configuration par défaut pour les entreprises de la plateforme et à sa direction actuelle ?

A Héberger un modèle open source sur un pool de nœuds GPU dès le premier jour pour un meilleur contrôle, et stocker le corpus de récupération dans la fonctionnalité de magasin de vecteurs géré de la plateforme IA. B Utiliser l'inférence gérée sur l'AI Model Hub via son API compatible OpenAI, avec une tarification par jeton et un traitement sans état dans le pays, et construire la récupération vous-même en utilisant les embeddings du hub, les vecteurs dans Managed PostgreSQL et le corpus dans Object Storage. C Utiliser l'inférence gérée, mais acheminer les requêtes vers une région des États-Unis pour la capacité, en acceptant que le caractère sans état compense le fait que les données quittent le pays. D Héberger le modèle vous-même et répliquer le magasin de vecteurs géré entre les régions afin que la récupération survive à une panne régionale.

6.

Un client déploie un modèle open source sur l'AI Model Hub et demande comment les responsabilités liées au règlement européen sur l'IA (EU AI Act) sont réparties, y compris dans le cas où IONOS CLOUD modifie un modèle, par exemple en le quantisant. Quelle répartition est correcte ?

A Le client est toujours le distributeur, IONOS CLOUD est toujours le fournisseur pour chaque modèle, et une modification telle que la quantisation ne modifie pas les obligations de l'une ou l'autre des parties. B IONOS CLOUD est le déployeur pour tous les modèles, le client est un simple utilisateur sans obligations, et une modification transfère les obligations sur l'auteur open source original du modèle. C Le client agit en tant que déployeur (ou en tant que fournisseur de son propre système d'IA) et est responsable de son propre évaluation des risques ; IONOS CLOUD est un distributeur ou un intermédiaire pour les modèles open source non modifiés, mais lorsque IONOS CLOUD modifie un modèle, par exemple par quantisation, il assume les obligations de transparence du fournisseur d'IA pour cette modification. D Les rôles sont sans importance, car le traitement dans le pays et le caractère sans état exemptent la plateforme et le client de l'EU AI Act dans son ensemble.