Compute Engine gives you the VM, but a fresh VM does not automatically stream its application logs or system metrics anywhere useful. You have to install something to collect that telemetry, and you have to decide whether the instance can be deleted with a single click. Both of those decisions show up on the Professional Cloud Architect exam, usually framed as a scenario where something has gone wrong and you have to pick the missing piece.
If you spin up a Compute Engine VM and look for its application logs in Cloud Logging, you will not find them. The same goes for system-level metrics in Cloud Monitoring beyond the basic infrastructure signals that Compute Engine reports for free. To get the richer telemetry off the instance and into Google Cloud's observability stack, you install the Ops Agent.
The Ops Agent is a single agent that handles both sides of the pipeline. It collects application logs and system metrics from inside the VM and exports them to Cloud Logging and Cloud Monitoring respectively. Once it is running, you can build dashboards on the metrics, set up alerting policies that fire when thresholds are breached, and search through logs in the same console you use for the rest of your Google Cloud environment.
On the Professional Cloud Architect exam, the trigger phrase is usually something like "the team needs to troubleshoot performance issues on a Compute Engine instance" or "application logs from the VM should be searchable in Cloud Logging." The correct answer in those scenarios is almost always to install the Ops Agent on the instance. If a question describes a VM where logs or metrics are missing from Google Cloud's observability tools, the gap is the agent.
One thing worth being clear on: the Ops Agent is not installed by default. Standard Compute Engine images do not ship with it running. You either install it manually, bake it into a custom image, or push it through a startup script or configuration management tool. For fleets of any size, automating the install is the right move so you do not end up with a mix of instrumented and uninstrumented instances.
Delete protection is a simpler feature, but it solves a real problem. Without it, anyone with the right IAM permissions can delete an instance, and once it is gone, the disks and any unsaved state can go with it. For production workloads, that is a one-click path to an outage.
Enabling delete protection adds a guard. The instance cannot be deleted while the flag is on. To delete it, you first have to go in and turn delete protection off, and then issue the delete. It does not change who has permission to delete the instance, it just adds a deliberate two-step process so accidental deletions become very hard to perform.
You can enable delete protection at instance creation, or you can flip it on later through the Management section of the instance settings. Either way, it is a checkbox-level change with no performance cost and no impact on how the workload runs. The only operational difference shows up at deletion time.
For the Professional Cloud Architect exam, the scenarios are straightforward. If a question describes a critical production VM where accidental deletion would cause downtime or data loss, and asks how to safeguard it, delete protection is the answer. It is not a substitute for backups or for IAM hygiene, but it stops the specific failure mode of a teammate clicking delete on the wrong resource.
These two features sit on opposite sides of the operational lifecycle. The Ops Agent is about visibility, making sure you can see what an instance is doing while it is running. Delete protection is about preservation, making sure the instance stays around until you genuinely intend to remove it. For any workload important enough to monitor, it is usually important enough to protect from accidental deletion as well.
My Professional Cloud Architect course covers Compute Engine monitoring, logging, and delete protection alongside the rest of the compute material.
