O analista Otto precisa criar a tabela PROCESSOS garantindo que:
1. o número do processo seja único e obrigatório.
2. o status só possa ser “ABERTO”, “FECHADO” ou “EM_ANDAMENTO”.
3. a coluna ID seja chave primária gerada automaticamente.
Para garantir a integridade dos dados, no PostgreSQL, Otto deve implementar:

Observe o script SQL do PostgreSQL a seguir.

CREATE TABLE partes (
  id INT PRIMARY KEY,
  nome VARCHAR(100));

CREATE TABLE processos (
  id INT PRIMARY KEY,
  numero_processo VARCHAR(50));

CREATE TABLE audiencias (
  id INT PRIMARY KEY,
  processo_id INT,
  FOREIGN KEY (processo_id) REFERENCES processos(id));

CREATE TABLE partes_processos (
  processo_id INT,
  parte_id INT,
  PRIMARY KEY (processo_id, parte_id),
  FOREIGN KEY (processo_id) REFERENCES processos(id),
  FOREIGN KEY (parte_id) REFERENCES partes(id));

-- Partes
INSERT INTO partes (id, nome)
VALUES (1, 'João Silva'), (2, 'Maria Souza');

-- Processos
INSERT INTO processos (id, numero_processo)
VALUES (101, '0001234-56.2025.8.01.0001'),
       (102, '0001234-56.2025.8.01.0002');

-- Audiências
INSERT INTO audiencias (id, processo_id)
VALUES (201, 101);

-- Partes_Processos
INSERT INTO partes_processos (processo_id, parte_id)
VALUES (101, 1), (102, 2);

A consulta que retorna apenas os registros com Partes que ainda não possuem Audiências marcadas é:

SELECT p.nome
FROM audiencias a
RIGHT JOIN partes_processos pp
        ON a.processo_id = pp.processo_id
JOIN partes p ON pp.parte_id = p.id;

SELECT p.nome
FROM partes p
JOIN partes_processos pp ON p.id = pp.parte_id
LEFT JOIN audiencias a
        ON pp.processo_id = a.processo_id
WHERE a.id IS NOT NULL;

SELECT p.nome
FROM partes p
WHERE NOT EXISTS (
        SELECT 1
        FROM partes_processos pp
        JOIN audiencias a ON pp.processo_id = a.processo_id
        WHERE pp.parte_id = p.id );

SELECT p.nome
FROM partes p
WHERE EXISTS (
        SELECT 1
        FROM partes_processos pp
        JOIN audiencias a
                ON pp.processo_id = a.processo_id
        WHERE pp.parte_id = p.id );

SELECT p.nome
FROM partes p
JOIN partes_processos pp ON pp.parte_id = p.id
WHERE EXISTS (
        SELECT 1
        FROM audiencias a
        WHERE a.processo_id = pp.processo_id );

A analista Maria está utilizando o MySQL para executar uma consulta com algumas colunas em diversas tabelas de um banco de dados utilizando a cláusula JOIN. O resultado apresenta diversos registros repetidos. No MySQL, a cláusula que Maria deve utilizar para que a consulta retorne apenas valores diferentes é:

O programador Luiz está acessando uma tabela armazenada em um banco de dados PostgreSQL. A cláusula que Luiz deve utilizar para retornar 20 registros, pulando os 40 primeiros, é:

O programador Miguel está implementando uma rotina de extração de dados de diversos bancos de dados, realizando a integração e transformação desses dados para serem carregados em um ambiente analítico. Miguel observou que a chave que identifica a entidade “Processo Judicial” é implementada de diferentes formas em cada banco de dados, por exemplo: ID_P, IDPROC e P_JUD_NUM. Para resolver o problema utilizando uma chave artificial, sem significado, que identifique unicamente os processos independentemente da sua origem, Miguel deve definir uma chave:

Uma aplicação baseada em microsserviços, hospedada em uma nuvem privada de um órgão, tem apresentado picos de latência em transações que atravessam vários serviços.
Com base no conceito de observabilidade, a correlação correta de itens a ser adotada para acelerar a investigação da causa raiz do problema é:

Considerando as demandas típicas de um tribunal por sistemas confiáveis e previsíveis, e à luz do teorema CAP, um banco de dados distribuído que prioriza consistência e tolerância a partições (CP), sacrificando temporariamente a disponibilidade durante partições de rede, é a escolha mais adequada para um:

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 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 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: