Arquitetura de Software · FGV · 2026 | Questão sqc-fg133947

Arquitetura de SoftwareSistemas Distribuídos

Código: fg133947
Banca: FGV
Órgão: TJ-RJ
Ano: 2026
Nível: Superior

Cargo: Analista Judiciário - Tecnologia da Informação - Arquiteto de Dados

Uma corte superior está redesenhando sua arquitetura de sistemas para suportar sistemas legados críticos ainda executados em data center próprio, novos serviços digitais com alta variabilidade de carga (portais, APIs abertas, painéis em tempo real), além de requisitos rígidos de conformidade, auditoria e soberania de dados.Na proposta inicial, a área de TI contrapõe duas abordagens de alto nível:• estratégia nativa (cloud-native), com serviços desenhados desde o início para consumir intensamente recursos de nuvem pública (contêineres orquestrados, funções serverless, filas e bancos gerenciados, observabilidade integrada etc.);• estratégia híbrida, em que parte significativa da carga permanece em data center próprio ou em nuvem privada, com integração estruturada (túneis seguros, VPN, direct connect, replicação de dados) com a nuvem pública.Considerando os trade-offs entre uma arquitetura nativa em nuvem e uma arquitetura híbrida nesse contexto, é correto afirmar que:

Aem uma arquitetura híbrida, a presença simultânea de ambientes on-premises e em nuvem tende a reduzir o risco de vendor lock-in, pois a possibilidade de distribuir cargas entre os dois lados torna menos relevante a escolha de serviços gerenciados específicos de cada provedor;
Bem uma arquitetura cloud-native em nuvem pública, é comum explorar serviços gerenciados e elasticidade para acelerar entregas e simplificar operação, enquanto a arquitetura híbrida tende a facilitar a convivência com sistemas legados e requisitos locais, aumentando, por outro lado, a complexidade de governança, a observabilidade fim a fim e a gestão de latência entre domínios;
Cem cenários com forte exigência de soberania de dados, concentrar todas as cargas em um único provedor de nuvem pública costuma ser mais adequado do que manter parte dos sistemas on-premises, pois a unificação da infraestrutura tende a simplificar o atendimento às restrições regulatórias;
Dem caso de adoção de uma arquitetura híbrida, limita-se de forma relevante o uso de práticas cloud-native, como contêineres, orquestração, infraestrutura como código e observabilidade distribuída, que apresentam melhor relação custo-benefício quando o ambiente está predominantemente na nuvem pública;
Eem uma arquitetura cloud-native bem desenhada, o uso de serviços serverless e bancos de dados gerenciados tende a atender grande parte das necessidades de auditoria, trilhas de acesso, criptografia e segmentação de redes, reduzindo a necessidade de controles adicionais de segurança em comparação a uma arquitetura híbrida baseada em data center próprio.

Revelar gabarito e comentário

GabaritoB — em uma arquitetura cloud-native em nuvem pública, é comum explorar serviços gerenciados e elasticidade para acelerar entregas e simplificar operação, enquanto a arquitetura híbrida tende a facilitar a convivência com sistemas legados e requisitos locais, aumentando, por outro lado, a complexidade de governança, a observabilidade fim a fim e a gestão de latência entre domínios;

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 Cloud-Native vs Híbrida

Gabarito: letra B. A alternativa B descreve com precisão os trade-offs: a arquitetura cloud-native em nuvem pública explora serviços gerenciados e elasticidade para acelerar entregas e simplificar a operação, enquanto a híbrida facilita a convivência com sistemas legados e requisitos locais, mas aumenta a complexidade de governança, observabilidade fim a fim e gestão de latência entre domínios. As demais alternativas apresentam distorções sobre vendor lock-in, soberania de dados, limitações de práticas cloud-native e necessidades de segurança.

Aspecto	Arquitetura Cloud-Native (Nuvem Pública)	Arquitetura Híbrida (On-Premises + Nuvem)
Benefícios principais	Acelera entregas, simplifica operação, explora elasticidade e serviços gerenciados	Facilita convivência com sistemas legados e requisitos locais (soberania, conformidade)
Complexidade de governança	Menor, pois o ambiente é unificado no provedor de nuvem	Maior, devido à gestão de múltiplos ambientes e políticas distintas
Observabilidade fim a fim	Mais simples, com ferramentas integradas do provedor	Mais complexa, exigindo soluções que cubram domínios on-premises e nuvem
Latência entre domínios	Baixa (intra-nuvem)	Potencialmente alta, exigindo túneis seguros, VPN ou Direct Connect
Vendor lock-in	Maior risco, devido ao uso intensivo de serviços gerenciados proprietários	Risco presente na parte em nuvem, mas mitigado pela parcela on-premises; integração pode aumentar dependência de soluções de conectividade
Soberania de dados	Mais difícil de atender, pois dados ficam sob controle do provedor	Mais adequada, permitindo manter dados sensíveis em data center próprio
Práticas cloud-native (contêineres, orquestração, IaC, observabilidade)	Totalmente aplicáveis e otimizadas para o ambiente	Aplicáveis, mas com complexidade adicional para integrar ambientes distintos; não são limitadas de forma relevante

Alternativa A — ❌ Incorreta

Afirma que a arquitetura híbrida reduz o risco de vendor lock-in ao tornar menos relevante a escolha de serviços gerenciados específicos. Na prática, a parte que utiliza a nuvem pública continua sujeita ao lock-in dos serviços contratados, e a integração entre ambientes pode até aumentar a dependência de soluções proprietárias de conectividade. A distribuição de cargas não elimina a importância da escolha do provedor; pelo contrário, a complexidade híbrida pode dificultar a migração futura. Portanto, a afirmação é equivocada.

Alternativa B — ✅ Correta ⟵ GABARITO

A alternativa captura corretamente os benefícios da abordagem cloud-native (agilidade, elasticidade, operação simplificada) e os desafios da híbrida (coexistência com legados, complexidade de governança, observabilidade e latência). É uma descrição balanceada e alinhada com as melhores práticas de arquitetura de sistemas distribuídos.

Alternativa C — ❌ Incorreta

Sugere que concentrar todas as cargas em um único provedor de nuvem pública é mais adequado para soberania de dados. Na realidade, requisitos rígidos de soberania e conformidade regulatória frequentemente exigem que dados sensíveis permaneçam em data centers próprios ou em nuvens privadas, sob controle direto da organização. A nuvem pública unificada dificulta atender restrições de residência de dados e auditoria local.

Alternativa D — ❌ Incorreta

Afirma que a arquitetura híbrida limita o uso de práticas cloud-native, como contêineres, orquestração, infraestrutura como código e observabilidade distribuída. Isso é falso: tais práticas podem ser aplicadas tanto em ambientes on-premises quanto em nuvem pública. Ferramentas como Kubernetes, Terraform e Prometheus funcionam de forma consistente em ambos os lados, e a adoção híbrida não as inviabiliza.

Alternativa E — ❌ Incorreta

Alega que serviços serverless e bancos gerenciados reduzem a necessidade de controles adicionais de segurança, como auditoria, trilhas, criptografia e segmentação. Na verdade, o modelo de responsabilidade compartilhada na nuvem transfere parte da segurança ao provedor, mas o cliente continua responsável pela configuração adequada desses controles. Auditoria, trilhas de acesso, criptografia e segmentação de redes permanecem essenciais e frequentemente exigem esforço adicional em comparação com ambientes tradicionais, não o contrário.

Gabarito: letra B.

Link permanente: /questoes/fg133947