CompTIA Cloud+ — Questões de prática e simulado

A idempotência garante que executar a mesma requisição de API várias vezes produz resultados idênticos, sem efeitos colaterais adicionais. Conforme a RFC 7231 S4.2.2, os métodos HTTP GET, PUT e DELETE são idempotentes por natureza, enquanto POST exige implementação explícita por meio de idempotency keys. Quando um cliente sofre um timeout, ele não tem como saber se o servidor processou a requisição. Sem idempotência, as tentativas de repetição correm o risco de duplicar operações (por exemplo, cobranças em dobro). A implementação normalmente envolve o cliente enviar uma idempotency key única; o servidor armazena o resultado e o devolve nas requisições duplicadas. Por que não as outras? A consistência eventual descreve um modelo de replicação de dados, não a segurança das requisições. O circuit breaking evita falhas em cascata interrompendo as chamadas a serviços com falha. O throttling de requisições limita a taxa de chamadas, mas não garante repetições seguras. Ref.: RFC 7231 S4.2.2; documentação de idempotência da API da Stripe; CompTIA Cloud+ CV0-004 Obj 3.3.

Um dos maiores desafios na migração para a nuvem é lidar com camadas de aplicação com estado. Quando os dados de sessão ficam na memória do servidor, os usuários precisam continuar chegando ao mesmo servidor (afinidade de sessão), o que limita a escalabilidade e coloca em risco a sessão de cada usuário se esse servidor falhar. A solução nativa de nuvem é externalizar o estado para um armazenamento compartilhado e distribuído, como Redis ou Memcached. Quando as sessões passam a ficar em um cache externo, os servidores de aplicação se tornam sem estado: qualquer servidor pode atender qualquer requisição, e servidores podem ser adicionados ou removidos livremente. Sticky sessions (afinidade de sessão) no balanceador de carga são uma solução paliativa que prende os usuários a servidores específicos. Elas permitem algum escalonamento horizontal, mas podem gerar distribuição desigual de carga, complicar as implantações e fazer com que a falha de um servidor cause a perda das sessões de todos os usuários presos a ele. Aumentar a memória é escalabilidade vertical, não um caminho para a escalabilidade horizontal. A conversão para WebSocket trata do tipo de conexão, não do gerenciamento de estado. Dica para a prova: uma migração “de com estado para sem estado” geralmente significa externalizar o estado para um cache distribuído.

Solucionar problemas de DHCP significa acompanhar a troca DISCOVER, OFFER, REQUEST, ACK e perguntar onde ela para. Nenhum OFFER significa que o DISCOVER nunca chegou ao servidor ou que o servidor optou por não responder. O primeiro caso decorre da configuração do relay, do roteamento ou de um firewall filtrando UDP 67/68. O segundo decorre de causas no lado do servidor, como ausência de escopo para a sub-rede, um pool esgotado ou uma política administrativa. Um OFFER seguido de um DHCPDECLINE do cliente aponta para um conflito de endereços, normalmente detectado por ARP. Um DHCPNAK aponta para um cliente pedindo um endereço que está errado para a rede atual ou cuja concessão expirou, normalmente depois de mudar de sub-rede. A etapa em que a conversa é interrompida localiza a falha.