This gives visibility into both host activity and network metadata, which is needed for practical monitoring and investigation.
Why this answer
Option B is correct because deploying an endpoint logging agent (e.g., auditd, osquery, or a SIEM agent) on the Linux VM captures OS login events and process activity at the guest level, while enabling cloud-native flow logs (e.g., AWS VPC Flow Logs, Azure NSG flow logs) provides network flow metadata. Sending both to a centralized logging service (e.g., AWS CloudWatch Logs, Azure Log Analytics, or a third-party SIEM) ensures all required telemetry is aggregated for alerting. This approach directly addresses the need for host-level and network-level visibility without relying on the cloud provider to collect guest OS internals.
Exam trap
The trap here is that candidates may assume cloud providers automatically collect guest OS telemetry (like login events and process activity) when they only provide infrastructure-level logs (e.g., hypervisor or network flow logs), leading them to choose Option A or D incorrectly.
How to eliminate wrong answers
Option A is wrong because perimeter security groups only filter network traffic at the cloud boundary and do not collect OS login events, process activity, or network flow metadata; the cloud provider does not automatically collect host-level telemetry from guest VMs. Option C is wrong because storing VM snapshots in object storage is a backup/recovery method, not a real-time logging solution, and manual review during incidents is too slow and impractical for continuous alerting. Option D is wrong because relying solely on the hypervisor console provides only hypervisor-level logs (e.g., VM start/stop), not guest OS login events or process activity, and disabling guest-level logging removes the very data needed for security monitoring.