VM access & lifecycle

Exam guide§2.1

Once a VM exists you connect to it, drive it through its lifecycle states, and keep its OS patched. For machine types, sizing, and pricing see Compute Engine.

VM access

• OS Login ties SSH access to IAM (recommended, centrally managed). Enable via metadata enable-oslogin=TRUE (project- or instance-level).
• Roles: roles/compute.osLogin (standard) and roles/compute.osAdminLogin (sudo).
• Alternative: metadata SSH keys - manual key management, no IAM link.

⚠GotchaOS Login overrides metadata keys

When enable-oslogin=TRUE, project/instance SSH-key metadata is ignored. Grant IAM roles instead of adding keys. For external (non-org) users you also need roles/compute.osLoginExternalUser.

#NumbersAccess ports & Windows RDP

• The instance creator has full root. On Linux they hold SSH and can grant SSH to other users from the Console.
• Windows VMs: the creator generates a username + password in the Console; anyone with those connects via an RDP client.
• Firewall rules required: tcp:22 (SSH), tcp:3389 (RDP). You do not need to define these on the default network - it already allows them.

Availability policy

• On host maintenance: MIGRATE (default, live migration) or TERMINATE.
• Automatic restart: on by default; VM restarts after a crash/maintenance (not for preemption or a user-initiated terminate).
• Spot/preemptible VMs cannot live migrate - they always TERMINATE.
• Called scheduling options in the SDK/API; configurable both at creation and while the VM is running.

Lifecycle

The full VM lifecycle. A VM boots PROVISIONING → STAGING → RUNNING; from RUNNING you can suspend/resume, or stop it into TERMINATED (the "stopped" state) and start it again. REPAIRING is an unbilled, no-SLA state Google enters on host failure. Every transition maps to an instances.* API call.

≡FactsLifecycle states beyond the core loop

• SUSPEND → SUSPENDED: pauses the VM (like sleep) and preserves memory to disk; resume it later or delete it. instances.suspend() / instances.resume().
• RESET: wipes memory contents and reboots to the initial state; the VM stays RUNNING throughout (like the physical reset button).
• REPAIRING: entered on an internal error or when the host is down for maintenance; the VM is unusable while repairing. Not billed and not covered by the SLA in this state. It returns to a prior state if repair succeeds.
• RESTART from TERMINATED sends the VM back to PROVISIONING; from TERMINATED you can also delete it.

Method	How	Shutdown script window	State change
reset	console, gcloud, API, OS	no script runs	remains running
start	console, gcloud, API	no script runs	terminated → running
reboot	OS: sudo reboot	~90 sec	running → running
stop	console, gcloud, API	~90 sec	running → terminated
shutdown	OS: sudo shutdown	~90 sec	running → terminated
delete	console, gcloud, API	~90 sec	running → N/A (gone)
preemption	automatic (Spot/preemptible)	~30 sec, then ACPI G3 off	→ terminated

⚠GotchaPreemptible shutdown scripts get only ~30s

Reboot/stop/delete allow the shutdown script ~90 seconds. A preemptible/Spot VM only gets ~30 seconds; if it hasn't stopped, Compute Engine sends an ACPI G3 (mechanical off) signal. Keep preemptible shutdown scripts short.

⚠GotchaSome properties are fixed at creation

The name, zone, CPU platform, and preemptibility are set at creation and can never be changed. Machine type can change, but only while STOPPED. Changing the network interfaces (NICs) requires recreating the instance - but you can keep the boot disk and reattach it to the new VM.

≡FactsBilling & allowed actions while TERMINATED (stopped)

• Not billed for memory and CPU. Still billed for attached persistent disks and reserved (static) IP addresses.
• Allowed while stopped: change machine type, migrate the instance to another network, add/remove disks or change auto-delete, modify tags, modify instance or project-wide metadata, set/remove a static IP, change the availability policy.
• Cannot change the boot image of a stopped VM.
• Not everything needs a stop - e.g. availability policy can also be changed while RUNNING.

Metadata server & startup/shutdown scripts

Every VM stores its metadata on a metadata server. A VM can query this server to programmatically get unique information about itself (external IP, project, instance name, ...) without any additional authorization - which is what makes it so useful inside startup and shutdown scripts.

≡FactsWhy the metadata server matters

• The default metadata keys are identical on every instance, so a script that reads, say, the external IP key works unchanged on any VM - no per-instance edits.
• That reuse produces less brittle application code.
• Storing and retrieving instance metadata is one of the most common Compute Engine actions.

⚠GotchaStore startup/shutdown scripts in Cloud Storage

Rather than pasting a script into instance metadata, point startup-script-url / shutdown-script-url at a Cloud Storage object. The script is centralized, versioned, and reused across instances instead of copied into each VM's metadata. (Shutdown-script timing windows are in the lifecycle table above.)

OS patch management

Apply OS patches across a fleet of Compute Engine VMs (Windows and Linux) from one place, so long-running VMs stay defended against defects and vulnerabilities.

≡FactsTwo components

• Patch compliance reporting - insights and recommendations on the patch status of your VMs across Windows and Linux distributions.
• Patch deployment - automates the update process. A deployment schedules patch jobs; a patch job runs across VMs and applies patches.

• Patch approvals - select which patches from the available set get applied.
• Flexible scheduling - one-time or recurring patch windows.
• Advanced config - pre- and post-patch scripts.
• Manage all patch jobs from a centralized location.

⚠GotchaPremium images bundle patch cost

A premium image (e.g. Windows, RHEL) carries a cost that covers both OS usage and OS patch management. That's baked into the image price, separate from the compute charge.