Verificación de conocimientos - Arquitectura de mejores prácticas
Un nivel de FinCorp debe escalar automáticamente bajo carga variable. Un arquitecto configura un grupo de VM Auto Scaling con un umbral de escala hacia afuera en el 70% de CPU y un umbral de escala hacia adentro en el 50% de CPU, esperando que la banda de 20 puntos mantenga el grupo estable. La plataforma rechaza la política. ¿Qué regla se ha violado y cuál es el principio de diseño correcto?
VM Auto Scaling aplica una separación mínima obligatoria de 40 puntos porcentuales entre los umbrales de escala hacia adentro y hacia afuera. Esta banda muerta es el control principal contra el parpadeo: sin ella, una lectura ruidosa podría cruzar ambos umbrales en rápida sucesión y provocar que el grupo escale hacia afuera y luego inmediatamente hacia adentro. Una diferencia de 20 puntos está por debajo del límite mínimo y se rechaza. El servicio admite cinco métricas (promedio de utilización de CPU y bytes y paquetes de red entrantes y salientes), por lo que la elección de la métrica no es el problema, y el umbral de escala hacia afuera está correctamente por encima del umbral de escala hacia adentro.
Un arquitecto ha elaborado un diseño funcionalmente completo para el procesamiento en contenedores regulado de FinCorp, ejecutándolo en Managed Kubernetes, y ahora aplica el filtro de soberanía y atestación. El contrato de la carga de trabajo exige cobertura de BSI C5. ¿Qué revela el filtro y cuál es la conclusión correcta?
Este es el segundo error de composición: una elección funcionalmente correcta colocada fuera del alcance de atestación requerido. El filtro se aplica al final, sobre un diseño que ya es funcionalmente completo, porque el cumplimiento restringe las opciones en lugar de originarlas. C5 cubre exactamente Compute Engine, Cloud Cubes y Object Storage; Managed Kubernetes se encuentra dentro del alcance de IT-Grundschutz pero no dentro de C5, y los dos alcances no son intercambiables. Una carga de trabajo que contractualmente requiere C5 debe, por lo tanto, migrarse a un servicio cubierto por C5, como Compute Engine. La elección no fue incorrecta técnicamente; fue incorrecta frente al filtro de alcance, y una atestación obtenida nunca autoriza una afirmación a nivel de plataforma.
En la arquitectura de referencia, la ruta de solicitud está deliberadamente estructurada en capas: un equilibrador público en el borde y un equilibrador privado delante de la capa de datos. Un ingeniero propone un único NLB de capa 4 en ambas posiciones para estandarizar, y propone encapsular cada equilibrador administrado en un Network Security Group para el filtrado. ¿Por qué el diseño de referencia rechaza ambas propuestas?
Los dos niveles de equilibradores existen por dos razones diferentes. El ALB de capa 7 público termina TLS y enruta según el contenido cuando la lógica de enrutamiento es relevante; el NLB de capa 4 privado transmite TCP rápidamente cuando no lo es, dejando el certificado en el servidor de origen. Estandarizar en una sola capa descarta la razón por la que se eligió cada una. Por separado, ningún equilibrador administrado acepta un Network Security Group ni una lista de permisos de IP, por lo que adjuntar un NSG a un equilibrador administrado no tiene efecto; el filtrado debe aplicarse en las NIC de los objetivos, y la seguridad de la capa de datos proviene de estar en una LAN privada, no de un firewall a nivel de equilibrador. DNS dirige nuevas conexiones, pero no es un equilibrador de carga y no aplica ningún NSG, y Cloud DNS no tiene conmutación por error nativa basada en verificación de estado.
La construcción de proyecto final integra las piezas de cada módulo en un solo VDC. Un equipo aprovisiona recursos en este orden: crean el NLB privado de capa 4, luego los servidores de la capa de datos que debe atender, después una NAT Gateway, y esperan que las cargas de trabajo privadas alcancen internet en cuanto exista la NAT Gateway. ¿Cuál es la evaluación correcta de su secuencia?
Una construcción integrada es un grafo de dependencias resuelto de abajo hacia arriba, no una lista de verificación que la plataforma reordena. Un NLB de capa 4 apuntado a destinos que aún no existen no tiene nada hacia donde enrutar, por lo que los servidores de la capa de datos deben aprovisionarse antes de crear el NLB. La NAT Gateway, incluso con una IP pública reservada y una regla SNAT, no produce salida hasta que la ruta predeterminada de la LAN privada (0.0.0.0/0) se redirija hacia ella; ese cambio de enrutamiento es el paso que los equipos olvidan, y la plataforma no lo realiza automáticamente. El orden correcto en toda la construcción es: sustrato de red, luego cómputo, luego la capa de datos, luego los balanceadores, luego la plataforma de contenedores, y luego el borde híbrido.
El auditor de FinCorp le pide al arquitecto que muestre, servicio por servicio, qué reconocimiento de BSI cubre cada componente del diseño desplegado. El arquitecto debe responder con precisión en lugar de afirmar que la plataforma está certificada. ¿Qué enunciado refleja el mapeo de cumplimiento servicio por servicio correcto?
El cumplimiento en IONOS CLOUD tiene un ámbito por servicio y por ubicación de centro de datos alemán, nunca de alcance de plataforma, por lo que la respuesta debe nombrar el servicio, la credencial y la ubicación en lugar de afirmar una certificación general. C5 (una atestación de Tipo 1) cubre exactamente Compute Engine, Cloud Cubes y Object Storage. IT-Grundschutz (un certificado ISO 27001) cubre exactamente Compute Engine, Object Storage, Backup y Managed Kubernetes. Los dos ámbitos divergen: Cubes están en C5 pero no en IT-Grundschutz, mientras que Managed Kubernetes y Backup están en IT-Grundschutz pero no en C5. Los motores relacionales y de caché y los equilibradores gestionados no están en ninguno de los dos, y el núcleo dedicado de VMware regulado tiene un ámbito propio para sus atestaciones, no para el C5 de la plataforma.