CompTIA Cloud+ — Preguntas de práctica y simulacro de examen

La idempotencia garantiza que ejecutar la misma solicitud a la API varias veces produce resultados idénticos sin efectos secundarios adicionales. Según el RFC 7231 S4.2.2, los métodos HTTP GET, PUT y DELETE son idempotentes por naturaleza, mientras que POST requiere una implementación explícita mediante idempotency keys. Cuando un cliente sufre un timeout, no puede determinar si el servidor procesó la solicitud. Sin idempotencia, los reintentos corren el riesgo de duplicar operaciones (por ejemplo, cobros dobles). La implementación suele consistir en que el cliente envía una idempotency key única; el servidor guarda el resultado y lo devuelve ante solicitudes duplicadas. ¿Por qué no las otras? La consistencia eventual describe un modelo de replicación de datos, no la seguridad de las solicitudes. El circuit breaking evita fallos en cascada al detener las llamadas a servicios que fallan. El throttling de solicitudes limita la tasa de llamadas pero no garantiza reintentos seguros. Ref: RFC 7231 S4.2.2; documentación de idempotencia de la API de Stripe; CompTIA Cloud+ CV0-004 Obj 3.3.

Uno de los mayores desafíos de una migración a la nube es manejar capas de aplicación con estado. Cuando los datos de sesión viven en la memoria del servidor, los usuarios deben seguir llegando al mismo servidor (afinidad de sesión), lo que limita el escalado y pone en riesgo la sesión de cada usuario si ese servidor falla. La solución nativa de la nube es externalizar el estado a un almacén compartido y distribuido como Redis o Memcached. Una vez que las sesiones viven en una caché externa, los servidores de aplicaciones pasan a ser sin estado: cualquier servidor puede atender cualquier solicitud y se pueden agregar o quitar servidores libremente. Las sticky sessions (afinidad de sesión) en el balanceador de carga son una solución alternativa que fija a los usuarios a servidores específicos. Permiten cierto escalado horizontal, pero pueden generar una distribución desigual de la carga, complicar los despliegues y hacer que la falla de un servidor provoque la pérdida de las sesiones de todos los usuarios fijados a él. Aumentar la memoria es escalado vertical, no un camino hacia la escalabilidad horizontal. Convertir a WebSocket aborda el tipo de conexión, no la gestión del estado. Consejo para el examen: una migración “de con estado a sin estado” suele implicar externalizar el estado a una caché distribuida.

Diagnosticar problemas de DHCP implica seguir el intercambio DISCOVER, OFFER, REQUEST, ACK y preguntarse dónde se detiene. Si no llega ningún OFFER, o bien el DISCOVER nunca llegó al servidor, o bien el servidor decidió no responder. El primer caso se debe a la configuración del relay, al enrutamiento o a un firewall que filtra UDP 67/68. El segundo se debe a causas del lado del servidor, como la falta de un ámbito para la subred, un pool agotado o una política administrativa. Un OFFER seguido de un DHCPDECLINE del cliente apunta a un conflicto de direcciones, normalmente detectado mediante ARP. Un DHCPNAK apunta a un cliente que solicita una dirección incorrecta para su red actual o cuya concesión expiró, normalmente después de moverse entre subredes. La etapa en la que se interrumpe la conversación permite localizar la falla.