Deploying and implementing Compute Engine resources

Study guide for Associate Cloud Engineer, Unit 3 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Deploying and implementing Compute Engine resources. Considerations include:

1. Launching a compute instance (e.g., assign disks, availability policy, SSH keys)
2. Creating an autoscaled managed instance group by using an instance template
3. Configuring OS Login
4. Configuring VM Manager

Deploying and implementing Compute Engine resources

One machine, then many, then who may log in, then who keeps them patched

One instance — disks, availability, SSH keys. Many instances — an autoscaled managed instance group from an instance template. Who logs in — OS Login. Who keeps them current — VM Manager.

Unit 2 chose the platform and the machine shape. This topic is where an engineer actually builds, and its four objectives follow the life of a fleet. First, one instance: launching a compute instance, and the guide names three things to get right — its disks, its availability policy, and its secure shell (SSH) keys. Second, many instances: an autoscaled managed instance group, created from an instance template. Third, access: configuring OS Login, so that logging in to a virtual machine (VM) is governed by identity and access management (IAM) rather than by keys scattered through metadata. Fourth, upkeep: configuring VM Manager, Google's suite for keeping the operating system (OS) on a whole fleet patched and inventoried. Every slide here names the command or setting that does the work, because that is how this exam asks.

Launching a compute instance

Three decisions at launch: its disks, its availability, and who can connect

• Create: gcloud compute instances create, or the console's OS and storage section
• Disks: a boot disk, plus data disks attached at creation or later
• Availability: the host maintenance policy — live migrate, or stop and restart
• Access: SSH keys in project or instance metadata, or OS Login

Worked example (synthetic). An engineer launches a reporting VM with a second data disk, leaves it to live migrate during maintenance, and adds one colleague's key to that instance's metadata only — not the project's.

The first objective is launching an instance, and the guide's parenthesis tells you what it will test: disks, availability policy, and secure shell (SSH) keys. The launch itself is one command. Google's words: to create an instance with your own configuration, use the gcloud compute instances create command; in the console, the boot disk, the operating system (OS) and any additional non-boot storage are set in the OS and storage section. Disks come in two roles — Google says Persistent Disk can be a boot disk for an instance, or a data disk that you attach to one. Availability is set by what the guide calls an availability policy and Google now calls the host maintenance policy: it chooses how your instance responds during or after a host event. And access comes last: a virtual machine (VM) that does not use OS Login stores SSH keys in project and instance metadata. The next four slides take those one at a time.

Adding a data disk: three steps, not one

Create it, attach it, then format and mount it inside the guest

Worked example (synthetic). A team attaches a new disk and finds it missing from the VM's file system. Nothing failed: the third step, format and mount, was never run.

Adding a data disk is where hands-on candidates lose marks, because it is three steps and people remember two. Create the disk. Attach it: Google says after you create the disk, attach it to any running or stopped virtual machine (VM), using the gcloud compute instances attach-disk command — so there is no need to stop the instance first. Then the step that lives inside the guest rather than in Google Cloud: after you create the new disk and attach it to a VM, you must format and mount the disk, so that the operating system (OS) can use the available storage space. An attached, unformatted disk is present to Compute Engine and invisible to the application. If an exam item describes a disk that is attached and still not usable, the missing step is almost always this one.

The availability policy, in Google's words

The guide says availability policy; the setting is the host maintenance policy

Worked example (synthetic). An instance must come back by itself after a host error. The flag the exam wants is --restart-on-failure — maintenance behavior alone does not say what happens after a crash.

This is a naming mismatch worth knowing before the exam. The guide asks about an availability policy; Google's documentation calls the same thing the host maintenance policy, and splits it into settings. Maintenance behavior is whether the instance is live migrated or stopped when there is a maintenance event, set with the --maintenance-policy flag. Restart behavior is whether Compute Engine restarts or terminates the instance if it crashes, experiences a host error, or becomes unresponsive — include --restart-on-failure to restart automatically, or --no-restart-on-failure to prevent it. Both can be set at creation, and for an existing instance Google says to use the gcloud compute instances set-scheduling command. Keep the two settings apart: one answers what happens during planned maintenance, the other what happens after something breaks.

What a host event does to the instance

Live migration is the default; disks survive either path

Figure: A flow from a host maintenance event. With the default live migrate behavior the instance moves to a new host and keeps running. With stop, the instance is stopped, and restart behavior decides whether it is restarted automatically or stays stopped. On both paths the Persistent Disk data persists.

Worked example (synthetic). A web VM is on the default policy. During a maintenance event it keeps serving, because it was live migrated — nobody had to configure anything.

Drawn out, the policy is two questions in sequence. When a host event arrives, the first is maintenance behavior, and Google is explicit about the default: by default, most instances are set to live migrate during host events. During live migration Compute Engine moves your instance away from the maintenance event and your instance remains running during the migration. If the instance is set to stop instead, the second question applies — restart behavior — and that decides whether it comes back by itself. One reassurance holds on both paths: because Persistent Disk and Hyperdisk are network storage, Google says the data on those disks persists through live migration and instance restarts. So the policy decides whether the virtual machine (VM) keeps running, not whether its disk data survives.

Where SSH keys live, and who they reach

Project metadata reaches every VM; instance metadata reaches one

Figure. Three cards. Project metadata keys reach all VMs in the project except those blocking project-wide keys. Instance metadata keys reach one VM. OS Login ties keys to a Google identity and the guest agent ignores metadata keys. Beneath: connect with gcloud compute ssh; expired keys remain in metadata but cannot open new connections.

Worked example (synthetic). A contractor needs one VM and nothing else. Their key goes in that instance's metadata; in project metadata it would reach every VM that does not block project-wide keys.

The third launch decision is access, and the scope question is what the exam tests. For a virtual machine (VM) without OS Login, secure shell (SSH) keys live in metadata at two levels. Google says you can use keys stored in project metadata to access all VMs in a project — except VMs that block project-wide SSH keys — and keys stored in instance metadata to access individual VMs. So a key for one person and one machine belongs in instance metadata. There is a third arrangement, which the next objective covers, and it ties the operating system account to a Google identity: if OS Login is enabled for a VM, its guest agent ignores the keys stored in metadata altogether. Two operational details round this out. You connect with the gcloud compute ssh command. And Compute Engine does not automatically remove expired keys from metadata, though expired keys cannot establish new connections.

An autoscaled managed instance group from a template

The template says what each VM is; the group says how many and where

• Template: machine type, boot image, labels, startup script — saved once
• A MIG must be created from an instance template
• Templates can't be updated — create a new one instead
• Autoscaler: adds VMs as load rises, deletes them as it falls

Worked example (synthetic). A team needs a bigger machine type for its group. It cannot edit the template; it creates a new template with the new type and points the group at it.

The second objective joins two resources. An instance template, in Google's words, is a convenient way to save a virtual machine (VM) instance's configuration — machine type, boot disk image, labels, startup script and other properties. A managed instance group (MIG) is a group of VMs you treat as a single entity, and each VM in it is based on an instance template; Google is firm that if you want a group of identical VMs, you must create the MIG using an instance template. Two template rules are tested often. You cannot update an instance template after it is created — you create a new one. And unless you need to reuse a template across regions, Google recommends regional templates over global ones. Autoscaling is what makes the group elastic: an autoscaler adds or deletes instances based on the group's autoscaling policy, adding VMs when load rises and deleting them when it falls.

Three commands, in order

Template, then group, then autoscaler

Figure: Three commands in sequence: create the instance template, using the instance template region flag for a regional template; create the managed instance group from that template with a size and an optional health check; then set autoscaling, where the maximum number of replicas is required alongside a target CPU utilization.

Worked example (synthetic). An engineer runs set-autoscaling with a CPU target and no maximum, and the command is refused. The maximum number of replicas is required when creating an autoscaler.

On the command line the objective is three commands, and the order is forced because each consumes the one before. First the template: gcloud compute instance-templates create — and Google notes that for a regional template you must use the --instance-template-region flag. Second the group: gcloud compute instance-groups managed create, pointing at the template and giving a size; the same command can attach a health check at creation. Third the autoscaler: Google says to use the set-autoscaling sub-command to enable autoscaling for a managed instance group (MIG), and it states a requirement candidates miss — along with the --target-cpu-utilization parameter, the --max-num-replicas parameter is also required when creating an autoscaler. The target is written as a fraction of central processing unit (CPU) capacity. An autoscaler must also always have at least one scaling signal; CPU is simply the most common one.

A regional MIG, and what it recreates

Two zones for resilience — and disks that go with their VM

Figure. Users send requests to Cloud Load Balancing, which spreads them across a regional managed instance group with one VM in zone a and one in zone b, both created from the same instance template. Each VM has an attached Persistent Disk. The callout notes that the autoscaler adds and deletes VMs, autohealing recreates unhealthy ones, and their disks are recreated too unless the group is stateful.

Worked example (synthetic). A team stores uploaded files on a MIG VM's attached disk. After autohealing recreates the VM, the files are gone — the default recreates disks with their VM.

This is the group the objective builds, drawn so the two traps are visible. A regional MIG spreads its virtual machines (VMs) across zones; Google gives the reason as distributing VMs across multiple zones in a region to protect against zonal failure. Every VM is stamped from the same template, and that has a location consequence: if a template names a zonal resource, Google says that restricts the template to that resource's zone. The second trap is the disks. The default behavior for all persistent disks in a managed instance group (MIG) is to delete or recreate them when their VM is deleted or recreated, so you should not rely on attached disks as persistent data. Autohealing makes that concrete: if a health check finds an application not responding, the MIG marks the VM unhealthy and repairs it by default. If data must survive, the group needs stateful configuration — disks that retain data whenever VMs are autohealed, updated or recreated.

The autoscaler's settings, and what each one prevents

Signals, a ceiling, a warm-up, and a repair

Worked example (synthetic). A group keeps adding VMs during every deployment because new VMs show high CPU while they boot. Lengthening the initialization period stops that.

Four settings decide whether an autoscaled group behaves. The scaling signal: Google says an autoscaling policy must always have at least one. The ceiling: the maximum number of replicas, required alongside a central processing unit (CPU) target. The warm-up, which Google now calls the initialization period — formerly the cool down period — is the time it takes for applications to initialize on your virtual machine (VM) instances, and it matters because for scale-out decisions the autoscaler ignores usage data from instances still initializing. Set it too short and every busy new VM looks like more load. And the repair: autohealing, which Google defines as repairing a VM based on an application-based health check. Autoscaling changes how many VMs there are; autohealing replaces the ones that are broken. An exam item that mixes them is usually testing exactly that difference.

Configuring OS Login

SSH access governed by IAM, instead of keys spread through metadata

• Enable: enable-oslogin=TRUE in project or instance metadata
• Effect: metadata SSH keys are no longer accepted
• Access follows IAM — removing permissions revokes access
• Recommended by Google for many users across many VMs or projects

Worked example (synthetic). An engineer leaves the company. With OS Login, removing their IAM grants ends their access to every VM at once; with metadata keys, someone must find and delete each key.

The third objective replaces key management with identity. Google's description: use OS Login to manage secure shell (SSH) access to your instances using identity and access management (IAM), without having to create and manage individual SSH keys — and it calls OS Login the recommended way to manage many users across multiple compute instances or projects. Configuring it is one metadata value. You can enable OS Login for a single virtual machine (VM), or all VMs in a project, by setting enable-oslogin to TRUE in project or instance metadata; at creation that is --metadata enable-oslogin=TRUE. Know the side effect: when you set OS Login metadata, Compute Engine deletes the VM's authorized_keys files and no longer accepts connections from SSH keys stored in metadata. The payoff is revocation. If you remove IAM permissions from a Google identity, access to compute instances is revoked, because Google checks permissions for every login attempt. The operating system (OS) account simply follows the identity.

OS Login's roles and switches

Two login roles, a second factor, and a way back

Worked example (synthetic). A developer can log in to a VM but cannot run sudo. They hold roles/compute.osLogin; administrative access needs roles/compute.osAdminLogin.

Once OS Login is on, access is a matter of which role a person holds. Google defines two: roles/compute.osLogin grants login access without sudo access, and roles/compute.osAdminLogin grants login access with sudo access. So a user who can connect but cannot administer the operating system (OS) has the first and needs the second. A second factor is available, with one catch the exam likes: for OS Login two-factor authentication to be enforced, both the enable-oslogin and the enable-oslogin-2fa metadata values must be set to TRUE — setting only the second does nothing. And the switch works in reverse: when OS Login is disabled, you can connect to your virtual machines (VMs) using secure shell (SSH) keys stored in metadata again. One caution from Google's page is worth carrying out of this slide: a user who connects to a VM can use every identity and access management (IAM) permission granted to the service account attached to it.

Configuring VM Manager

Patch, inventory and OS policies for a whole fleet

• Patch: on-demand and scheduled patching, with compliance reporting
• OS inventory management: collect and review OS information
• OS policies: install, remove and auto-update software packages
• Scope: one VM, a project, or every project in a folder or organization

Worked example (synthetic). An operations team must prove every Linux VM got last month's security update. VM Manager's Patch service applies it on a schedule and reports compliance.

The fourth objective is upkeep at fleet scale. Google describes VM Manager as a suite of tools to manage operating systems for large virtual machine (VM) fleets running Windows and Linux on Compute Engine, and it has three services, each with one job. Patch applies on-demand and scheduled patches, and can also be used for patch compliance reporting. OS inventory management collects and reviews operating system (OS) information. OS policies install, remove and auto-update software packages. When a scenario asks you to keep a fleet current, prove it is current, or know what is installed on it, those are the three services in that order. Scope is flexible: Google says you can enable VM Manager for individual VMs, for a project, or for all projects in a folder or organization. The next slide is what enabling it actually involves.

Turning VM Manager on

An API, an agent, and a metadata value — or a policy that sets it

Figure. Three numbered steps: enable the OS Config API with gcloud services enable osconfig.googleapis.com; check the OS Config agent is installed on each VM, since VM Manager cannot be enabled where no agent exists for that OS; set the agent's metadata on the project or each VM. Beneath: the Require OS Config organization policy sets the metadata for new VMs only, not for VMs or projects created before it.

Worked example (synthetic). A team applies the Require OS Config policy and expects its existing VMs to appear in VM Manager. They don't — the policy sets metadata for new VMs; the existing ones need their metadata updated.

Enabling VM Manager is three pieces, and an exam item usually removes one. The application programming interface (API): Google says to enable the OS Config API in your project — gcloud services enable osconfig.googleapis.com is the command. The agent: on each virtual machine (VM), check the OS Config agent is installed, and note the hard limit — if the agent is not available for a particular operating system (OS), you cannot enable VM Manager for a VM running it. The metadata: on either the project or each VM, set the metadata for the OS Config agent. At organization scale there is a shortcut, the Require OS Config organization policy, which automatically sets the VM Manager metadata for all new VMs in an organization, folder or project. Read the word new. Google states that this policy does not change the enable-osconfig metadata for VMs or projects created before it was enabled; for those, you update the metadata yourself.

What this topic actually tests

Four objectives, each with one step candidates skip

Disks: attach, then format and mount. Availability: the host maintenance policy — live migrate by default. MIGs: templates can't be edited; disks are recreated with their VM. OS Login: metadata keys stop working; sudo needs osAdminLogin. VM Manager: API, agent and metadata — the org policy only reaches new VMs.

Each objective in this topic has one step that candidates skip, and the exam is built around those steps. Launching an instance: an attached data disk still has to be formatted and mounted inside the operating system (OS), and the guide's availability policy is Google's host maintenance policy, which live migrates by default. The autoscaled group: an instance template cannot be updated, so a change means a new template; the maximum number of replicas is required when you create a CPU-based autoscaler; and a managed instance group (MIG) recreates disks along with their virtual machine (VM) unless it is stateful. OS Login: once enable-oslogin is TRUE, secure shell (SSH) keys in metadata stop being accepted, and sudo needs roles/compute.osAdminLogin rather than roles/compute.osLogin. VM Manager: the application programming interface (API), the agent and the metadata must all be present, and the Require OS Config policy only reaches new VMs. Hold those five and this topic's scenarios become recognition rather than recall. The central processing unit (CPU) target is the one number you will set, and it is always written as a fraction.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 3
• Create and start a Compute Engine instance
• Add a Persistent Disk to your VM — Compute Engine
• Host maintenance overview — Compute Engine
• Add SSH keys to VMs — Compute Engine
• Instance templates — Compute Engine
• Basic scenarios for creating managed instance groups — Compute Engine
• Autoscaling groups of instances — Compute Engine
• About OS Login — Compute Engine
• Set up OS Login — Compute Engine
• VM Manager — Compute Engine
• Set up VM Manager — Compute Engine
• Set instance host maintenance policy — Compute Engine
• Connect to Linux VMs — Compute Engine
• Create instance templates — Compute Engine
• Scaling based on CPU utilization — Compute Engine
• Set up an application health check and autohealing — Compute Engine