1
Una organización crea una máquina virtual, una base de datos y almacenamiento en cloud. ¿Qué condición permite afirmar que eso ya es una arquitectura cloud y no solo recursos sueltos?
2
Un sistema tiene RTO de 2 horas y RPO de 15 minutos. ¿Qué decisión se alinea mejor con esos objetivos?
3
Un portal productivo debe tolerar una falla localizada, pero no justifica el costo ni la complejidad de operar en varias regiones. ¿Qué diseño es más coherente?
4
¿Cuál es el error conceptual más grave al decir “tenemos respaldo, por lo tanto tenemos continuidad operacional”?
5
En un taller de diseño cloud, ¿por qué la elección del proveedor debe venir después de levantar la necesidad?
6
Una arquitectura tiene dos servidores web detrás de un balanceador, pero ambos dependen de una única base de datos sin réplica ni respaldo probado. ¿Qué riesgo persiste?
7
En una arquitectura para un sistema con usuarios externos y datos sensibles, ¿qué separación es más adecuada?
8
¿Qué función cumple mejor un health check asociado a un balanceador de carga?
9
Una plataforma recibe alta demanda solo algunos días al mes. ¿Qué enfoque responde mejor a capacidad y costo?
10
¿Cuál afirmación diferencia mejor monitoreo de una simple revisión manual ocasional?
11
Una organización propone multi-región para un sitio informativo de baja criticidad. ¿Cuál observación sería más sólida?
12
En una propuesta ejecutiva cloud, ¿qué contenido demuestra mejor madurez de diseño?
13
¿Qué decisión refleja mejor el principio de mínimo privilegio en una arquitectura cloud?
14
Un estudiante propone empezar el diseño por “crear una VM potente”. ¿Qué corrección conceptual es más adecuada?
15
¿Cuál alternativa expresa mejor la diferencia entre requerimiento funcional y no funcional?
16
Un sistema necesita publicar una aplicación nueva rápidamente y el equipo no quiere administrar sistemas operativos. ¿Qué modelo suele ser más coherente?
17
¿Qué frase explica mejor la responsabilidad compartida en cloud?
18
¿Qué riesgo se controla principalmente al documentar arquitectura, responsables, flujos y procedimientos?
19
En una solución con demanda variable, ¿cuál es el riesgo de automatizar escalamiento sin límites ni alertas?
20
¿Cuál sería una señal clara de que un diagrama cloud no está suficientemente entendido?
21
¿Qué decisión es más coherente si un sistema interno crítico necesita consultar servicios locales y mantener parte de sus datos en la institución?
22
¿Por qué declarar riesgos en una propuesta cloud fortalece la evaluación del estudiante?
23
¿Qué opción describe mejor una arquitectura “proporcional” al caso?
24
Un estudiante propone que la base de datos sea privada, con acceso solo desde la aplicación, respaldos probados y monitoreo. ¿Qué principio integra mejor esa decisión?
Explicación
La arquitectura aparece cuando los recursos trabajan como un sistema coherente: tienen flujos definidos, controles, monitoreo, respaldo y recuperación. No basta con que existan recursos; deben estar diseñados para operar y resistir fallas.
RTO indica el tiempo máximo aceptable para volver a operar y RPO indica la pérdida máxima de información. La única opción que cubre ambos exige recuperación probada antes de 2 horas y una estrategia que no pierda más de 15 minutos de datos.
La arquitectura multi-zona permite reducir el impacto de fallas locales sin llegar al costo y complejidad de operar en varias regiones. Es una decisión proporcional para servicios productivos que requieren resiliencia intermedia.
El respaldo es solo una copia. La continuidad requiere procedimiento, responsables, pruebas, restauración dentro del tiempo definido y validación de que el servicio vuelve a operar.
Primero se entiende el problema: quién usará el servicio, qué datos manejará, qué disponibilidad requiere y qué riesgos existen. Recién después se selecciona el proveedor que mejor se ajusta a esos criterios.
Aunque la capa web tiene redundancia, la base de datos sigue siendo un componente único cuya caída podría detener todo el servicio. La alta disponibilidad debe revisar dependencias reales, no solo duplicar servidores.
La entrada puede ser pública porque los usuarios deben acceder al servicio, pero la aplicación interna y especialmente la base de datos deben quedar protegidas. Esto reduce exposición y ordena los flujos de comunicación.
Un health check verifica si una instancia está sana. Si falla, el balanceador puede dejar de dirigirle tráfico, mejorando disponibilidad y experiencia del usuario.
La elasticidad permite aumentar recursos cuando la demanda sube y reducirlos cuando baja. Para evitar costos inesperados, debe acompañarse de reglas, límites, monitoreo y alertas.
El monitoreo entrega visibilidad continua sobre salud, errores, disponibilidad, rendimiento, eventos y consumo. Permite detectar problemas antes de que escalen o antes de que los usuarios sean los primeros en avisar.
Multi-región aumenta resiliencia, pero también complejidad, sincronización, gobierno y costo. En sistemas de baja criticidad puede ser excesivo si no existe una razón clara.
Una propuesta madura conecta la necesidad con decisiones justificadas y explica cómo se protege, monitorea, recupera y costea la solución. La claridad y la proporcionalidad son tan importantes como la tecnología.
Mínimo privilegio significa entregar únicamente los permisos necesarios, reduciendo superficie de abuso o error. Aplica tanto a usuarios como a servicios, aplicaciones y cuentas administrativas.
El diseño debe comenzar por el problema y los requisitos. Una VM puede ser adecuada en algunos casos, pero no debe elegirse antes de entender necesidad, riesgos y responsabilidades.
El requerimiento funcional describe acciones del sistema, como registrar solicitudes o publicar documentos. El no funcional define condiciones como disponibilidad, seguridad, rendimiento, respaldo y continuidad.
PaaS suele ser adecuado cuando se quiere desplegar una aplicación sin administrar con detalle servidores y sistemas operativos. Permite concentrarse más en el código, configuración de la aplicación y operación funcional.
Cloud no delega todo. El proveedor opera y protege ciertas capas, pero la organización sigue siendo responsable de decisiones, configuraciones, accesos, datos, monitoreo, respaldos y gobierno de su entorno.
La documentación reduce dependencia de conocimiento tácito y permite operar, auditar, mantener y recuperar la arquitectura con mayor orden. También facilita cambios y continuidad ante ausencia de personal clave.
La elasticidad mal controlada puede aumentar recursos para responder a demanda, pero elevar el gasto sin visibilidad. Por eso debe acompañarse de alertas, presupuestos, límites y revisión de consumo.
Una arquitectura debe poder explicarse como un recorrido: usuario, entrada, aplicación, datos, seguridad, monitoreo y recuperación. Si no se puede narrar, probablemente solo hay cajas dibujadas sin comprensión funcional.
Una arquitectura híbrida permite combinar servicios cloud con sistemas locales, siempre que exista conectividad segura, segmentación, control de accesos, monitoreo y continuidad. Es coherente cuando no todo puede moverse a cloud.
Identificar riesgos muestra que el estudiante entiende exposición, continuidad, costos y operación. La propuesta mejora cuando cada riesgo se acompaña de una mitigación razonable.
Una arquitectura proporcional no es la más cara ni la más compleja; es la que responde al riesgo real y puede operarse de manera sostenible. Debe justificar sus decisiones según la necesidad.
La decisión protege datos, limita accesos, permite recuperación y agrega visibilidad operacional. Integra seguridad y continuidad desde la arquitectura, no como anexos posteriores.
|
