At a hotel, the distribution authentication log shows a successful SSH login as a service account from the guest Wi-Fi range, and that account has previously been used only from the management VLAN. What is the lead?
Select an answer to reveal the explanation.
Short Explanation
A master key used from the guest lobby is a different problem than a broken elevator. You have a successful SSH for a service account from guest Wi-Fi, and that account normally comes only from the management VLAN. The trap is inventing an expired certificate, a database injection, or a mechanical failure.
Full Explanation
The distribution authentication log shows a successful SSH as the service account, and the new fact is the source network. That account has been used only from the management VLAN, so a success from the guest Wi-Fi range is an authentication from an unusual network. The lead the log supports is this: The service account authenticated successfully from a network outside its usual management range. A certificate story does not fit: The guest Wi-Fi certificate expired, so this service account was unable to complete the SSH login. That reading contradicts a record of success. A database story does not fit: The property-management database was changed by SQL injection at the time of this SSH login. An SSH success line is an authentication event, not a database statement. An equipment story does not fit: An elevator outage occurred in the hotel at the same moment this SSH login was written to the log. That is equipment state, not the content of the authentication log. On the exam, one unusual source does not name a person, and a success is not evidence that a certificate expired. In operations, compare the source address with the management range documented for that service account before you treat guest Wi-Fi as approved for it.