6.7 Verificación de conocimientos - Contenedores y Plataforma de Inteligencia Artificial

1.

Un equipo que migra un nivel web de acceso público a un Managed Kubernetes público Cluster declara un Servicio de tipo LoadBalancer y asume que ahora tiene un equilibrio de carga externo de alta disponibilidad, que preserva la dirección IP de origen, equivalente al Managed Network Load Balancer utilizado en otras partes de la propiedad. El arquitecto se opone. ¿Por qué esta suposición es incorrecta y cuál es la forma correcta de dar acceso al Workload?

A Un Servicio LoadBalancer no es un equilibrio de carga externo gestionado; IONOS reserva una dirección IP pública estática y la asigna como una dirección IP secundaria a un solo trabajador Node que actúa como el ingreso Node, por lo que el ingreso de producción debe ser un equilibrio de carga Load Balancer provisionado por separado, más un controlador de ingreso en Cluster. B Un Servicio LoadBalancer es un equilibrio de carga L4 completamente gestionado, pero solo se vuelve de alta disponibilidad una vez que al menos tres nodos están en el grupo, por lo que la solución es simplemente escalar el grupo de Node a tres. C El tipo de Servicio funciona como se espera; la única corrección necesaria es establecer externalTrafficPolicy: Cluster para que el tráfico se equilibre automáticamente en cada Node. D El manifiesto Cluster auto-provisiona un Managed Network Load Balancer en segundo plano, por lo que el equipo debe eliminar el Servicio explícito y dejar que el controlador lo cree.

2.

Un equipo consciente del costo que ejecuta trabajos por lotes en un Managed Kubernetes Cluster quiere que el grupo de Node se reduzca a cero nodos durante la noche cuando no se ejecutan trabajos, y también quiere que los eventos del plano de control de Cluster fluyan hacia el Logging Service centralizado junto con los registros de la aplicación. El arquitecto explica que ambas expectativas chocan con los límites de la plataforma. ¿Cuál de las siguientes afirmaciones describe correctamente esos límites?

A Node Pools puede escalarse a cero, y los eventos del plano de control se entregan al Logging Service de forma predeterminada una vez que se crea el Cluster. B Node Pools puede escalarse a cero solo en clusters privados, mientras que los eventos del plano de control llegan al Logging Service solo en clusters públicos. C El escalado automático de Cluster tiene un piso de un Node caliente y no puede escalarse a cero, y los eventos del plano de control no llegan al Logging Service, por lo que el equipo debe diseñar alrededor de un Node siempre activo y obtener la visibilidad del plano de control de otra manera. D Node Pools puede escalarse a cero si se deshabilita primero el análisis de vulnerabilidades, y los eventos del plano de control llegan al Logging Service una vez que se habilita la registrazione de auditoría en S3.

3.

Un arquitecto está diseñando un Managed Kubernetes Cluster privado para un Workload regulado y enumera los requisitos previos. La construcción es para un Cluster privado cuyo plano de datos debe estar aislado, cuyo servidor API debe permanecer accesible solo para el equipo de operaciones, y cuyos nodos deben comunicarse a través de un segundo VDC. ¿Cuál es el conjunto de decisiones correctas?

A Los clústeres privados aíslan el punto de conexión API en sí, por lo que no se necesita una lista de permitidos; el tráfico de salida y el tráfico entre VDC funcionan sin recursos de red adicionales. B Proporcionar una puerta de enlace NAT y Cross-Connect después de que Cluster esté en funcionamiento, y confiar en un grupo de seguridad vinculado al objeto Cluster para restringir el servidor API. C Elegir el tipo de grupo Node de manera flexible, ya que se puede cambiar más adelante, y proteger el servidor API colocando el plano de control en una región de EE. UU. para la redundancia. D Un Cluster privado aísla el plano de datos pero no el punto de conexión API, por lo que proteger el servidor API con una lista de permitidos IP; proporcionar la puerta de enlace NAT para el tráfico de salida y Cross-Connect para el tráfico Node entre VDC primero; mantener el plano de control en la región para la soberanía y fijar el tipo de grupo Node de antemano porque es inmutable después de la creación.

4.

Un equipo de plataforma quiere gobernar el acceso a su Registro de Contenedores de la misma manera que gobierna sus cuentas en la nube, definiendo roles como desarrollador de solo lectura, pipeline-pusher y administrador, y vinculando usuarios y grupos humanos a esos roles. También quieren un nivel de extracción pública anónima para imágenes de código abierto. El arquitecto explica que el registro no funciona de esa manera. ¿Cuál es el modelo de gobernanza correcto?

A El registro admite roles RBAC vinculados a usuarios y grupos, pero un nivel de extracción pública debe habilitarse por separado para cada repositorio. B La gobernanza se maneja deshabilitando tokens cuando una etapa de pipeline se retira, y hay un nivel de extracción pública disponible para imágenes marcadas como de código abierto. C El registro hereda automáticamente los roles IAM de la cuenta en la nube, por lo que las vinculaciones de roles existentes se aplican sin configuración adicional. D El registro no tiene RBAC; el acceso es solo mediante token, por lo que la gobernanza proviene de la disciplina de tokens (un token con alcance limitado por etapa de pipeline con caducidad, rotado regularmente y eliminado en lugar de deshabilitado), y no hay un nivel de extracción pública.

5.

Una empresa quiere agregar inteligencia artificial generativa a una aplicación regulada en el país y debe mantener todo el procesamiento en Alemania, evitar ejecutar y parchear la infraestructura de GPU, y integrar utilizando sus bibliotecas de cliente de OpenAI existentes. También necesita recuperación sobre un corpus privado. ¿Qué enfoque se adapta a la plataforma empresarial predeterminada y a su dirección actual?

A Autohospedar un modelo de código abierto en un grupo de Node de GPU desde el primer día para controlar, y almacenar el corpus de recuperación en la función de vector-store administrada de la plataforma de inteligencia artificial. B Utilizar inferencia administrada en el AI Model Hub a través de su API compatible con OpenAI con precios por token y procesamiento estatal e in-country, y construir la recuperación usted mismo utilizando incrustaciones de hub, vectores en Managed PostgreSQL y el corpus en Object Storage. C Utilizar inferencia administrada pero enrutar solicitudes a una región de EE. UU. para capacidad, aceptando que la estatalidad compensa la salida de datos del país. D Autohospedar el modelo y replicar el almacenamiento de vector administrado en regiones para que la recuperación sobreviva a una interrupción regional.

6.

Un cliente despliega un modelo de código abierto en el AI Model Hub y pregunta cómo se asignan las responsabilidades de la Ley de IA de la UE, incluyendo el caso en el que IONOS modifica un modelo, por ejemplo, cuantizándolo. ¿Cuál es la asignación correcta?

A El cliente siempre es el distribuidor, IONOS siempre es el proveedor de cada modelo, y la modificación, como la cuantización, no cambia las obligaciones de ninguna de las partes. B IONOS es el desplegado para todos los modelos, el cliente es un mero usuario sin obligaciones, y la modificación transfiere las obligaciones al autor original del modelo de código abierto. C El cliente actúa como desplegado (o como proveedor de su propio sistema de IA) y es propietario de su propia evaluación de riesgos; IONOS es un distribuidor o intermediario para modelos de código abierto no modificados, pero cuando IONOS modifica un modelo, como la cuantización, asume las obligaciones de transparencia del proveedor de IA para esa modificación. D Los roles son irrelevantes porque el procesamiento en el país y la falta de estado eximen a la plataforma y al cliente de la Ley de IA de la UE por completo.