{"subject_id":"3a3cc48d00998165b129fae9d03bc7b6","topico":"HTTP: métodos (idempotência), status (401×403, 301×302, 5xx), stateless, cookies","stems":["Julgue os itens subsecutivos, em relação a IIS (internet information services) e RDS (remote desktop services) em Windows Server.","Julgue os itens a seguir, a respeito de servidores de aplicação e ferramentas de versionamento.","Em relação a sistemas operacionais, programas do Microsoft Office, navegadores e Microsoft Outlook, julgue os itens a seguir.","No que se refere a técnicas de desenvolvimento seguro, julgue os itens que se seguem.","Julgue os itens que se seguem, a respeito do servidor Apache.","Acerca de contêineres, microsserviços e APIs, julgue os itens a seguir.","Julgue os itens a seguir, relativos a arquiteturas de integração."],"questions":[{"id":"0f5771825721","number":70,"stem":0,"statement":"O IIS implementado no Windows Server 2016 e superiores e no Windows 10 e superiores gera logs detalhados das conexões recebidas, realizando registros úteis para auditoria e segurança, como IP de origem, data e hora, método HTTP e código de status retornado.","answer":"C","source":{"slug":"TCE_RS_25","ano":2025},"explanation":{"verdict_reason":"O registro de log é funcionalidade nativa do IIS, ativada por padrão e configurável por site. Nos formatos disponíveis, o W3C Extended inclusive, os campos registrados são exatamente esses: endereço IP de origem, data e hora, método HTTP, recurso solicitado, código de status e tempo de resposta — conjunto que atende às necessidades de auditoria e de investigação de incidentes.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"log do IIS registra origem, método e status","citation":null,"trap_note":"Todo servidor web registra o mesmo núcleo de campos, mude o produto: IIS, Apache e NGINX gravam origem, data e hora, método, recurso e status. Item que negue a um deles esse registro básico está errado."}},{"id":"0e77e44de1c8","number":91,"stem":1,"statement":"O comando git-cherry-pick aplica as alterações introduzidas por alguns commits existentes, sendo necessário, nesse caso, que a árvore de trabalho esteja limpa.","answer":"C","source":{"slug":"TJ_PA_25_SERVIDOR","ano":2025},"explanation":{"verdict_reason":"O git cherry-pick aplica sobre o ramo atual as alterações introduzidas por commits já existentes, criando um novo commit para cada um deles — é como se transportasse a mudança sem levar o histórico junto. A própria documentação do comando exige árvore de trabalho limpa, isto é, sem modificações em relação ao HEAD, porque o comando pode precisar mesclar conteúdo e interromper em conflito.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"cherry-pick reaplica commits existentes","citation":"documentação do git-cherry-pick","trap_note":"Separe os comandos pelo que eles produzem: merge junta históricos, rebase reescreve a base do ramo, cherry-pick copia commits avulsos e revert cria um commit que desfaz outro. A banca troca um pelo outro mantendo a descrição correta."}},{"id":"e85d8db0f147","number":92,"stem":1,"statement":"Um realm no servidor Tomcat verifica a integridade de um arquivo ao comparar o seu resumo de mensagem com o do arquivo original.","answer":"E","source":{"slug":"TJ_PA_25_SERVIDOR","ano":2025},"explanation":{"verdict_reason":"Realm, no Tomcat, é o repositório de usuários, senhas e papéis usado para autenticar quem chega e autorizar o acesso aos recursos protegidos da aplicação — daí existirem o JDBCRealm, o DataSourceRealm, o JNDIRealm e o UserDatabaseRealm, cada um apontando para uma fonte de credenciais diferente. A ação descrita no item, comparar resumo de mensagem para conferir integridade, é verificação de checksum ou de assinatura, e não tem relação com o componente citado.","distortion_type":"atribuicao_errada","distorted_span":"verifica a integridade de um arquivo ao comparar o seu resumo de mensagem com o do arquivo original","corrected_statement":"Um realm no servidor Tomcat é o repositório de usuários, senhas e papéis utilizado para autenticar e autorizar o acesso aos recursos da aplicação.","concept":"realm é base de autenticação e autorização","citation":null,"trap_note":"Realm pode até armazenar a senha como resumo de mensagem, e é dessa vizinhança que a banca se aproveita. Distinga o objetivo: autenticar é provar identidade; comparar resumo de arquivo é verificar integridade. Ação real pendurada no componente errado é atribuição errada."}},{"id":"9a50d05b276b","number":54,"stem":2,"statement":"Além de limpar o histórico de navegação e o histórico de downloads, o modo InPrivate do navegador Microsoft Edge apaga os cookies, os arquivos baixados e os sites selecionados como favoritos durante uma sessão de navegação realizada em modo InPrivate.","answer":"E","source":{"slug":"TRF6_24","ano":2024},"explanation":{"verdict_reason":"A navegação InPrivate descarta o que pertence à sessão: histórico de navegação, histórico de downloads, cookies, dados de site e dados preenchidos em formulários. Ela não apaga o que foi gravado fora do navegador nem o que o usuário decidiu guardar — os arquivos baixados permanecem no disco e os favoritos criados durante a sessão permanecem nos favoritos. A regra está certa, mas foi esticada a dois itens que sobrevivem ao fim da janela.","distortion_type":"escopo_ampliado","distorted_span":"os arquivos baixados e os sites selecionados como favoritos","corrected_statement":"Além de limpar o histórico de navegação e o histórico de downloads, o modo InPrivate do navegador Microsoft Edge apaga os cookies e os dados de sites de uma sessão de navegação realizada em modo InPrivate, mas mantém os arquivos baixados e os sites selecionados como favoritos.","concept":"modo privativo apaga rastro de sessão, não arquivos salvos","citation":null,"trap_note":"Distinga o registro da navegação do artefato salvo: o modo privativo apaga o primeiro e preserva o segundo. Vale para download, favorito e arquivo exportado, e o mesmo raciocínio serve para o modo anônimo de qualquer navegador."}},{"id":"e66eaf023e3f","number":78,"stem":3,"statement":"A redução de velocidade de resposta do servidor é uma forma de prevenção de ataques como o que causa o erro HTTP 429.","answer":"C","source":{"slug":"BCB_24","ano":2023},"explanation":{"verdict_reason":"O 429 Too Many Requests é a resposta que o servidor devolve quando o cliente ultrapassa o limite de requisições no intervalo — situação típica de força bruta, de varredura e de negação de serviço na camada de aplicação. Retardar deliberadamente a resposta é a contramedida clássica desse ataque: reduz a taxa útil do atacante, encarece cada tentativa e é o mesmo princípio da limitação de taxa que produz o próprio 429.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"limitação de taxa e 429 Too Many Requests","citation":"RFC 6585, seção 4","trap_note":"Guarde os códigos que carregam semântica de segurança: 401 é falta de autenticação, 403 é autenticação feita mas acesso negado e 429 é excesso de requisições. Item de desenvolvimento seguro costuma se decidir só pela leitura correta do código."}},{"id":"1d9c08c6300e","number":115,"stem":4,"statement":"As requisições a um servidor Apache sempre retornam um código de status e, opcionalmente, um corpo de resposta.","answer":"C","source":{"slug":"INPI_23","ano":2023},"explanation":{"verdict_reason":"Toda resposta HTTP começa pela linha de estado, que carrega obrigatoriamente o código de três dígitos — não existe resposta sem código. O corpo, ao contrário, é opcional: o 204 No Content e o 304 Not Modified são definidos sem corpo, e a resposta a um HEAD também não o traz. O Apache, como qualquer servidor HTTP, segue essa estrutura.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"código de status é obrigatório; corpo é opcional","citation":"RFC 9110, seção 15","trap_note":"Cuidado com o sempre: aqui ele está certo, porque a obrigatoriedade do código de status é estrutural. Antes de marcar errado por causa do advérbio, procure a exceção concreta — quando não houver nenhuma, o sempre é legítimo."}},{"id":"4bae2de1618e","number":74,"stem":5,"statement":"Usuários que recebem um código de status HTTP 4XX podem refazer a solicitação mesmo sem alterar nada e ter sucesso na próxima resposta.","answer":"E","source":{"slug":"BANCO_DO_NORDESTE_22","ano":2022},"explanation":{"verdict_reason":"A família 4xx significa erro do cliente: a requisição está malformada, não autenticada, sem permissão ou dirigida a recurso inexistente, e repeti-la sem mudar nada produz exatamente a mesma resposta. Quem admite nova tentativa sem alteração é a família 5xx, em que a falha é do servidor e pode ser transitória — e é essa a metade que o item troca.","distortion_type":"troca_de_termo","distorted_span":"código de status HTTP 4XX","corrected_statement":"Usuários que recebem um código de status HTTP 5XX podem refazer a solicitação mesmo sem alterar nada e ter sucesso na próxima resposta.","concept":"4xx é erro do cliente; 5xx é erro do servidor","citation":"RFC 9110, seção 15","trap_note":"Decore as cinco famílias pela responsabilidade: 1xx informativa, 2xx sucesso, 3xx redirecionamento, 4xx culpa do cliente e 5xx culpa do servidor. Repetir a requisição só faz sentido quando a culpa não é de quem repete."}},{"id":"ce43a9eac2fc","number":93,"stem":6,"statement":"A operação HEAD em aplicação RESTful pode ser usada para se obter metainformação sobre a entidade implícita na solicitação sem transferir o próprio corpo da entidade.","answer":"C","source":{"slug":"EMAP_18","ano":2018},"explanation":{"verdict_reason":"O HEAD é definido como idêntico ao GET, com a única diferença de que o servidor não envia o corpo da resposta — apenas a linha de estado e os cabeçalhos, que são os mesmos que acompanhariam o GET. É por isso que ele serve para consultar metainformação: tamanho, tipo de mídia, data de modificação e ETag, sem custo de transferência do conteúdo.","distortion_type":"correto","distorted_span":null,"corrected_statement":null,"concept":"HEAD devolve os cabeçalhos do GET sem o corpo","citation":"RFC 9110, seção 9.3.2","trap_note":"HEAD e GET são seguros e idempotentes; OPTIONS e TRACE também. Idempotentes mas não seguros são PUT e DELETE, porque alteram o recurso. Nem seguro nem idempotente é apenas o POST — e o PATCH também não é idempotente."}}]}