Um órgão público mantém um sistema de processamento de folha de pagamento que roda, durante a maior parte do ano, em infraestrutura própria (on-premises).
No entanto, nos meses de dezembro e janeiro, a demanda por processamento aumenta significativamente devido ao 13º salário, reajustes e grande volume de retificações, causando risco de indisponibilidade e degradação de desempenho.
Para lidar com esses picos, a equipe de TI decide configurar um mecanismo automático para que, sempre que a carga ultrapassar determinado limiar, sejam instanciados recursos adicionais de computação em uma nuvem pública.
Essa estratégia de extensão dinâmica da capacidade computacional para a nuvem pública em momentos de alta demanda é denominada: 

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: 

Um tribunal está padronizando o deploy do serviço api-judicial em Kubernetes. O time de infraestrutura propõe o seguinte manifesto:

                                                                                       

Com base nesse manifesto e em conceitos de Kubernetes (contêineres, pods e orquestração), analise as afirmativas a seguir.

I. O objeto Deployment gerenciará ReplicaSets e pods de modo que, em condições normais, haja até 3 pods prontos (readiness OK) associados ao rótulo app: api-judicial.

II. A readinessProbe evita que o Service associado (caso exista) encaminhe tráfego para pods cujo endpoint /health em 8080 ainda não esteja respondendo adequadamente, mesmo que o contêiner já esteja em execução.

III. Se o time alterar apenas o campo image para uma nova versão e aplicar o manifesto com kubectl apply -f, o Deployment poderá realizar um rolling update, substituindo gradualmente os pods antigos pelos novos, desde que não haja alteração no seletor (selector.matchLabels).

Está correto o que se afirma em: 

 

A equipe de SRE (Site Reliability Engineering) de um órgão público está definindo a estratégia de atualização de microsserviços críticos em seu cluster Kubernetes. O requisito de negócio estabelece que novas versões da aplicação não podem ser liberadas para todos os usuários simultaneamente devido ao risco de bugs não detectados em homologação.
A estratégia escolhida deve permitir o direcionamento de uma pequena porcentagem do tráfego de produção (ex: 5%) para a nova versão, enquanto os 95% restantes continuam sendo atendidos pela versão estável. Se as métricas de latência e erro da nova versão forem satisfatórias, o tráfego é gradualmente migrado até atingir 100%; caso contrário, o tráfego é revertido instantaneamente.
Essa estratégia de implantação, que frequentemente exige o uso de um Ingress Controller avançado ou de um Service Mesh para gerenciar o peso do tráfego independentemente do número de réplicas de pods, é denominada: 

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: