Questão de Arquitetura de Software — Sistemas Distribuídos — FGV 2026
Arquitetura de Software›Sistemas Distribuídos
Código
gp045391
Banca
FGV
Órgão
TJ-SC
Ano
2026
Cargo
Analista de Sistemas
Uma arquitetura utiliza: • aplicação primária on-premise; • réplica em nuvem atualizada continuamente; • mecanismo de failover por DNS, com troca automática deendpoint; e• pequeno atraso na propagação do DNS. Considerando esse cenário, é correto afirmar que essa arquitetura
Ausa redundância ativa-ativa com RPO e RTO nulos.
Badota uma estratégia híbrida com failover automático, sujeitaa pequenas janelas de indisponibilidade.
Ccaracteriza uma estratégia de Warm Site, cuja ativação doendpoint em nuvem exige intervenção na camada deaplicação.
Dimplementa tolerância a falhas, garantindo a persistência desessões de usuário durante o failover.
Eemprega replicação assíncrona, cujo RTO é limitadoexclusivamente pela largura de banda do link de sincronismo.
Revelar gabarito e comentário▾
GabaritoB — adota uma estratégia híbrida com failover automático, sujeita
a pequenas janelas de indisponibilidade.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Arquitetura híbrida com failover por DNS
Gabarito: letra B. A arquitetura descrita combina um ambiente on-premise (primário) com uma réplica em nuvem, utilizando failover automático via DNS, que introduz um pequeno atraso na propagação. Isso caracteriza uma estratégia híbrida com janelas de indisponibilidade reduzidas, mas não nulas.
A questão testa os conceitos de failover, replicação e métricas de continuidade (RPO/RTO). O cenário apresentado é típico de uma abordagem ativa-passiva com failover automático, onde a réplica em nuvem é atualizada continuamente (replicação síncrona ou assíncrona) e a troca de endpoint é gerenciada pelo DNS. O atraso na propagação do DNS gera uma pequena janela de indisponibilidade, o que invalida alternativas que preconizam RTO nulo ou tolerância a falhas sem perda de sessão.
Alternativa A — ❌ Incorreta
Afirma que a redundância é ativa-ativa e que RPO e RTO são nulos. Na arquitetura descrita, a réplica em nuvem não está ativa simultaneamente (é passiva, aguardando failover). Além disso, o atraso na propagação do DNS implica RTO > 0, e a replicação contínua pode ser assíncrona, gerando RPO > 0. Portanto, a afirmação é falsa.
Alternativa B — ✅ Correta ⟵ GABARITO
A combinação de primário on-premise com réplica em nuvem é híbrida. O failover automático via DNS, com pequeno atraso de propagação, cria uma janela de indisponibilidade (RTO não nulo), mas ainda assim aceitável para muitos cenários. A descrição se encaixa perfeitamente em uma estratégia de Disaster Recovery (DR) híbrida com failover automático.
Alternativa C — ❌ Incorreta
Uma estratégia de Warm Site geralmente requer intervenção manual ou scripts para ativar o endpoint, o que contrasta com o failover automático por DNS descrito. Além disso, a ativação em Warm Site costuma envolver a camada de infraestrutura, não necessariamente a de aplicação. Portanto, incorreta.
Alternativa D — ❌ Incorreta
Tolerância a falhas com persistência de sessões exigiria replicação de estado de sessão (por exemplo, via sticky sessions ou cache distribuído). O enunciado menciona apenas réplica de dados (atualização contínua), não de sessão. O failover por DNS não garante que as sessões em andamento sejam mantidas, pois o novo endpoint não possui o contexto da sessão.
Alternativa E — ❌ Incorreta
Embora a replicação possa ser assíncrona, o RTO não é limitado exclusivamente pela largura de banda. O tempo de failover inclui a detecção da falha, a atualização do DNS e a propagação — fatores que vão além da sincronização de dados. A largura de banda afeta o RPO (quantidade de dados perdidos), mas não o RTO isoladamente.
PEGA ESSA DICA!
Em questões sobre failover, identifique os regimes de replicação (síncrona/assíncrona) e os componentes que impactam RTO: tempo de detecção, decisão, propagação de DNS e inicialização do serviço. O RPO depende da frequência de sincronização.