Simulados por competências do Escriturário do Banco do Brasil – Agente de Tecnologia e revisão prática dos tópicos técnicos

Como usar este capítulo (simulados por competências)

Este capítulo organiza mini-simulados por domínio (lógica, SQL, redes, sistemas operacionais, segurança, APIs e infraestrutura). Cada bloco traz: (1) questões objetivas com dificuldade progressiva, (2) tarefas práticas curtas, (3) gabarito comentado com armadilhas e validação técnica, e (4) lista de verificação de competências demonstradas. O foco é treinar leitura de enunciado: identificar restrições, palavras-chave (exceto, incorreta, melhor, primeiro), contexto (produção, auditoria, desempenho) e “o que está sendo pedido” (causa, efeito, comando, camada, propriedade).

Bloco 1 — Lógica e interpretação de enunciados

Conceito (o que a banca costuma cobrar)

Em lógica aplicada a TI, a cobrança frequente envolve: equivalências (implicação, contrapositiva), quantificadores (todo/existe), negações corretas e leitura de condições necessárias/suficientes. A armadilha mais comum é confundir “se” (condição suficiente) com “somente se” (condição necessária) e errar a negação de conectivos (De Morgan).

Questões (progressivas)

Q1. Considere a proposição: “Se o serviço está indisponível, então o monitoramento gera alerta”. Qual é a contrapositiva logicamente equivalente?

• A) Se o monitoramento gera alerta, então o serviço está indisponível.
• B) Se o monitoramento não gera alerta, então o serviço não está indisponível.
• C) Se o serviço não está indisponível, então o monitoramento não gera alerta.
• D) Se o serviço está indisponível, então o monitoramento não gera alerta.

Q2. Negue corretamente: “O sistema autentica o usuário e registra o log”.

• A) O sistema não autentica o usuário e não registra o log.
• B) O sistema não autentica o usuário ou não registra o log.
• C) O sistema autentica o usuário ou não registra o log.
• D) O sistema não autentica o usuário ou registra o log.

Q3. Um requisito diz: “O deploy só ocorre se houver aprovação do change”. Qual formalização é a mais adequada?

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• A) Deploy → Aprovação
• B) Aprovação → Deploy
• C) Deploy ↔ Aprovação
• D) ¬Deploy → Aprovação

Tarefa prática (passo a passo)

Reescreva enunciados em forma lógica antes de responder:

• Passo 1: destaque conectivos (“se”, “somente se”, “e”, “ou”, “exceto”).
• Passo 2: nomeie proposições simples (ex.: D = “há deploy”; A = “há aprovação”).
• Passo 3: traduza: “só ocorre se” vira D → A; “ocorre se” vira A → D.
• Passo 4: se pedirem negação, aplique De Morgan: ¬(P ∧ Q) = ¬P ∨ ¬Q; ¬(P ∨ Q) = ¬P ∧ ¬Q.

Gabarito comentado

Q1: B. A contrapositiva de P → Q é ¬Q → ¬P. Aqui: “indisponível” = P, “gera alerta” = Q. Logo: “se não gera alerta, então não está indisponível”. Armadilha: marcar A (conversa), que não é equivalente.

Q2: B. Negação de “P e Q” é “não P ou não Q”. Armadilha: A (negação forte demais), pois exige que ambos falhem.

Q3: A. “Só ocorre se” indica condição necessária: para haver deploy, precisa haver aprovação. Logo Deploy → Aprovação. Armadilha: B inverte a necessidade (transforma aprovação em suficiente).

Lista de verificação de competências

• Identificar contrapositiva e diferenciar de conversa/inversa.
• Negar proposições compostas usando De Morgan.
• Traduzir “somente se / só ocorre se” como condição necessária (→).
• Evitar armadilhas de linguagem natural em requisitos.

Bloco 2 — SQL (JOIN, agregação, filtros e leitura de resultado)

Conceito (o que a banca costuma cobrar)

O núcleo é interpretar o resultado de consultas: efeito de JOIN (INNER/LEFT), filtros em WHERE vs ON, agregações (COUNT, SUM), HAVING, DISTINCT e tratamento de NULL. Armadilhas: transformar LEFT JOIN em INNER por colocar filtro da tabela da direita no WHERE; confundir COUNT(*) com COUNT(coluna); esquecer que NULL não compara com “=”.

Questões (progressivas)

Considere as tabelas:

clientes(id, nome)  pedidos(id, cliente_id, valor)

Q1. Qual consulta retorna todos os clientes, inclusive os que não têm pedidos, trazendo NULL quando não houver pedido?

• A) SELECT c.nome, p.valor FROM clientes c INNER JOIN pedidos p ON p.cliente_id = c.id;
• B) SELECT c.nome, p.valor FROM clientes c LEFT JOIN pedidos p ON p.cliente_id = c.id;
• C) SELECT c.nome, p.valor FROM clientes c RIGHT JOIN pedidos p ON p.cliente_id = c.id;
• D) SELECT c.nome, p.valor FROM clientes c CROSS JOIN pedidos p;

Q2. Você precisa listar clientes e total gasto, incluindo clientes sem pedidos com total 0. Qual opção é a mais adequada?

• A) SELECT c.id, SUM(p.valor) total FROM clientes c INNER JOIN pedidos p ON p.cliente_id=c.id GROUP BY c.id;
• B) SELECT c.id, COALESCE(SUM(p.valor),0) total FROM clientes c LEFT JOIN pedidos p ON p.cliente_id=c.id GROUP BY c.id;
• C) SELECT c.id, COALESCE(SUM(p.valor),0) total FROM clientes c LEFT JOIN pedidos p WHERE p.cliente_id=c.id GROUP BY c.id;
• D) SELECT c.id, SUM(p.valor) total FROM clientes c LEFT JOIN pedidos p ON p.cliente_id=c.id HAVING SUM(p.valor) >= 0;

Q3. Qual alternativa descreve corretamente a diferença entre WHERE e HAVING em consultas com GROUP BY?

• A) WHERE filtra após a agregação; HAVING filtra antes da agregação.
• B) WHERE filtra linhas antes da agregação; HAVING filtra grupos após a agregação.
• C) WHERE e HAVING são equivalentes em qualquer cenário.
• D) HAVING só pode ser usado sem GROUP BY.

Tarefa prática (passo a passo)

Valide mentalmente o efeito de filtros em LEFT JOIN:

• Passo 1: escreva a intenção: “manter todos os clientes”. Isso exige LEFT JOIN partindo de clientes.
• Passo 2: qualquer condição sobre colunas de pedidos que fique no WHERE pode eliminar linhas com NULL e “quebrar” o LEFT JOIN.
• Passo 3: se precisar filtrar pedidos (ex.: valor > 100) e ainda manter clientes sem pedidos, mova o filtro para o ON: LEFT JOIN pedidos p ON p.cliente_id=c.id AND p.valor > 100.
• Passo 4: para total 0, use COALESCE(SUM(p.valor),0).

Gabarito comentado

Q1: B. LEFT JOIN preserva todas as linhas da tabela à esquerda. Armadilha: A (INNER) elimina clientes sem pedidos.

Q2: B. LEFT JOIN + agregação + COALESCE. Armadilha: C coloca a condição de junção no WHERE, o que tende a transformar o resultado em comportamento de INNER JOIN (clientes sem pedidos desaparecem).

Q3: B. WHERE filtra linhas antes de agrupar; HAVING filtra grupos após agregação. Armadilha: A inverte a ordem.

Lista de verificação de competências

• Interpretar INNER vs LEFT JOIN e prever linhas com NULL.
• Evitar “LEFT JOIN que vira INNER” por filtro indevido no WHERE.
• Aplicar COALESCE em agregações para tratar ausência de linhas.
• Distinguir WHERE (linhas) de HAVING (grupos).

Bloco 3 — Redes (camadas, protocolos e diagnóstico)

Conceito (o que a banca costuma cobrar)

Questões típicas pedem: mapear sintomas a camadas (física/enlace/rede/transporte/aplicação), reconhecer funções de protocolos (ARP, ICMP, TCP/UDP, DNS, HTTP/TLS) e escolher ferramentas de diagnóstico (ping, traceroute, nslookup/dig, netstat/ss). Armadilhas: atribuir DNS à camada errada, confundir ICMP com TCP, ou interpretar “porta aberta” como “aplicação saudável”.

Questões (progressivas)

Q1. Um host não resolve nomes (ex.: não acessa https://exemplo.com), mas acessa um IP diretamente (https://1.2.3.4). O problema é mais provável em qual componente?

• A) DNS
• B) ARP
• C) TCP
• D) MTU

Q2. Qual protocolo é tipicamente usado pelo comando ping?

• A) TCP
• B) UDP
• C) ICMP
• D) ARP

Q3. Em um cenário de “conexão estabelecida, mas aplicação não responde”, qual evidência aponta mais para problema na camada de aplicação do que na de transporte?

• A) Três vias do TCP (SYN/SYN-ACK/ACK) não completa.
• B) Porta está em LISTEN, mas requisições HTTP retornam 500.
• C) Não há rota para o destino.
• D) ARP não resolve o MAC do gateway.

Tarefa prática (passo a passo)

Roteiro rápido de triagem (do mais básico ao mais específico):

• Passo 1: conectividade IP: ping no gateway e em um IP externo (quando permitido).
• Passo 2: caminho: traceroute/tracert para identificar onde para.
• Passo 3: DNS: nslookup/dig para validar resolução e servidor DNS configurado.
• Passo 4: porta: testar TCP (ex.: telnet/nc) e verificar LISTEN (ss/netstat).
• Passo 5: aplicação: testar endpoint (curl) e checar códigos HTTP/latência.

Gabarito comentado

Q1: A. Se IP funciona e nome não, a falha tende a ser resolução DNS (servidor DNS, cache, zona, configuração). Armadilha: marcar TCP (mas TCP funciona ao acessar IP).

Q2: C. Ping usa ICMP Echo Request/Reply. Armadilha: TCP/UDP (ping não usa portas).

Q3: B. TCP estabelecido e HTTP 500 indica que a aplicação recebeu a requisição e falhou internamente (lógica, dependências, exceções). Armadilha: A é transporte; C é rede; D é enlace/rede local.

Lista de verificação de competências

• Identificar DNS como causa quando IP funciona e nome não.
• Reconhecer ICMP como base do ping.
• Diferenciar falha de transporte (handshake) de falha de aplicação (HTTP 5xx).
• Selecionar ferramenta adequada por sintoma (ping, traceroute, dig, ss, curl).

Bloco 4 — Sistemas Operacionais (processos, permissões e troubleshooting)

Conceito (o que a banca costuma cobrar)

Em SO, a banca costuma explorar: permissões e propriedade (Linux), processos e sinais, consumo de recursos (CPU/memória), logs e serviços. Armadilhas: confundir permissão do arquivo com permissão do diretório; interpretar “kill” como sempre “matar” (sinais diferentes); esquecer que falta de espaço em disco pode derrubar serviços por falha de escrita em log.

Questões (progressivas)

Q1. Em Linux, para criar um arquivo dentro de um diretório, qual permissão é essencial no diretório?

• A) Leitura (r)
• B) Escrita (w)
• C) Execução (x)
• D) Escrita (w) e execução (x)

Q2. Um processo está consumindo 100% de CPU e não responde a um encerramento “gracioso”. Qual sequência é mais adequada?

• A) Enviar SIGKILL diretamente sempre.
• B) Enviar SIGTERM e, se necessário, SIGKILL.
• C) Reiniciar a máquina imediatamente.
• D) Remover o binário do processo.

Q3. Um serviço falha ao iniciar e o log mostra “No space left on device”. Qual causa é mais provável?

• A) Falta de memória RAM
• B) Falta de espaço em disco/partição
• C) Falta de permissões de rede
• D) DNS indisponível

Tarefa prática (passo a passo)

Checklist operacional para investigar falha de serviço (Linux):

• Passo 1: status do serviço (ex.: systemctl status nome).
• Passo 2: logs do serviço (ex.: journalctl -u nome).
• Passo 3: recursos: df -h (disco), free -h (memória), top/htop (CPU).
• Passo 4: permissões: verificar usuário do serviço e permissões em diretórios de trabalho/log.
• Passo 5: portas: ss -lntp para ver se já há conflito de porta.

Gabarito comentado

Q1: D. Para criar/remover entradas no diretório, precisa de escrita e execução no diretório. Armadilha: marcar apenas w; sem x você não “acessa” o diretório para criar a entrada.

Q2: B. SIGTERM tenta encerrar permitindo limpeza; SIGKILL é último recurso. Armadilha: A (pula o encerramento controlado e pode corromper estado).

Q3: B. Mensagem é explícita: falta de espaço no dispositivo (disco/partição/inode). Armadilha: A (memória) não gera esse erro.

Lista de verificação de competências

• Reconhecer permissões necessárias em diretórios (w+x).
• Aplicar sequência correta de sinais (TERM antes de KILL).
• Interpretar mensagens de erro de disco e relacionar a falhas de serviço.
• Usar logs e comandos básicos para triagem.

Bloco 5 — Segurança (vetores, controles e leitura de incidentes)

Conceito (o que a banca costuma cobrar)

O foco costuma ser: reconhecer vetores (phishing, força bruta, injeção, XSS, SSRF), diferenciar autenticação vs autorização, e escolher controles (MFA, rate limiting, validação de entrada, menor privilégio, segmentação). Armadilhas: achar que criptografia resolve autorização; confundir hash com criptografia reversível; tratar “bloquear IP” como solução definitiva para ataques distribuídos.

Questões (progressivas)

Q1. Um atacante insere ' OR 1=1 -- em um campo de login e consegue burlar a consulta. Qual vulnerabilidade é mais compatível?

• A) XSS
• B) SQL Injection
• C) CSRF
• D) SSRF

Q2. Um usuário autenticado acessa um endpoint e obtém dados de outro usuário apenas alterando o ID na URL (ex.: /clientes/123 para /clientes/124). Qual falha é mais provável?

• A) Falha de autenticação
• B) Falha de autorização (IDOR)
• C) Falha de criptografia em trânsito
• D) Falha de disponibilidade (DoS)

Q3. Para reduzir impacto de tentativas de senha (credential stuffing) em um endpoint de login, qual controle é mais efetivo em conjunto com boas práticas?

• A) Aumentar o tamanho do banco de dados
• B) Rate limiting e detecção de anomalias, com MFA quando aplicável
• C) Trocar HTTP por FTP
• D) Desabilitar logs

Tarefa prática (passo a passo)

Como validar a alternativa correta em questões de segurança:

• Passo 1: identifique o “sintoma” (ex.: alterar ID e acessar dados alheios).
• Passo 2: mapeie para a categoria (autenticação, autorização, validação de entrada, sessão).
• Passo 3: procure o controle que atua na causa (ex.: checagem de permissão no servidor, não no cliente).
• Passo 4: elimine “soluções cosméticas” (ex.: criptografia não corrige autorização).

Gabarito comentado

Q1: B. Padrão clássico de injeção SQL. Armadilha: XSS envolve script no navegador; aqui o alvo é a consulta.

Q2: B. IDOR é falha de autorização: o usuário está autenticado, mas acessa recurso que não deveria. Armadilha: A (autenticação está funcionando).

Q3: B. Rate limiting, detecção e MFA mitigam tentativas automatizadas e reutilização de credenciais. Armadilha: D remove evidência e piora resposta a incidentes.

Lista de verificação de competências

• Reconhecer padrões de SQLi e diferenciar de XSS/CSRF/SSRF.
• Distinguir autenticação de autorização (IDOR).
• Selecionar controles coerentes com a causa (rate limiting, MFA, validação server-side).
• Identificar armadilhas de “controle irrelevante” (criptografia não substitui autorização).

Bloco 6 — APIs (HTTP, idempotência, erros e contratos)

Conceito (o que a banca costuma cobrar)

Em APIs, é comum cobrar: semântica de métodos HTTP (GET/POST/PUT/PATCH/DELETE), códigos de status (200/201/204/400/401/403/404/409/500), idempotência, versionamento e validação de contrato. Armadilhas: usar 401 quando é 403; achar que POST é idempotente; confundir 200 com 201 em criação.

Questões (progressivas)

Q1. Um cliente envia credenciais ausentes/invalidas. Qual status é mais adequado?

• A) 400
• B) 401
• C) 403
• D) 404

Q2. Qual método é tipicamente idempotente?

• A) POST
• B) PUT
• C) PATCH
• D) CONNECT

Q3. Ao criar um recurso com sucesso e retornar a representação do novo recurso, qual status é mais apropriado?

• A) 200
• B) 201
• C) 204
• D) 409

Tarefa prática (passo a passo)

Como decidir status code em prova:

• Passo 1: identifique o tipo de falha: cliente (4xx) ou servidor (5xx).
• Passo 2: autenticação: 401 (não autenticado); autorização: 403 (autenticado, mas sem permissão).
• Passo 3: criação: 201; sucesso sem corpo: 204; conflito de estado: 409.
• Passo 4: idempotência: PUT tende a substituir/definir estado do recurso; repetir não muda o resultado final.

Gabarito comentado

Q1: B. 401 é para ausência/invalidade de credenciais (não autenticado). Armadilha: 403 é quando credenciais são válidas, mas falta permissão.

Q2: B. PUT é tipicamente idempotente. Armadilha: POST geralmente não é (repetir pode criar múltiplos recursos).

Q3: B. 201 Created é o padrão para criação bem-sucedida. Armadilha: 200 pode aparecer em alguns sistemas, mas 201 é a resposta mais correta em termos de semântica HTTP.

Lista de verificação de competências

• Diferenciar 401 (não autenticado) de 403 (sem permissão).
• Reconhecer idempotência e associar a PUT.
• Escolher status code adequado para criação (201) e ausência de corpo (204).
• Interpretar enunciados com foco em semântica HTTP.

Bloco 7 — Infraestrutura e observabilidade (capacidade, disponibilidade e sinais)

Conceito (o que a banca costuma cobrar)

Em infraestrutura, a cobrança frequente envolve: identificar gargalos (CPU, memória, I/O, rede), interpretar métricas e logs, noções de disponibilidade (redundância, ponto único de falha) e efeitos de escalabilidade. Armadilhas: confundir “mais CPU” com solução para I/O; interpretar aumento de latência sem olhar percentis; ignorar saturação de conexões/threads.

Questões (progressivas)

Q1. Uma API apresenta latência alta apenas em p95/p99, enquanto a média permanece aceitável. O que isso sugere?

• A) Não há problema, pois a média está boa.
• B) Há cauda de latência afetando parte dos usuários, possivelmente por contenção ou dependências lentas.
• C) O problema é certamente DNS.
• D) O problema é certamente falta de CPU.

Q2. Um servidor tem CPU baixa, mas tempo de resposta alto e disco com alta utilização e fila de I/O. Qual gargalo é mais provável?

• A) CPU
• B) Memória
• C) I/O de disco
• D) Camada física de rede

Q3. Em termos de disponibilidade, qual cenário representa um ponto único de falha (SPOF)?

• A) Dois servidores em balanceamento, mas um único banco de dados sem replicação
• B) Dois servidores e dois bancos com failover
• C) Serviços distribuídos em múltiplas zonas
• D) Cache redundante com múltiplos nós

Tarefa prática (passo a passo)

Como validar hipóteses de gargalo com sinais:

• Passo 1: defina o sintoma (latência, erro, timeout, queda).
• Passo 2: observe métricas-chave: CPU, memória, I/O, rede, filas (threads/conexões), taxa de erro.
• Passo 3: compare média vs percentis (p95/p99) para detectar cauda.
• Passo 4: correlacione com logs e eventos (deploy, pico de tráfego, falha de dependência).
• Passo 5: teste a hipótese: se I/O está saturado, otimizar acesso a disco/banco tende a impactar mais do que aumentar CPU.

Gabarito comentado

Q1: B. Percentis altos com média ok indicam cauda de latência: uma parcela significativa sofre atrasos (contenção, GC, dependência externa, lock). Armadilha: A ignora a experiência dos usuários afetados.

Q2: C. Alta fila de I/O e disco saturado apontam gargalo de disco. Armadilha: A (CPU baixa não sustenta hipótese de CPU como gargalo principal).

Q3: A. Mesmo com dois servidores, um único banco sem replicação é SPOF. Armadilha: confundir redundância parcial com alta disponibilidade completa.

Lista de verificação de competências

• Interpretar percentis (p95/p99) e reconhecer cauda de latência.
• Identificar gargalo por evidências (I/O vs CPU vs rede).
• Reconhecer ponto único de falha em arquiteturas.
• Correlacionar métricas, logs e eventos para validar hipóteses.

Mini-simulado integrado (misturando domínios)

Questões

Q1. Em uma consulta com LEFT JOIN, um filtro em coluna da tabela da direita foi colocado no WHERE e “sumiram” linhas esperadas. Qual correção é mais adequada para manter as linhas da esquerda?

• A) Trocar LEFT por INNER JOIN
• B) Mover o filtro para a cláusula ON
• C) Remover o GROUP BY
• D) Trocar SUM por COUNT

Q2. Um endpoint retorna 403 para um usuário logado. O que isso indica com maior probabilidade?

• A) Credenciais inválidas
• B) Usuário autenticado, mas sem permissão
• C) Recurso não existe
• D) Erro interno do servidor

Q3. Um analista afirma: “Se há alerta, então o serviço está indisponível”. Isso é equivalente a “Se o serviço está indisponível, então há alerta”?

• A) Sim, são equivalentes
• B) Não, é a conversa e não é equivalente
• C) Sim, é a contrapositiva
• D) Não, é a inversa e sempre equivalente

Q4. Um host acessa IPs, mas não resolve nomes. Qual comando ajuda a confirmar a hipótese principal?

• A) dig/nslookup
• B) kill -9
• C) chmod
• D) git status

Q5. Latência p99 subiu após aumento de tráfego, com CPU moderada e fila de conexões alta. Qual hipótese é mais coerente?

• A) Contenção/saturação de recursos concorrentes (threads/conexões) causando cauda de latência
• B) DNS parou de funcionar
• C) O problema é exclusivamente disco, sem evidência
• D) Não há problema, pois a média não mudou

Gabarito comentado

Q1: B. Filtro no WHERE elimina NULLs do lado direito e descaracteriza o LEFT JOIN. Colocar no ON preserva linhas da esquerda.

Q2: B. 403 é autorização negada (autenticado, mas sem permissão). 401 seria ausência/invalidade de credenciais.

Q3: B. “Se há alerta então indisponível” é a conversa de “se indisponível então há alerta”. Não é equivalência lógica.

Q4: A. dig/nslookup valida resolução DNS e servidor configurado.

Q5: A. p99 alto com fila de conexões sugere saturação/contensão e cauda de latência; a média pode mascarar o problema.

Lista de verificação de competências

• Corrigir armadilhas de LEFT JOIN com filtros.
• Interpretar 401 vs 403 em APIs.
• Distinguir implicação de conversa/contrapositiva.
• Selecionar ferramenta de rede adequada para hipótese de DNS.
• Interpretar p99 e relacionar com saturação/contensão.