Hidden SSID vs. credential failures in WLAN client discovery

The visibility test decides it

The question says the client fails to see the enterprise SSID, while other clients are already connected. That asymmetry is the whole diagnostic: an SSID that others join is being broadcast normally, so this is not a global AP or controller problem — it is a client-side view problem. Two distinct failure layers exist here, and the exam is testing whether you can tell them apart: association/authentication failure (client sees the SSID but cannot join) versus discovery failure (client never sees the SSID at all).

Hidden (cloaked) SSIDs and discovery

When an SSID is configured as hidden — network cloaking — the AP simply omits it from beacon frames. A client cannot "see" it in a scan; the only way to reach it is to enter the SSID manually, after which the client probes for it directly. Option B describes exactly this: the hidden SSID was not manually configured on the client. This matches the reported symptom precisely, and one comment argues for B on precisely these grounds, citing the network-cloaking behaviour.

Why the credential options are wrong

Options A and D talk about incorrect stored credentials. Wrong credentials produce an association or 4-way-handshake failure: the client would still list the SSID and then fail to connect — a different symptom than "cannot see". They also presuppose knowing whether the SSID is broadcast or hidden, which the scenario never states. Option C is self-defeating: a broadcast SSID needs no manual entry, and if it were unconfigured the client would simply join it after scanning.

Therefore the correct choice is B — the cloaked SSID requires manual entry on that client, and its absence from the client's scan is why it appears to be missing.