Questão de Arquitetura de Software — Arquitetura de Software — CESPE / CEBRASPE 2026
Arquitetura de Software›Arquitetura de Software
Código
ce225577
Banca
CESPE / CEBRASPE
Órgão
IPAAM
Ano
2026
Nível
Superior
Cargo
Analista Ambiental – Especialidade: Análise de Sistemas
O IPAAM planeja modernizar sua plataforma de licenciamento ambiental eletrônico, adotando uma arquitetura de software que facilite a evolução de serviços, a integração com sistemas externos e o isolamento de falhas. A equipe de análise de sistemas avalia diferentes abordagens arquiteturais antes de definir o desenho final da solução.Na situação hipotética apresentada, a abordagem arquitetural mais adequada consiste em
Amicrosserviços por domínios em contêineres independentes e escaláveis.
Bmonolito em camadas com todos os módulos no mesmo processo.
Ccliente-servidor de duas camadas com banco de dados centralizado.
DMVC único que concentre regras de negócio e integrações externas.
Eserviços SOAP em barramento corporativo único para integração.
Revelar gabarito e comentário▾
GabaritoA — microsserviços por domínios em contêineres independentes e escaláveis.
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”.
Abordagem Arquitetural para Modernização de Plataforma de Licenciamento Ambiental
Gabarito: letra A. A arquitetura de microsserviços por domínios em contêineres independentes e escaláveis atende de forma mais adequada aos requisitos de evolução de serviços, integração com sistemas externos e isolamento de falhas – cada serviço é independente, pode ser desenvolvido, implantado e escalado separadamente, e uma falha em um serviço não derruba os demais.
A questão exige que o candidato relacione as características de cada estilo arquitetural com as necessidades do projeto. Vejamos cada alternativa:
Abordagem Arquitetural
Evolução de Serviços
Integração com Sistemas Externos
Isolamento de Falhas
Escalabilidade
A) Microsserviços por domínios em contêineres independentes
✅ Cada serviço evolui independentemente, sem impacto nos demais
✅ Expõe APIs leves (REST, gRPC) para integração flexível
✅ Falhas ficam restritas ao serviço afetado
✅ Cada serviço pode ser escalado separadamente
B) Monólito em camadas
❌ Qualquer alteração exige reimplantação completa
❌ Integração centralizada e rígida
❌ Um erro em qualquer módulo pode parar o sistema inteiro
❌ Escalabilidade apenas do sistema como um todo
C) Cliente-servidor de duas camadas
❌ Dificulta evolução separada de funcionalidades
❌ Pouco flexível para múltiplos sistemas externos
❌ Sem isolamento de serviços
❌ Escalabilidade granular inexistente
D) MVC único
❌ Repete problemas do monólito
❌ Concentra integrações em uma única aplicação
❌ Falta de isolamento de falhas
❌ Dificuldade de escalar partes específicas
E) Serviços SOAP em barramento corporativo
❌ Barramento (ESB) torna-se ponto de acoplamento
✅ Promove integração, mas com protocolo pesado
❌ Barramento é ponto central de falha
❌ Escalabilidade limitada pelo barramento
Arquitetura de software
1Monolítica
Monólito em camadas
MVC único
Cliente-servidor 2 camadas
2Distribuída
Microsserviços por domínio
Contêineres independentes
APIs leves (REST/gRPC)
Isolamento de falhas
Evolução independente
SOAP em barramento (ESB)
Ponto central de falha
Acoplamento rígido
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
Microsserviços organizados por domínio de negócio, executados em contêineres independentes, oferecem:
Evolução – cada serviço pode ser atualizado sem impacto nos demais.
Integração – expõem APIs leves (REST, gRPC) para sistemas externos.
Isolamento de falhas – falhas ficam restritas ao serviço afetado.
Essa é a abordagem moderna mais alinhada aos requisitos do enunciado.
Alternativa B — ❌ Incorreta
Monólito em camadas – todos os módulos no mesmo processo comprometem o isolamento de falhas (um erro em qualquer módulo pode parar o sistema inteiro) e a evolução independente de serviços. Qualquer alteração exige reimplantação completa.
Alternativa C — ❌ Incorreta
Cliente-servidor de duas camadas – a lógica de negócio fica no servidor ou no cliente, dificultando a evolução separada de funcionalidades. Não há isolamento de serviços nem escalabilidade granular. É uma arquitetura rígida e pouco adequada a sistemas modernos que integram múltiplos sistemas externos.
Alternativa D — ❌ Incorreta
MVC único – concentrar regras de negócio e integrações em uma única aplicação monolítica (ainda que organizada em modelo, visão e controle) repete os problemas do monólito: falta de isolamento de falhas, dificuldade de escalar partes específicas e complexidade elevada para evolução.
Alternativa E — ❌ Incorreta
Serviços SOAP em barramento corporativo único – embora promova integração, o barramento (ESB) torna-se um ponto central de falha e de acoplamento. Além disso, SOAP é um protocolo pesado comparado a abordagens mais leves (REST, gRPC) comuns em microsserviços. A evolução independente é prejudicada pela dependência do barramento.
PEGA ESSA DICA!
Para identificar a arquitetura mais adequada em questões como esta, relacione os requisitos do enunciado (evolução, integração, isolamento) com os benefícios de cada estilo. Microsserviços são a resposta sempre que a pergunta exigir independência, escalabilidade e resiliência.