

Seu próximo nível começa aqui
Com a Assinatura Ilimitada, você tem tudo que precisa para sua aprovação.
Com a Assinatura Ilimitada, você combina prática, teoria e método em uma única assinatura com tudo que você precisa para sua aprovação.
Um órgão fazendário está modernizando o módulo de cálculo de tributos e deseja separar claramente a lógica das regras fiscais das adaptações necessárias para diferentes bancos de dados usados pelos estados. Considerando que a equipe quer garantir que mudanças na infraestrutura não impactem as regras tributárias centrais, a abordagem arquitetural que atende melhor a essa necessidade é
a Arquitetura MVC, concentrando a lógica tributária em serviços ligados à camada de apresentação da aplicação web, aproveitando os recursos nativos do framework (como filtros, interceptors e validações) para tratar as particularidades de cada banco de dados.
concentrar as regras fiscais em repositórios especializados por tipo de banco de dados, permitindo que cada repositório implemente as regras e consultas de forma otimizada para o SGBD específico (por exemplo, usando stored procedures ou funções nativas).
Implementar a maior parte da lógica fiscal nos controllers das APIs, centralizando ali o fluxo das regras tributárias e das chamadas às diferentes fontes de dados, o que facilitaria a coordenação entre múltiplos bancos de dados sem alterar o domínio existente.
a arquitetura hexagonal, estruturando o dominio com portas (Interfaces) e adaptadores para cada banco de dados, de forma que as regras fiscais permaneçam independentes das tecnologias de persistência.
definir DTOs ricos para transporte de dados entre camadas, adicionando validações e transformações relacionadas às regras fiscais nesses objetos, mantendo a lógica tributária distribuída entre serviços, controllers e mapeamentos de banco de dados já existentes.
Uma empresa está migrando sua arquitetura monolítica para microsserviços. Durante a análise, identificou-se que vários serviços precisam acessar dados de clientes, atualmente centralizados em um único banco de dados.
Considerando os princípios de arquitetura de microsserviços e o teorema CAP, a abordagem mais adequada para garantir autonomia dos serviços, sem comprometer a consistência dos dados críticos de clientes é
manter o banco de dados compartilhado entre todos os serviços para garantir consistência forte.
replicar o banco de dados de clientes para cada microsserviço, garantindo que cada um tenha sua própria cópia completa.
implementar um serviço dedicado de clientes com seu próprio banco de dados e expor operações via API, usando eventos para sincronização eventual com outros serviços.
eliminar o banco de dados relacional e migrar todos os dados para um sistema de arquivos distribuído.
implementar transações distribuídas (2PC) entre todos os serviços para garantir atomicidade.
Ao projetar um novo sistema para um ministério, o arquiteto de software precisa decidir entre uma arquitetura monolítica e uma arquitetura de microsserviços. O sistema terá módulos com diferentes demandas de escalabilidade: um módulo de consulta pública com picos de acesso sazonais e um módulo de processamento em lote com uso intensivo de CPU. A equipe de desenvolvimento é grande e distribuída.
Analise as seguintes proposições sobre a escolha do padrão arquitetural indicada para este cenário:
I. Uma arquitetura monolítica seria a indicada, pois a implantação única facilita a gestão da infraestrutura e garante a consistência transacional entre os módulos, mesmo que isso signifique escalar a aplicação como um todo para atender aos picos de um único módulo.
II. A arquitetura de microsserviços é a escolha ideal, pois permite escalar o serviço de consulta pública de forma independente do serviço de processamento em lote, otimizando o uso de recursos. Além disso, facilita o trabalho paralelo de equipes distribuídas em serviços autônomos.
III. A complexidade da comunicação entre serviços e a necessidade de um gateway de API para expor as funcionalidades ao cliente são desvantagens da arquitetura de microsserviços que a tornam inviável para o setor público, que preza pela simplicidade operacional.
Está correto o que se afirma em:
II e III, apenas.
II, apenas.
I e II, apenas.
I, II e III.
III, apenas.
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
microsserviços por domínios em contêineres independentes e escaláveis.
monolito em camadas com todos os módulos no mesmo processo.
cliente-servidor de duas camadas com banco de dados centralizado.
MVC único que concentre regras de negócio e integrações externas.
serviços SOAP em barramento corporativo único para integração.
Em arquiteturas de microsserviços, a autonomia dos serviços favorece escalabilidade e evolução independente, mas impõe desafios relevantes na gestão de dados. A adoção do princípio “banco de dados por serviço” reduz acoplamento, porém dificulta transações distribuídas tradicionais, exigindo estratégias arquiteturais para manter consistência e confiabilidade em operações que atravessam múltiplos serviços. Uma abordagem recorrente é o padrão Saga, que coordena transações locais e compensações, evitando bloqueios globais típicos de transações ACID distribuídas.
Considere um sistema de marketplace implementado em microsserviços, com os seguintes serviços: Pedido, Pagamento e Estoque, cada um com seu próprio banco de dados. Ao confirmar uma compra, o fluxo exige: (1) criar o pedido, (2) reservar o estoque e (3) confirmar o pagamento. Em caso de falha em qualquer etapa, o sistema deve retornar a um estado consistente, sem depender de uma transação distribuída única com bloqueio entre bancos.
Assinale a alternativa que descreve corretamente a estratégia arquitetural mais adequada, nesse cenário, para garantir consistência de dados sem uso de transações distribuídas ACID, reduzindo risco de bloqueios e aumentando resiliência.
Implementar uma transação distribuída em dois fases (2PC) entre os três bancos, pois elimina a necessidade de tratamento de falhas e garante atomicidade global.
Centralizar todos os dados em um único banco relacional compartilhado pelos três serviços, pois isso preserva independência dos microsserviços e evita acoplamento.
Aplicar o padrão Saga, compondo transações locais em cada serviço e definindo ações compensatórias para desfazer etapas concluídas quando ocorrer falha posterior.
Executar as três operações em paralelo e aceitar inconsistência temporária sem correção, pois microsserviços não exigem consistência entre serviços.


Seu próximo nível começa aqui

Seu próximo nível começa aqui
Destrave a preparação completa para sua aprovação. Com a Assinatura Ilimitada, você estuda com os melhores professores do Brasil e todos os recursos Gran.
O IFCE está migrando parte de seu sistema acadêmico para uma arquitetura baseada em microsserviços. A equipe identificou que diferentes serviços (matrícula, financeiro, biblioteca e autenticação) precisam ser acessados por aplicações web e mobile. Para evitar que os clientes consumam diretamente cada microsserviço e para centralizar autenticação, roteamento e controle de requisições, o analista de tecnologia da informação propôs a adoção de um componente específico na arquitetura.
Considerando o cenário descrito, é correto afirmar que a solução adequada é
permitir que cada aplicação cliente se conecte diretamente a todos os microsserviços, realizando autenticação individual em cada serviço.
consolidar as funcionalidades dos microsserviços em um serviço centralizado do tipo monolítico, visando à simplificação da comunicação entre a camada de apresentação e o backend.
utilizar um API Gateway para centralizar autenticação, roteamento e políticas de acesso, podendo combinar com orquestração quando houver coordenação entre múltiplos serviços.
implementar um barramento de dados dedicado para o armazenamento compartilhado de estados e informações entre todos os microsserviços do ecossistema.
limitar a infraestrutura de rede ao uso de balanceadores de carga na camada de transporte, sem a adoção de uma camada intermediária de gerenciamento de APIs.
Um microsserviço pode ter diversas finalidades, desde que sejam escritas na mesma linguagem e estejam no mesmo servidor.
Certo
Errado
Certa equipe de desenvolvimento está criando um sistema de acompanhamento processual com interface web e aplicativo móvel. O sistema adota o padrão MVC para separar a lógica da apresentação, mas a comunicação entre o front-end e o back-end ocorre por APIs REST expostas em contêineres Docker, orquestrados por Kubernetes, a fim de garantir alta disponibilidade e balanceamento de carga.
A partir da situação hipotética precedente, é correto afirmar que o conjunto de tecnologias e conceitos utilizados caracteriza uma
implementação de SOA baseada em filas síncronas e acoplamento rígido.
aplicação peer-to-peer com comunicação direta entre instâncias.
arquitetura cliente-servidor com uso de microsserviços e contêineres orquestrados.
aplicação monolítica com padrão MVC centralizado.
arquitetura em três camadas sem separação lógica entre componentes.
Na modernização dos sistemas de fiscalização, o Tribunal migrou de um sistema monolítico para uma arquitetura de microsserviços. Durante uma auditoria técnica, observou-se que a falha em um serviço de autenticação estava causando a queda em cascata de todos os outros serviços dependentes.
O padrão de projeto de arquitetura de software a ser implementado para interromper chamadas a um serviço que está a falhar, permitindo que o sistema degrade graciosamente em vez de colapsar, é o
Singleton.
Observer.
Circuit Breaker.
Adapter.
Facade.
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
os serviços individuais podem ser liberados como artefatos que podem ser implantados independentemente, sem exigir reconstrução ou rollout sincronizado do sistema completo.
o alinhamento de versões entre microsserviços garante que suas releases ocorram simultaneamente, evitando incompatibilidades entre componentes.
a arquitetura impõe uma estratégia fixa de rollout que padroniza a implantação em todos os ambientes onde o sistema deve ser implantado.
o pipeline de implantação compartilhado garante que todos os microsserviços passem pelos mesmos estágios de release ao mesmo tempo.


Seu próximo nível começa aqui
Seu desenvolvimento não pode ter limites. Garanta sua Assinatura Ilimitada e libere uma preparação completa com os melhores professores do Brasil.
Em microsserviços baseados no estilo RESTful, onde deve ser feita a validação de requisições?
No lado do cliente, o que é suficiente para verificar se as requisições estão corretas e evitar que requisições malformadas sejam enviadas para o servidor, melhorando a usabilidade e eliminando tráfego desnecessário.
No API Gateway, para verificar a conformidade com o esquema de requisições, evitando a necessidade de verificação de erros pelo servidor e padronizando a validação entre os vários microsserviços.
No lado do cliente para verificar regras de formatação, melhorando a usabilidade e reduzindo tráfego desnecessário, assim como no lado servidor para garantir segurança e conformidade com a interface do serviço.
No lado do servidor, em se tratando de requisições a APIs publicamente acessíveis, ao passo que requisições internas entre os microsserviços da aplicação podem ser validadas apenas pelo microsserviço chamador
Sistemas distribuídos modernos frequentemente combinam diferentes modelos de comunicação para atender requisitos de desempenho, escalabilidade e resiliência. A comunicação síncrona, como chamadas diretas via HTTP, oferece simplicidade e resposta imediata, enquanto a comunicação assíncrona, baseada em eventos ou mensageria, reduz acoplamento temporal e aumenta tolerância a falhas, sendo especialmente relevante em arquiteturas de microsserviços.
Considere uma arquitetura de microsserviços em que um serviço de Processamento de Pedidos precisa acionar, de forma confiável, serviços de Faturamento e Notificação. O sistema deve continuar aceitando pedidos mesmo quando um desses serviços estiver temporariamente indisponível, sem bloquear o fluxo principal da aplicação.
Nesse contexto, assinale a alternativa que descreve corretamente a estratégia arquitetural mais adequada para atender a esses requisitos, considerando comunicação entre serviços.
Utilizar chamadas HTTP síncronas encadeadas entre os serviços, garantindo resposta imediata e simplificando o controle do fluxo.
Adotar comunicação assíncrona baseada em eventos ou filas, permitindo desacoplamento temporal e processamento independente entre os serviços.
Centralizar toda a lógica de comunicação em um único serviço orquestrador, eliminando a necessidade de troca de mensagens entre serviços.
Executar os serviços dependentes apenas após confirmação manual da equipe de operações, evitando falhas durante indisponibilidades temporárias.
Uma Secretaria da Fazenda mantém um sistema corporativo que integra cadastro de contribuintes, arrecadação, fiscalização eletrônica e relatórios gerenciais. Com o aumento do volume de acessos e a necessidade de evoluir módulos de forma independente, a equipe de TI avalia manter a arquitetura atual ou migrar gradualmente para microsserviços, entendendo que
os módulos em uma arquitetura monolítica compartilham o mesmo ciclo de implantação e execução, o que simplifica o desenvolvimento inicial; já em microsserviços, cada serviço pode ser implantado e escalado de forma independente, exigindo maior maturidade em integração, monitoramento e gestão operacional.
a adoção de microsserviços elimina a necessidade de testes integrados e observabilidade, pois cada serviço funciona de maneira isolada, enquanto sistemas monolíticos dependem de ferramentas externas para garantir confiabilidade.
a arquitetura monolitica impede qualquer tipo de escalabilidade seletiva, pois tados 05 componentes precisam ser replicados integralmente, enquanto microsserviços eliminam dependências entre módulos e dispensam mecanismos de comunicação entre serviços.
microsserviços são indicados apenas para sistemas pequenos e estáveis, pois a fragmentação do sistema aumenta a complexidade de implantação, tornando inviável o uso em ambientes críticos como os de arrecadação estadual.
a arquitetura monolitica facilta a govemança e o controle transacional distribuido entre módulos independentes, enquanto microsserviços concentram dados e regras de negócio em um único repositório para simplificar a consistência.
O Ministério Público de um estado brasileiro está modernizando seus sistemas de TI. A nova arquitetura de software será baseada em microsserviços hospedados na AWS e exigirá diferentes estratégias de comunicação assíncrona entre os componentes. A equipe identificou os seguintes requisitos:
I. Ingestão de dados em tempo real: As denúncias precisam ser ingeridas continuamente e em grande volume para análise posterior (Streaming).
II. Notificações fan-out: Alertas críticos devem ser enviados via SMS, e-mail e push (Múltiplos protocolos).
III. Compatibilidade legada: Sistemas Java que utilizam o padrão JMS devem ser integrados sem modificações significativas no código.
Considerando os serviços da AWS, atendem aos requisitos I, II e III, respectivamente:
Amazon Kinesis, Amazon SNS e Amazon MQ.
Amazon Kinesis, Amazon SQS e Amazon MQ.
Amazon SQS, Amazon SNS e Amazon MQ.
Amazon SNS, Amazon Kinesis e Amazon MQ.
Amazon MQ, Amazon Kinesis e Amazon SNS.
Em arquiteturas modernas baseadas em microsserviços, é comum a utilização de uma API Gateway, que atua como um ponto único de entrada para requisições externas. Esse componente integra a camada de middleware, sendo responsável por funções como roteamento de requisições, autenticação, transformação de mensagens, controle de acesso e aplicação de políticas de segurança, permitindo que clientes acessem múltiplos serviços de backend de forma transparente.
Considere o seguinte exemplo de configuração simplificada de um gateway para registrar um serviço e criar uma rota de acesso:

Clientes podem acessar o serviço por meio do endpoint:
![]()
O gateway encaminhará automaticamente a requisição para o serviço backend correspondente
. Com base no funcionamento de API Gateways em arquiteturas distribuídas, analise as afirmativas a seguir.
I. A configuração apresentada permite que o cliente acesse o recurso /usuarios pelo gateway, sem precisar conhecer diretamente o endereço ou a porta do serviço backend responsável pelo processamento da requisição.
II. A presença da API Gateway na arquitetura implica que os serviços internos deixam de se comunicar diretamente entre si, passando toda interação obrigatoriamente pelo gateway.
III. A centralização do acesso aos serviços em uma API Gateway possibilita a implementação de mecanismos comuns, como autenticação, registro de logs e limitação de requisições, em um único ponto da arquitetura.
Assinale a alternativa CORRETA:
Apenas I e II estão corretas.
Apenas III está correta.
Apenas I e III estão corretas.
Apenas I está correta.


Seu próximo nível começa aqui

Seu próximo nível começa aqui
Destrave a preparação completa para sua aprovação. Com a Assinatura Ilimitada, você estuda com os melhores professores do Brasil e todos os recursos Gran.
Uma instituição financeira está redesenhando sua arquitetura de TI, migrando de uma arquitetura monolítica para microsserviços executados em contêineres sobre Kubernetes. Em um segundo momento, alguns componentes pontuais (por exemplo, funções de validação de CPF, cálculo de score ou envio de notificações) foram implementados em modelo serverless (Functions as a Service), disparados sob demanda.
Para lidar com a complexidade crescente da comunicação entre microsserviços (observabilidade, tracing, retry, circuit breaking e políticas de segurança mTLS), a equipe está avaliando a adoção de um service mesh (como Istio ou Linkerd).
Com base nesse cenário, é correto afirmar que:
a adoção de serverless torna desnecessária a arquitetura de microsserviços, pois funções serverless substituem, por definição, serviços implantados em contêineres em qualquer cenário;
em uma arquitetura com service mesh, a comunicação entre serviços passa a ocorrer sem uso da rede, por meio de chamadas diretas em memória entre sidecars, eliminando latência e falhas de transporte;
a principal função de um service mesh é substituir o orquestrador de contêineres, assumindo responsabilidades de agendamento de pods, distribuição de carga entre nós físicos e detecção de falhas de hardware;
microsserviços e serverless são abordagens mutuamente excludentes, de forma que uma aplicação que utiliza funções serverless não pode, ao mesmo tempo, empregar serviços em contêineres para o mesmo domínio de negócio;
o uso de um service mesh busca externalizar, para a infraestrutura, diversas preocupações transversais, como roteamento de tráfego, telemetria, autenticação mútua (mTLS) e políticas de resiliência, reduzindo a necessidade de implementar essas funcionalidades no código de cada microsserviço.
A arquitetura de software define a estrutura e as interações entre os componentes de um sistema, impactando diretamente atributos como escalabilidade e manutenibilidade. Analise as afirmativas a seguir:
I.O padrão Model-View-Controller (MVC) separa a aplicação em três camadas lógicas: dados e regras de negócio, interface com o usuário e coordenação do fluxo de controle.
II.A arquitetura de microsserviços propõe a divisão do sistema em serviços autônomos e independentes, que se comunicam através de protocolos leves e descentralizados.
III.Em sistemas Service-Oriented Architecture (SOA), os serviços devem ser construídos com alto acoplamento para assegurar a sincronização de dados entre os componentes.
Está correto o que se afirma em:
I e II apenas.
II apenas.
I, II e III.
III apenas.
Diferentemente das arquiteturas tradicionais de N camadas, a arquitetura de microsserviços se baseia na descentralização da gestão de dados, em que cada serviço deve, idealmente, possuir sua própria base de dados, de forma a garantir a independência de implantação e o baixo acoplamento.
Certo
Errado
A arquitetura de microsserviços contrasta com a arquitetura monolítica em aspectos como acoplamento entre componentes, independência dos serviços e forma de interação entre eles. Nesse sentido, assinale a alternativa correta.
Em uma arquitetura monolítica, a aplicação é decomposta em serviços independentes de plataforma, fracamente acoplados, que interagem por interfaces para compor o sistema.
Na arquitetura orientada a serviços, os componentes devem ser fortemente acoplados entre si e compartilhar estado e dependências comuns, para garantir a consistência das operações distribuídas sem necessidade de coordenação explícita.
Na arquitetura de microsserviços, os serviços devem basear-se em componentes externos compartilhados, para garantir seu comportamento funcional e não funcional consistente em qualquer ambiente de execução.
Na arquitetura de microsserviços, a aplicação é composta por serviços independentes de plataforma e linguagem de implementação, fracamente acoplados, que interagem entre si para compor o sistema.
Na arquitetura de microsserviços, cada serviço executa de forma completamente isolada, sem necessitar de comunicação com os demais serviços do sistema para realizar suas operações.
Com a crescente demanda por sistemas escaláveis e de rápida evolução, a arquitetura de microsserviços tem sido amplamente adotada em ambientes corporativos modernos.
Nesse contexto, assinale a alternativa que descreve corretamente uma característica essencial da arquitetura de microsserviços.
Cada microsserviço é desenvolvido e implantado de forma independente, comunicando-se com outros serviços por meio de interfaces bem definidas.
Todos os microsserviços devem compartilhar o mesmo banco de dados para garantir consistência transacional entre operações.
A arquitetura de microsserviços elimina completamente a necessidade de mecanismos de comunicação entre serviços.
Em microsserviços, a aplicação deve ser empacotada e implantada como uma única unidade executável.