Em uma instalação de servidor de banco de Dados PostgreSQL, ...

As with any server daemon that is accessible to the outside world, it is advisable to run PostgreSQL under a separate user account. This user account should only own the data that is managed by the server, and should not be shared with other daemons. (For example, using the user nobody is a bad idea.) It is not advisable to install executables owned by this user because compromised systems could then modify their own binaries. Documentation PostgreSQL 17.1 User Account.

Quem não tem acesso:  - -> C

Me lembrei de Game Of Thrones, - quem é você? ninguém!

Valar Morghulis

Alternativa correta: C - nobody.

Para entender esta questão, é preciso ter conhecimento sobre boas práticas de segurança em sistemas de gerenciamento de banco de dados (SGBD), como o PostgreSQL. Um dos aspectos críticos da segurança é o princípio do menor privilégio, que recomenda que os softwares, incluindo daemons ou serviços que operam no servidor, sejam executados com o menor nível de permissões necessário para realizar suas funções.

O usuário "nobody" é um usuário especial em sistemas Unix e Unix-like, que geralmente possui muito poucos privilégios sobre o sistema. Isso é feito intencionalmente para que, se um processo ou serviço for comprometido por um ataque, o impacto seja minimizado, já que o usuário sob o qual ele roda não tem as permissões necessárias para realizar alterações críticas no sistema.

Usar uma conta como "superuser" ou "root" para executar serviços é uma prática insegura, pois esses usuários têm permissões amplas e, caso o serviço seja comprometido, um atacante poderia potencialmente ganhar controle total sobre o sistema. Portanto, o PostgreSQL, assim como outras aplicações sensíveis, não deve ser executado com essas contas altamente privilegiadas.

A alternativa correta é a C, porque a conta "nobody" é tradicionalmente utilizada para serviços que não devem ter permissões elevadas no sistema, diminuindo os riscos associados a falhas de segurança ou exploração de vulnerabilidades. Os outros nomes de usuário listados podem não seguir os mesmos princípios de segurança ou não ser contas padrão com baixos privilégios. Dessa forma, a alternativa C - nobody é a mais apropriada para preencher a lacuna, refletindo uma prática recomendada em termos de segurança para a execução deste tipo de processo em um servidor.