Verificación de conocimientos - Arquitectura de mejores prácticas
Un nivel de FinCorp debe escalarse automáticamente bajo una carga variable. Un arquitecto configura un grupo VM Auto Scaling con un umbral de escalado horizontal en 70% CPU y un umbral de escalado vertical en 50% CPU, esperando que la banda de 20 puntos mantenga estable el grupo. La plataforma rechaza la política. ¿Qué regla se ha violado y cuál es el principio de diseño correcto?
VM Auto Scaling establece una separación mínima obligatoria de 40 puntos porcentuales entre los umbrales de escalado vertical y horizontal. Esta banda muerta es el control principal anti-flapping: sin ella, una lectura ruidosa podría cruzar ambos umbrales en rápida sucesión y hacer que el grupo se escale hacia arriba y luego hacia abajo de inmediato. Una brecha de 20 puntos está por debajo del piso y es rechazada. El servicio admite cinco métricas (utilización promedio 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 escalado horizontal está correctamente por encima del umbral de escalado vertical.
Un arquitecto ha producido un diseño funcionalmente completo para el procesamiento regulado de FinCorp en contenedores, ejecutándolo en Managed Kubernetes, y ahora aplica el filtro de soberanía y acreditación. El contrato Workload requiere contractualmente la 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 acreditación requerido. El filtro se aplica al final, sobre un diseño que ya es funcionalmente completo, porque el cumplimiento normativo reduce las opciones en lugar de originarlas. C5 cubre exactamente Compute Engine, Cloud Cubes y Object Storage; Managed Kubernetes se encuentra en el alcance de IT-Grundschutz pero no en C5, y los dos alcances no son intercambiables. Un Workload que requiere contractualmente C5 se mueve, por lo tanto, a un servicio cubierto por C5, como Compute Engine. La elección no estaba técnicamente mal; estaba mal en relación con el filtro de alcance, y una acreditación mantenida nunca licencia una afirmación de plataforma general.
En la arquitectura de referencia, la ruta de solicitud se divide intencionalmente en capas: un equilibrador público en el borde y un equilibrador privado frente al nivel de datos. Un ingeniero propone un solo equilibrador NLB de capa 4 en ambas posiciones para estandarizar, y propone envolver cada equilibrador gestionado en un Grupo de Seguridad de Red para filtrar. ¿Por qué el diseño de referencia rechaza ambas propuestas?
Las dos altitudes del equilibrador existen por dos razones diferentes. El equilibrador ALB de capa 7 público termina TLS y enruta en contenido donde la lógica de enrutamiento es importante; el equilibrador NLB de capa 4 privado pasa TCP rápidamente donde no es necesario, dejando el certificado en el backend. Estandarizar en una capa descarta la razón por la que cada uno fue elegido. Por separado, ningún equilibrador gestionado acepta un Grupo de Seguridad de Red o una lista de permitidos de IP, por lo que adjuntar un NSG a un equilibrador gestionado no hace nada; el filtrado pertenece a las tarjetas NIC de destino, y la seguridad del nivel de datos proviene de vivir en una LAN privada en lugar de un equilibrador de nivel Firewall. DNS dirige nuevas conexiones pero no es un Load Balancer y no aplica NSG, y Cloud DNS no tiene un conmutación de falla basada en comprobación de salud nativa.
La construcción de la piedra angular combina las piezas de cada módulo en un VDC. Un equipo proporciona recursos en este orden: crean el NLB de capa 4 privado, luego los servidores de nivel de datos que debe servir, luego una API Gateway, y esperan que las cargas de trabajo privadas lleguen a Internet tan pronto como exista la API Gateway. ¿Cuál es la evaluación correcta de su secuencia?
Una construcción integrada es un gráfico de dependencias resuelto de abajo hacia arriba, no una lista de verificación que la plataforma reordena. Un NLB de capa 4 que apunta a objetivos que no existen aún no tiene nada que enrutrar, por lo que los servidores de nivel de datos deben provisionarse antes de que se cree el NLB. La API Gateway, incluso con una dirección pública reservada y una regla SNAT, no produce salida hasta que la ruta predeterminada de la instancia 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 hace automáticamente. El orden correcto en toda la construcción es sustrato de red, luego cómputo, luego el nivel de datos, luego los equilibradores de carga, luego la plataforma de contenedores, 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. ¿Cuál de las siguientes afirmaciones refleja la asignación de cumplimiento correcta servicio por servicio?
El cumplimiento en IONOS está limitado por servicio y por ubicación de centro de datos alemán, nunca a nivel 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 (un atestiguo de tipo 1) cubre exactamente Compute Engine, Cloud Cubes y Object Storage. IT-Grundschutz (un certificado ISO 27001) cubre exactamente Compute Engine, Object Storage, Copia de seguridad y Managed Kubernetes. Los dos alcances divergen: Cubes están en C5 pero no en IT-Grundschutz, mientras que Managed Kubernetes y Copia de seguridad están en IT-Grundschutz pero no en C5. Los motores relacional y de caché y los equilibradores administrados no están en ninguno, y el núcleo dedicado regulado VMware está limitado a sus propias atestaciones en lugar de a la atestación de plataforma C5.