1
Una aplicación fue movida a una máquina virtual cloud, pero guarda archivos, logs y configuración crítica en el disco local del servidor. ¿Cuál es el diagnóstico más preciso?
2
¿Qué decisión refleja mejor un diseño stateless para la capa de aplicación?
3
Una base de datos usada por una aplicación cloud mantiene información crítica. ¿Qué tratamiento conceptual corresponde?
4
¿Por qué conviene separar código y configuración en una aplicación preparada para cloud?
5
Una API key está escrita dentro del repositorio de la aplicación. ¿Cuál es el principal problema?
6
¿Qué riesgo aparece si una aplicación solo guarda logs en el disco local de la instancia?
7
¿Cuál diferencia es más correcta entre health check y readiness check?
8
¿Cuál es el objetivo más importante de separar desarrollo, prueba y producción?
9
En un despliegue moderno, ¿por qué el rollback debe planificarse antes de publicar una nueva versión?
10
¿Cuál afirmación evita una confusión común sobre Cloud Native?
11
¿Qué diferencia mejor una página web de una API?
12
En una solicitud `POST /v1/solicitudes` con body JSON de una nueva atención, ¿qué intención representa mejor el método?
13
Una API responde 403 a un cliente que sí envió token válido. ¿Cuál interpretación es más precisa?
14
En un body JSON con RUT, nombre, correo y documento_id, ¿qué análisis es más adecuado?
15
¿Qué relación describe mejor header y body en una solicitud API?
16
¿Por qué un token pegado en un chat público representa un riesgo alto?
17
¿Cuál diferencia mejor una consulta API tradicional de un webhook?
18
¿Qué es un endpoint dentro de una API?
19
Una aplicación Cloud Native consume una API externa usando un token. ¿Dónde debería gestionarse ese token conceptualmente?
20
Si una solicitud POST envía JSON sin un campo obligatorio como `correo`, ¿qué respuesta sería más esperable?
21
Una aplicación está encendida, pero no puede conectarse a la API de autenticación que necesita para atender usuarios. ¿Qué chequeo debería reflejar ese problema?
22
¿Qué práctica combina mejor observabilidad y seguridad al registrar una integración API?
23
Una aplicación guarda respuestas JSON con datos personales en archivos locales de cada instancia. ¿Qué problema combina mejor Cloud Native y APIs?
24
Después de desplegar una nueva versión, las llamadas a una API comienzan a devolver 500. ¿Cuál acción es más madura?
Explicación
La aplicación cambió de ubicación, pero no de diseño. Sigue dependiendo del servidor local para archivos, logs y configuración, lo que dificulta escalar, reemplazar o recuperar la instancia.
Un componente stateless atiende solicitudes sin depender de datos críticos locales. Por eso puede duplicarse, reiniciarse o reemplazarse con menor impacto.
Una base de datos mantiene estado y datos importantes. Por eso requiere persistencia, respaldo, control de acceso, recuperación y continuidad operacional.
La separación permite que la misma aplicación opere en desarrollo, prueba y producción cambiando valores externos, sin reescribir ni recompilar el código principal.
Una API key o token funciona como credencial. Si queda en un repositorio, puede copiarse, reutilizarse y permitir solicitudes no autorizadas según sus permisos.
En cloud, las instancias pueden reiniciarse o reemplazarse. Si los logs quedan solo localmente, se pierde visibilidad para diagnóstico, auditoría y soporte.
Un health check indica si la aplicación está viva o sana. Un readiness check indica si está lista para recibir solicitudes reales, por ejemplo si ya cargó configuración y dependencias.
La separación de ambientes permite construir, probar y validar antes de afectar la operación real. Reduce errores, impactos sobre usuarios y exposición de datos productivos.
El rollback reduce impacto cuando una versión nueva genera fallas. Debe estar definido antes del incidente, porque durante una caída hay presión y poco tiempo.
Cloud Native se relaciona con diseño para escalabilidad, observabilidad, configuración externa, resiliencia y despliegue controlado. Puede adoptarse gradualmente.
La página web entrega una interfaz visual a personas. La API permite que sistemas intercambien datos o ejecuten acciones mediante reglas como endpoint, método, headers, body y response.
POST se usa normalmente para enviar datos o crear un nuevo recurso. En este caso, apunta a registrar una solicitud nueva.
403 Forbidden indica que la solicitud está prohibida por falta de autorización. Puede existir autenticación, pero el permiso no alcanza para esa acción.
JSON es un formato de datos; puede transportar información personal o sensible. RUT, nombre, correo e identificadores deben manejarse con resguardo.
Los headers transportan información de control, formato, autenticación o trazabilidad. El body contiene los datos principales cuando la solicitud lo requiere.
Un token funciona como credencial. Si se expone, otra persona o sistema podría realizar solicitudes con los permisos que tenga ese token.
En una consulta, un sistema pregunta cuando necesita información. En un webhook, otro sistema envía un aviso automático al ocurrir un evento.
El endpoint es la dirección concreta a la que se envía la solicitud para operar sobre un recurso o acción de la API.
El token debe tratarse como secreto: separado del código, protegido, restringido por permisos y rotado cuando corresponda.
Cuando faltan datos requeridos o el JSON no cumple lo esperado, corresponde un error del cliente como 400 Bad Request.
Aunque el proceso esté vivo, si falta una dependencia crítica la aplicación no está lista para atender. Readiness debe evitar enviarle tráfico real.
Los logs deben ayudar al diagnóstico y auditoría, pero sin revelar secretos, tokens, contraseñas o datos personales innecesarios.
Guardar datos personales en discos locales de instancias aumenta riesgo de pérdida al reemplazarlas, dificultad de respaldo y posible exposición de información sensible.
Un error 500 indica falla interna del servidor o servicio. Ante impacto productivo, corresponde usar el plan de rollback si existe y analizar logs, métricas y trazas.
|
Tissues - Practice Quiz
Test your knowledge about the 5 seeing habits discussed in the text 'UPS 5 seeing habits'.