Questão de Arquitetura de Software — Conceitos Básicos em Arquitetura de Software — IV - UFG 2026
Arquitetura de Software›Conceitos Básicos em Arquitetura de Software
Código
qg732567
Banca
IV - UFG
Órgão
UFSCAR
Ano
2026
Nível
Superior
Cargo
Analista de TI
Como parte do desenvolvimento e manutenção de um dado sistema de software, as equipes observam que até pequenas alterações em uma única funcionalidade exigem a reconstrução e reimplantação (re-deployment) de todo o artefato para colocá-lo em produção. Isso aumenta o esforço de coordenação entre equipes e eleva o risco de falhas não relacionadas durante as releases. Após redesenhar o sistema usando arquitetura de microsserviços, espera-se que o comportamento de implantação mude. Na nova arquitetura, a necessidade de as equipes coordenarem releases conjuntas de todo o sistema deve diminuir principalmente porque
Aos serviços individuais podem ser liberados como artefatos que podem ser implantados independentemente, sem exigir reconstrução ou rollout sincronizado do sistema completo.
Bo alinhamento de versões entre microsserviços garante que suas releases ocorram simultaneamente, evitando incompatibilidades entre componentes.
Ca arquitetura impõe uma estratégia fixa de rollout que padroniza a implantação em todos os ambientes onde o sistema deve ser implantado.
Do pipeline de implantação compartilhado garante que todos os microsserviços passem pelos mesmos estágios de release ao mesmo tempo.
Revelar gabarito e comentário▾
GabaritoA — os serviços individuais podem ser liberados como artefatos que podem ser implantados independentemente, sem exigir reconstrução ou rollout sincronizado do sistema completo.
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 de Microsserviços: implantação independente
Gabarito: letra A. A principal vantagem da arquitetura de microsserviços é o desacoplamento: cada serviço pode ser desenvolvido, testado e implantado independentemente, eliminando a necessidade de reconstruir e reimplantar todo o sistema para cada alteração. Esse conceito resolve diretamente o problema descrito no enunciado, em que o sistema monolítico exigia a reconstrução e reimplantação de todo o artefato para qualquer pequena mudança.
A questão descreve um problema típico de sistemas monolíticos: qualquer alteração, por menor que seja, demanda a reconstrução completa e a implantação do sistema inteiro, aumentando o esforço de coordenação e o risco de falhas não relacionadas. Ao migrar para microsserviços, a arquitetura passa a ser composta por serviços pequenos e autônomos, cada um com seu próprio ciclo de vida e implantação.
Implantação em microsserviços: Característica principal (Desacoplamento, Cada serviço é independente); Benefícios (Implantação independente, Sem reconstrução do todo, Menos coordenação entre equipes, Menos risco de falhas não relacionadas); Estratégias de rollout (flexíveis) (Blue-green, Canary, Rolling update); Compatibilidade entre serviços (Contratos de API (REST, mensageria), Versionamento)
Alternativa A — ✅ Correta ⟵ GABARITO
Afirma que os serviços individuais podem ser liberados como artefatos independentes, sem exigir reconstrução ou rollout sincronizado do sistema completo. Isso é exatamente a essência dos microsserviços: cada serviço é uma unidade independente de implantação, permitindo que equipes entreguem suas funcionalidades sem coordenar releases conjuntas.
Alternativa B — ❌ Incorreta
Diz que "o alinhamento de versões entre microsserviços garante que suas releases ocorram simultaneamente". Esse conceito é equivocado: a independência dos microsserviços visa justamente evitar a necessidade de releases simultâneas. Embora haja preocupação com compatibilidade, a abordagem típica é usar contratos de API (como REST ou mensageria) e versionamento, não releases sincronizadas.
Alternativa C — ❌ Incorreta
Afirma que a arquitetura impõe uma estratégia fixa de rollout. Microsserviços não impõem uma única estratégia; cada equipe ou serviço pode adotar a estratégia de implantação que melhor se adequa (blue-green, canary, rolling update, etc.). A flexibilidade é uma das vantagens, não uma imposição.
Alternativa D — ❌ Incorreta
Diz que o pipeline de implantação compartilhado garante que todos os microsserviços passem pelos mesmos estágios ao mesmo tempo. Na prática, cada microsserviço geralmente tem seu próprio pipeline de CI/CD, permitindo que sejam implantados em momentos diferentes. Um pipeline compartilhado forçaria a sincronização, contrariando a independência.
PEGA ESSA DICA!
Lembre-se: a principal diferença entre um monolito e microsserviços é a independência de implantação. Se uma alternativa falar em "alinhamento simultâneo" ou "pipeline compartilhado forçando sincronia", está errada. Para a prova, associe microsserviços a independência, desacoplamento e deploy autônomo.