Verificación de conocimientos - Gobernanza, identidad y costos
FinCorp desea separar su entorno no productivo del entorno productivo únicamente para que cada uno aparezca como su propia línea en la factura mensual, manteniendo un solo ámbito de gobernanza y auditoría. Se le pregunta al arquitecto si esto requiere un segundo contrato. ¿Cuál es la orientación correcta?
Un VDC es la primitiva de segmentación regional y por entorno dentro de un contrato, y cada VDC ya genera su propia sección en la factura mensual. Por lo tanto, la visibilidad de costos por sí sola no justifica un segundo contrato, que es el límite comercial, de gobernanza y de auditoría. Un nuevo contrato solo está justificado para el aislamiento por cumplimiento, un propietario o entidad legal diferente, o un alcance de auditoría separado.
Un arquitecto asigna el primer VDC regulado de FinCorp a una región en Alemania y más tarde se da cuenta de que otra región alemana habría sido preferible. ¿Cuál es la realidad de cambiarla?
La región de un VDC se fija en el momento de la creación. Los bloques de IPv4 reservados solo son utilizables en la región donde se reservaron, y las imágenes y las instantáneas son locales a la región, sin replicación entre regiones gestionada. Dado que estos atributos vinculados a la región no pueden seguir al VDC a otro lugar, la región (y el nombre) es una decisión de un solo sentido, por lo que la ubicación se define deliberadamente y una sola vez.
Un auditor de FinCorp necesita revisar la actividad, pero no debe poder modificar ninguna infraestructura. La plataforma no tiene ninguna regla de denegación. ¿Cómo debería el arquitecto otorgar este acceso?
El acceso se basa en grupos, con los derechos de capacidad y las concesiones de recursos mantenidos por separado. La lectura es implícita cuando se otorga un recurso, y no existe ninguna regla de denegación. Por lo tanto, el principio de privilegio mínimo se logra otorgando únicamente lo que el rol necesita: la capacidad de Acceso al registro de actividad y concesiones de recursos de nivel de lectura. Una concesión demasiado amplia no puede corregirse mediante una excepción, ya que no existe ninguna regla de denegación; habría que eliminarla y volver a delimitarla.
FinCorp opera un proveedor de identidad corporativo y desea federar el acceso a IONOS CLOUD para que los nuevos empleados se creen y se les asignen grupos automáticamente en el primer inicio de sesión. ¿Qué debe indicar el arquitecto al equipo?
La federación de IONOS CLOUD admite SAML 2.0 y OIDC, pero su alcance actual es solo de autenticación. No existe aprovisionamiento just-in-time (el usuario debe existir previamente) y el IdP no controla la membresía en grupos de IONOS CLOUD (la asociación de acceso está en la hoja de ruta, pero no está disponible). La federación verifica la identidad de la persona; el modelo de grupos y permisos sigue determinando lo que pueden hacer, por lo que el ciclo de vida es un procedimiento manual explícito.
FinCorp ejecutará una línea base estable de cómputo de núcleos dedicados durante al menos tres años, pero espera picos ocasionales muy superiores a dicha línea base. El arquitecto está dimensionando un Savings Plan. ¿Qué enfoque es correcto?
Un Savings Plan es un compromiso basado en recursos con un descuento del 15% a 1 año y del 40% a 3 años para núcleos dedicados y RAM. El uso que excede la cantidad comprometida se factura a la tarifa estándar de pago por uso (PAYG) (el exceso no se rechaza), y el plan no puede editarse después de su activación ni cancelarse. La disciplina segura es comprometer únicamente el piso que se tiene certeza de ejecutar durante el plazo y dejar los picos variables en el flexible pago por uso (PAYG), en lugar de fijar un gasto pico optimista que no puede reducirse posteriormente.