GCP ACE Practice / Study guide / Topics / Compute Engine Deployment & Operations
Compute Engine Deployment & Operations
What actually gets tested on the Google Cloud Associate Cloud Engineer exam,
the traps to know, and 6 free sample questions with full explanations.
gcloud compute instances create is the canonical way to create a VM, with --machine-type and --zone setting shape and placement (omitting --zone falls back to your configured default, which the exam likes to use as a "why did this land in the wrong place" trap). For repeatable, scalable deployment, an instance template plus a managed instance group (MIG) is the pattern to reach for — MIGs are how you get autoscaling, autohealing, and rolling updates, and almost any "deploy this at scale" scenario resolves to "create a template, then a MIG from it," not manually creating individual instances.
Bootstrapping runs through the startup-script metadata key, which Compute Engine executes on every boot (not just the first) — the standard way to configure a fresh instance without baking a fully custom image, though a custom image is the better answer when the setup is heavy enough that repeating it at every boot would be wasteful.
On day-2 operations: changing a running instance's machine type normally requires stopping it first for most machine-type changes, which is a common "why did this fail" setup in scenario questions. Remote access splits by OS — gcloud compute ssh manages keys and connects (through IAP tunneling when configured for internal-only VMs) for Linux, while reset-windows-password creates or resets a local Windows account and returns a password for RDP, since SSH isn't the default Windows path and no password is emailed automatically.
Exam tips for this topic
- "Deploy/scale automatically" almost always resolves to an instance template + managed instance group, not manually creating individual Compute Engine instances.
- Changing a running instance's machine type normally requires stopping it first — a frequent "why did this fail" setup in operations scenarios.
- startup-script runs on every boot, which makes it right for lightweight bootstrap and wrong (too repetitive/slow) for heavy setup — that's when a custom image is the better answer instead.
Sample questions — Compute Engine Deployment & Operations
These 6 questions are drawn from our full bank of 658 to show the style and
depth you'll get in the app. Each comes with the full explanation you'd see after answering
in a real practice session.
Compute Engine
You are provisioning your team's first VM: web-1, machine type e2-medium, in zone us-central1-a. Which command creates it?
- gcloud compute instances create web-1 --machine-type=e2-medium --zone=us-central1-aCorrect
- gcloud compute create instance web-1 --type e2-medium
- gcloud instances new web-1 e2-medium us-central1-a
- gcloud vm create web-1
Why: gcloud compute instances create is the canonical command; --machine-type and --zone set shape and placement (omitting --zone uses your configured default). The other forms are not valid gcloud syntax.
Compute ops
A Linux VM stopped responding to SSH entirely. Which built-in tool lets you see boot/kernel output and even log in for debugging?
- The serial console (view serial port output / enable interactive serial console)Correct
- Cloud Trace
- VPC Flow Logs
- The billing report
Why: Serial port output shows boot logs even when networking is broken, and the interactive serial console permits emergency login. Trace and flow logs won't show a hung boot.
Compute Engine
You need every new VM in your fleet to run a setup script automatically on first boot, with no manual steps. What do you use?
- A startup script via instance metadata (--metadata=startup-script=... or startup-script-url)Correct
- SSH in manually after boot
- A cron job created after the fact
- An image with the script name in its description
Why: Compute Engine executes the startup-script metadata key at boot (every boot, in fact). It's the standard bootstrap mechanism; manual steps don't scale to MIGs, and descriptions are inert text.
Compute ops
Snapshots of critical disks must be taken every 6 hours automatically, retaining 14 days. What do you configure?
- A snapshot schedule (resource policy) attached to the disksCorrect
- A sticky note reminder
- An instance template
- Live migration
Why: Snapshot schedules automate creation and retention/deletion per disk. Templates define new VMs and live migration is host maintenance — neither backs anything up.
Compute Engine
You need a shell on one of your Linux VMs to check application logs. How do you connect to it using gcloud?
- gcloud compute ssh web-1 --zone=us-central1-aCorrect
- gcloud compute rdp web-1
- gcloud connect web-1
- telnet web-1 22
Why: gcloud compute ssh manages keys and connects (through IAP tunneling if configured for internal-only VMs). RDP is the Windows path (via a generated password and an RDP client); the other commands don't exist or are insecure.
Compute ops
You resized disk data-1 on one of your VMs from 200GB to 500GB, but df -h inside the VM still shows 200GB. Why?
- The filesystem/partition must be grown inside the OS after the disk resizeCorrect
- The resize silently failed and must be retried
- Disks can't be resized
- df is broken on cloud VMs
Why: Cloud-level resize only enlarges the block device; the OS must extend the partition/filesystem (growpart + resize2fs/xfs_growfs; Windows Disk Management). This two-step is a classic ops gotcha.
Practice this for real
The app has dozens more questions on this and every other topic, with instant scoring,
spaced repetition of what you get wrong, and progress tracking across sessions.
Start practicing →
This topic shows up in
Other topics