Q: 4

A cloud administrator needs to collect process-level, memory-usage tracking for the virtual machines that are part of an autoscaling group. Which of the following is the best way to accomplish the goal by using cloud-native monitoring services?

Options

Discussion

Ishaan W. Aug 18, 2026 2:52 am

B. not D. D only shows total VM memory, not process-level which the question asks for.

Chris U. Sep 1, 2026 5:18 pm

Option B

Daniel J. Sep 5, 2026 12:57 am

B or D? Had something like this in a mock, picked B for per-process detail.

TaylorF Sep 6, 2026 1:45 pm

Nora U. Sep 3, 2026 12:05 am

D , because enabling memory monitoring in the VM config seems like it should let you track usage without extra agents. But now I'm not sure if that gets down to process-level details. Anyone else tripped up by this wording?

Aisha O. Sep 4, 2026 4:01 pm

B tbh, since cloud-native memory monitoring (D) usually just gives you the total VM memory, not process-level info. Only deploying the agent gets you that detailed breakdown. I remember AWS and Azure both needing agents for this, correct me if that's changed.

Skyler V. Aug 31, 2026 8:34 pm

C or D here. Scripts can grab process-level memory stats and run on schedule, which I've seen in practice labs. Official guide mentions agent install more, but for quick data collection without extra software, a script could work too. Anyone see C used in practice tests?

Ben E. Aug 28, 2026 5:37 am

B , the monitoring agent is really the only cloud-native way to get actual process-level and memory usage. Official guides and labs both mention deploying these agents for deep OS stats. Open to other thoughts but that's what I've seen most in practice tests.

Piya C. Aug 27, 2026 9:42 pm

You'd need B for process-level details, since the built-in memory metrics (like in D) usually only show you the whole VM. The cloud-native monitoring agent gets inside the OS and grabs that per-process and memory info. Pretty sure that's how AWS and Azure do it, too. Let me know if I'm missing something from recent updates.

MeeraP Aug 22, 2026 5:38 pm

Looks like B is the way to go here. Native memory monitoring (like D) gives you overall usage but won't break it down by process, which is what the question wants. You need the agent installed inside the VM to get process-level stats-it's a classic trap to pick D just because it sounds easy. Pretty sure that's how AWS and Azure do it too, correct me if I'm wrong.

Be respectful. No spam.

Correct Answer:

Explanation

Cloud-native monitoring services (like AWS CloudWatch, Azure Monitor, or Google Cloud's operations suite) provide high-level metrics from the hypervisor by default, such as overall CPU utilization for a VM. However, to collect detailed in-guest operating system data, such as process-level memory usage, it is necessary to install a dedicated monitoring agent. This agent software runs inside the VM, collects the specified metrics directly from the OS, and sends them to the cloud monitoring service. For an autoscaling group, the agent is installed on the base machine image, ensuring all new instances automatically report these detailed metrics, making it the most effective and scalable solution.

Why Incorrect

A. Configuring page file/swap metrics: This only tracks the usage of virtual memory on disk, which is an indicator of memory pressure, not a direct measurement of memory usage by individual processes.

C. Scheduling a script to collect the data: This is a custom, non-native solution. While possible, it requires manual development and maintenance and is less integrated and reliable than using the purpose-built agent provided by the cloud platform.

D. Enabling memory monitoring in the VM configuration: This option typically enables hypervisor-level memory metrics, which report the total memory consumed by the VM as a whole, but lack the visibility to report on individual processes running inside the guest OS.

References

1. Amazon Web Services (AWS) Documentation. The CloudWatch agent is required to collect guest OS-level metrics. "By default

EC2 instances send hypervisor-visible metrics to CloudWatch... To collect metrics from the operating system or from applications

you must install the CloudWatch agent."

Source: AWS Documentation

"The metrics that the CloudWatch agent collects

" Section: "Predefined metric sets for the CloudWatch agent."

2. Microsoft Azure Documentation. The Azure Monitor agent is used to collect in-depth data from the guest operating system of virtual machines. "Use the Azure Monitor agent to collect guest operating system data from Azure... virtual machines... It collects data from the guest operating system and delivers it to Azure Monitor."

Source: Microsoft Learn

"Azure Monitor agent overview

" Introduction section.

3. Google Cloud Documentation. The Ops Agent is Google's solution for collecting detailed telemetry from within Compute Engine instances. "The Ops Agent is the primary agent for collecting telemetry from your Compute Engine instances. It collects both logs and metrics." The agent can be configured to collect process metrics.

Source: Google Cloud Documentation

"Ops Agent overview

" What the Ops Agent collects section.

4. Armbrust

et al. (2010). A View of Cloud Computing. This foundational academic paper from UC Berkeley discusses the challenges of cloud monitoring

implying the need for mechanisms beyond the hypervisor to understand application-level performance. The distinction between what the infrastructure provider can see (hypervisor-level) and what the user needs to see (in-guest) necessitates agent-based approaches for detailed monitoring.

Source: Communications of the ACM

53(4)

50-58. Section 5.3

"Monitoring and Auditing." DOI: https://doi.org/10.1145/1721654.1721672

A cloud administrator needs to collect process-level, memory-usage tracking for the virtual machines that are part of an autoscaling group. Which of the following is the best way to accomplish the goal by using cloud-native monitoring services?

Premium Access Includes