Explicando por partes...
O enunciado já nos mostra que A determina os demais atributos (B, C, D). Como A identifica uma tupla de forma única, ela é uma chave candidata.
Agora percebam a relação entre A e C:
a ➝ c
c ➝ a
A e C são determinantes equivalentes, tudo que A determina, C também determinará. Assim, C também é chave candidata.
Agora percebam a relação entre B e C:
b ➝ c
Se B determina C e C é chave candidata, então B também determinará tudo que C determina e B também será chave candidata.
O que a gente faz quando uma tabela possui mais de 1 chave candidata?
"quando um esquema de relação tem várias chaves candidatas, a escolha de uma para se tornar a chave primária é um tanto quanto arbitrária; porém, normalmente é melhor escolher uma chave primária com um único atributo ou um pequeno número de atributos. As outras chaves candidatas são designadas como chaves únicas (unique keys)" Navathe
-> Uma das chaves candidatas vira PK (que por definição é unique) e as demais ficam com a restrição unique. GAB E é a única alternativa em que temos as 3 chaves candidatas marcadas individualmente como unique
Por que não é Letra C?
Imagina uma tabela Pessoa com as chaves candidatas: id_pessoa, CPF e RG. Se a restrição de unicidade contemplasse os 3 atributos de forma conjunta, poderia haver situações de mais de uma pessoa com o mesmo CPF desde que RG ou id_pessoa fossem diferentes. Não faria sentido permitir isso no banco
Se a,b,c,d são colunas da tabela, deve-se criar uma restrição para cada uma a fim de evitar a repetição de dados, reduzir a redundância com a normalização.
Será criada uma restrição para cada coluna, a,b,c,d.