A SaaS company can inspect its guest operating systems in the provider cloud but has no access to the hypervisor logs the provider keeps. What visibility gap does that boundary describe?
Select an answer to reveal the explanation.
Short Explanation
Picture a rented floor in someone else's building: you can search your offices, but the landlord's camera room stays locked. Your guest operating systems sit on your side of the shared-responsibility line, and the hypervisor logs stay with the provider. The trap is blaming office NAT, a mail filter, or a hosts file for a gap those controls never create.
Full Explanation
The SaaS company can read its guest operating systems and cannot read the provider hypervisor logs. That split is the shared-responsibility line: guest telemetry stays with the customer, and the hypervisor stays with the provider. The gap is "Cloud visibility stops at the shared-responsibility line, short of the hypervisor logs". Office address translation rewrites packets on the company firewall. It does not withhold a hypervisor log the provider never shipped, so "Network address translation on the office firewall is hiding the provider hypervisor logs" does not explain the missing records. A mail filter acts on mail. It is not in the path of hypervisor audit data, so "A mail filter on the company mail gateway is dropping hypervisor log messages before delivery" fails. A hosts file only changes local name lookups on the guest. It cannot reveal or conceal the provider control plane, so "A local hosts file on the guest is blocking the name used to reach the hypervisor logs" fails. Exam caveat: the line moves with the service model, and this scenario is the case where the customer holds the guest and the provider holds the hypervisor. Operational check: export the log list the SaaS company can actually pull and confirm hypervisor logs are absent there and remain on the provider side of the line.