{"id":636,"date":"2026-04-14T20:26:48","date_gmt":"2026-04-14T20:26:48","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-vm-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/"},"modified":"2026-04-14T20:26:48","modified_gmt":"2026-04-14T20:26:48","slug":"google-cloud-vm-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-vm-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/","title":{"rendered":"Google Cloud VM Manager Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Compute<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>VM Manager is Google Cloud\u2019s operating-system (OS) management toolkit for Compute Engine virtual machine fleets. It helps you keep VMs patched, understand what software is installed, and enforce baseline OS configuration\u2014without having to log in to each instance.<\/p>\n\n\n\n<p>In simple terms: <strong>VM Manager lets you patch and audit many VMs from one place<\/strong>. You define which VMs should be updated (for example, \u201call production web servers\u201d), when updates should run (maintenance windows), and how results should be reported.<\/p>\n\n\n\n<p>Technically, VM Manager is primarily a <strong>Google Cloud Console experience plus APIs<\/strong> (most notably the <strong>OS Config API<\/strong>) that coordinate patching and inventory collection through an <strong>OS Config agent<\/strong> running inside each VM. VM Manager integrates with Compute Engine (instances, labels, instance groups), Cloud Logging (audit and operational visibility), and IAM (access control). It is designed for both ad hoc operations (run a patch job now) and scheduled operations (recurring patch deployments).<\/p>\n\n\n\n<p>The core problem VM Manager solves is <strong>operational control and compliance at scale<\/strong>: reducing exposure from unpatched vulnerabilities, producing inventory evidence for audits, and standardizing OS configuration across many VMs\u2014without building and maintaining your own patch orchestration platform.<\/p>\n\n\n\n<p><strong>Service naming note (important):<\/strong> In current Google Cloud documentation and APIs, many VM Manager capabilities are implemented by the <strong>OS Config<\/strong> service (OS Config API). VM Manager remains a widely used name in the Console and Compute documentation as the \u201csuite\u201d that provides these OS management workflows.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is VM Manager?<\/h2>\n\n\n\n<p>VM Manager is a set of Google Cloud Compute capabilities used to <strong>manage operating systems for Compute Engine VMs<\/strong>. Its official purpose is to provide centralized tools for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OS patch management<\/strong> (on-demand patch jobs and scheduled patch deployments)<\/li>\n<li><strong>OS inventory<\/strong> (what OS version, packages, and software are installed)<\/li>\n<li><strong>OS configuration policy<\/strong> (enforcing desired state, commonly via OS policies \/ OS policy assignments)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Target groups of VMs using <strong>zones\/regions, instance names, or labels<\/strong><\/li>\n<li>Execute <strong>patch operations<\/strong> across fleets with reporting and success\/failure status<\/li>\n<li>Collect and view <strong>inventory metadata<\/strong> from the guest OS<\/li>\n<li>Enforce baseline configuration (for example, \u201cpackage X must be installed\u201d, \u201cservice Y must be running\u201d)<\/li>\n<li>Provide API-driven automation via the <strong>OS Config API<\/strong>, enabling Infrastructure-as-Code and CI\/CD integration<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud Console (VM Manager UI):<\/strong> Human-friendly workflow for patching and viewing inventory.<\/li>\n<li><strong>OS Config API:<\/strong> The control plane API that schedules patching, inventory collection, and policy evaluation.<\/li>\n<li><strong>OS Config agent:<\/strong> Guest agent that runs inside the VM to apply patches, report results, and collect inventory.<\/li>\n<li><strong>IAM + Audit Logs:<\/strong> Controls who can run patch jobs, view inventory, and change policy; logs changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed control plane + guest agent<\/strong> model:<\/li>\n<li>The control plane is hosted and managed by Google.<\/li>\n<li>The agent runs in your VM and executes OS-level actions locally (package manager, Windows Update, file\/service state).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (how it\u2019s organized)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Project-scoped:<\/strong> You manage VM Manager operations within a Google Cloud project.<\/li>\n<li><strong>Fleet-wide across zones\/regions in a project:<\/strong> You can target VMs across multiple zones.<\/li>\n<li><strong>Control plane is effectively global:<\/strong> You access it via APIs\/Console; your VMs can be in any supported region\/zone.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>VM Manager sits in the <strong>Compute<\/strong> operational layer:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Works directly with <strong>Compute Engine instances<\/strong> (and their labels\/service accounts)<\/li>\n<li>Complements monitoring agents like the <strong>Google Cloud Ops Agent<\/strong> (VM Manager is about OS management; Ops Agent is about telemetry)<\/li>\n<li>Supports governance with <strong>IAM, Cloud Audit Logs, and Cloud Logging sinks<\/strong><\/li>\n<li>Helps security posture by reducing patch lag and improving inventory evidence<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use VM Manager?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce risk and downtime:<\/strong> Faster response to security advisories and critical vulnerabilities.<\/li>\n<li><strong>Audit readiness:<\/strong> Inventory and patch reports help demonstrate control for internal governance and external audits.<\/li>\n<li><strong>Operational efficiency:<\/strong> Centralize patch orchestration and reduce manual SSH\/RDP work.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Fleet targeting:<\/strong> Use labels and projects to apply actions to hundreds\/thousands of VMs consistently.<\/li>\n<li><strong>Repeatable operations:<\/strong> Schedule recurring patch deployments and standardize configuration.<\/li>\n<li><strong>API-driven automation:<\/strong> Integrate patching into change management pipelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Visibility into success\/failure:<\/strong> Get job-level and per-VM results rather than guessing what updated.<\/li>\n<li><strong>Controlled rollout:<\/strong> Reduce blast radius by patching canaries first and scaling out.<\/li>\n<li><strong>Reduced toil:<\/strong> Minimize ad hoc patch scripts and \u201csnowflake\u201d VM handling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least-privilege operations with IAM:<\/strong> Separate \u201cwho can execute patch jobs\u201d from \u201cwho can view results\u201d.<\/li>\n<li><strong>Centralized auditing:<\/strong> Use Cloud Audit Logs to track patch job creation and configuration changes.<\/li>\n<li><strong>Baseline enforcement:<\/strong> OS policies can ensure required packages\/services\/files are present.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Designed for fleets:<\/strong> Avoid serial manual patching. Use orchestration built for many instances.<\/li>\n<li><strong>Minimal control-plane overhead:<\/strong> VM actions happen locally on VMs; the control plane coordinates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose VM Manager<\/h3>\n\n\n\n<p>Choose VM Manager when you:\n&#8211; Run <strong>Compute Engine VM fleets<\/strong> and need patch\/inventory at scale\n&#8211; Need <strong>scheduled patch windows<\/strong> and consistent reporting\n&#8211; Want a <strong>Google-native<\/strong> approach instead of operating a separate patch orchestration platform\n&#8211; Prefer managing VMs with labels and projects rather than per-VM scripts<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose VM Manager<\/h3>\n\n\n\n<p>VM Manager may not be the best fit when:\n&#8211; You use <strong>immutable infrastructure<\/strong> exclusively (rebuild images and replace instances, never patch in-place)\n&#8211; Your workloads primarily run in <strong>GKE<\/strong> (use container image scanning\/patching and node management instead)\n&#8211; You need advanced cross-platform configuration management beyond OS-level policies (you may prefer Ansible\/Chef\/Puppet\/Salt for richer state models and app-layer orchestration)\n&#8211; Your OS\/distribution is <strong>not supported by OS Config agent<\/strong> (verify supported OS list in official docs)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is VM Manager used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Finance and insurance (strict patch SLAs, audit trails)<\/li>\n<li>Healthcare (compliance evidence, change windows)<\/li>\n<li>Retail and e-commerce (large web\/app fleets with controlled maintenance)<\/li>\n<li>SaaS and technology (DevOps automation, fleet standardization)<\/li>\n<li>Public sector (central governance and reporting)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams managing shared VM fleets<\/li>\n<li>SRE\/operations teams owning uptime and patch cadence<\/li>\n<li>Security engineering teams measuring patch compliance and inventory<\/li>\n<li>DevOps teams integrating patching into release\/change workflows<\/li>\n<li>IT operations teams managing Windows and Linux servers in the cloud<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Web\/app tiers on Compute Engine<\/li>\n<li>Batch processing and schedulers<\/li>\n<li>Windows line-of-business apps<\/li>\n<li>Bastion\/jump hosts (hardened and tightly controlled)<\/li>\n<li>Multi-tier enterprise apps with patch windows<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures and contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-zone regional deployments with maintenance windows<\/li>\n<li>Shared VPC environments (central network, multiple service projects)<\/li>\n<li>Organizations with separate dev\/test\/prod projects<\/li>\n<li>Mixed OS fleets (Linux + Windows)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> Emphasis on maintenance windows, canary rollouts, strong reporting, and change control.<\/li>\n<li><strong>Dev\/test:<\/strong> Faster cadence, more frequent patching, experimentation with OS policies and automation.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic VM Manager use cases commonly seen in Google Cloud Compute environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Monthly patch window for production web fleet<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Production VMs must patch monthly during a maintenance window.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> Scheduled patch deployments + label targeting + centralized results.<\/li>\n<li><strong>Example:<\/strong> Patch all VMs with label <code>env=prod<\/code> and <code>role=web<\/code> every Sunday 02:00\u201304:00.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Emergency out-of-band patch for a critical CVE<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A critical vulnerability requires immediate patching across internet-facing VMs.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> Run an ad hoc patch job now, track failures quickly.<\/li>\n<li><strong>Example:<\/strong> Patch all VMs in <code>dmz<\/code> subnet labels within 2 hours, then re-run for failures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Patch compliance reporting for audit<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Auditors ask for evidence of patching and OS baselines.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> Central patch job history + per-instance results + inventory.<\/li>\n<li><strong>Example:<\/strong> Export patch job logs to BigQuery for monthly compliance reporting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Inventory discovery after migration to Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> After a lift-and-shift migration, the team doesn\u2019t know what packages are installed.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> OS inventory provides package lists and OS details at scale.<\/li>\n<li><strong>Example:<\/strong> Identify which VMs still run older OpenSSL packages post-migration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Enforce baseline packages and services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Security baseline requires certain agents\/tools installed (for example, endpoint monitoring).<\/li>\n<li><strong>Why VM Manager fits:<\/strong> OS policy assignments enforce a desired state.<\/li>\n<li><strong>Example:<\/strong> Ensure a logging agent package is installed and a service is running on all prod VMs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Canary patch rollout<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Patching all VMs at once risks widespread outage.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> Target small canary label first; then broaden scope.<\/li>\n<li><strong>Example:<\/strong> Patch <code>canary=true<\/code> VMs on Friday, evaluate, then patch the rest Saturday.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Standardize OS configuration for golden image drift control<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams patch and change VMs manually, causing configuration drift.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> OS policies re-apply desired state and reduce drift.<\/li>\n<li><strong>Example:<\/strong> Enforce that SSH settings and a required config file exist on every VM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Patch management for Windows fleets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Windows Update coordination is inconsistent across many VMs.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> Central patch orchestration and reporting for Windows updates.<\/li>\n<li><strong>Example:<\/strong> Apply security updates to all Windows Server instances in a maintenance window with reboots controlled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Separate duties: security defines policy, ops executes patching<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Need separation of duties for compliance.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> IAM roles can separate \u201cdefine deployment\u201d from \u201cexecute job\u201d.<\/li>\n<li><strong>Example:<\/strong> Security team creates patch deployments; operations runs emergency patch jobs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Reduce NAT\/egress surprises by controlling patch source<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> OS updates cause unexpected outbound data and costs.<\/li>\n<li><strong>Why VM Manager fits:<\/strong> You can design patching schedules and repositories; VM Manager orchestrates timing.<\/li>\n<li><strong>Example:<\/strong> Patch at off-peak hours and use internal mirrors where appropriate (architecture-dependent).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Feature availability can evolve; confirm details in official docs when implementing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Patch jobs (on-demand patch execution)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Executes a patch operation immediately against targeted VMs.<\/li>\n<li><strong>Why it matters:<\/strong> Useful for emergency fixes or one-time maintenance.<\/li>\n<li><strong>Practical benefit:<\/strong> Centralized execution and per-VM results without manual login.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Requires a supported OS and a functioning OS Config agent.<\/li>\n<li>Patching can require reboots; careless settings can cause downtime.<\/li>\n<li>VMs must have network access to required update repositories (or configured internal mirrors).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Patch deployments (scheduled patching)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines a recurring schedule (for example, weekly or monthly) for patching a target set of VMs.<\/li>\n<li><strong>Why it matters:<\/strong> Enables routine patch hygiene and predictable maintenance.<\/li>\n<li><strong>Practical benefit:<\/strong> Standardizes patch cadence with reporting.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Requires careful coordination with application maintenance windows.<\/li>\n<li>Evaluate impact on managed instance groups and autoscaling (patching during scale events can complicate outcomes).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Targeting by labels, zones, and instance selection<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you patch or enforce policy on a defined fleet segment.<\/li>\n<li><strong>Why it matters:<\/strong> Precision reduces blast radius.<\/li>\n<li><strong>Practical benefit:<\/strong> Operational workflows map cleanly to labels like <code>env<\/code>, <code>tier<\/code>, <code>owner<\/code>, <code>patch_group<\/code>.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Label hygiene becomes critical; inconsistent labels create gaps.<\/li>\n<li>Consider Shared VPC and multi-project segmentation strategies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) OS inventory management<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Collects OS and software inventory data from VMs (for example, OS version and installed packages).<\/li>\n<li><strong>Why it matters:<\/strong> You can\u2019t manage what you can\u2019t measure\u2014inventory helps with audits and vulnerability response.<\/li>\n<li><strong>Practical benefit:<\/strong> Quickly locate where a specific package\/version exists across fleets.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Inventory is typically \u201cbest effort\u201d and depends on agent health.<\/li>\n<li>Inventory does not automatically equal vulnerability assessment; it\u2019s data you can use in your security processes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) OS policies \/ OS policy assignments (desired state enforcement)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enforces baseline configuration such as packages, repositories, files, and services.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces configuration drift and strengthens compliance.<\/li>\n<li><strong>Practical benefit:<\/strong> Codify baselines (\u201cthese packages must be installed\u201d) and apply consistently.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Policy design must account for OS differences and app constraints.<\/li>\n<li>Avoid overly broad policies that can break workloads.<\/li>\n<li>If you previously used \u201cguest policies,\u201d verify current recommended approach in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Centralized reporting and job status<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Shows patch job progress and per-instance outcomes (success, failure, not applicable).<\/li>\n<li><strong>Why it matters:<\/strong> Operations needs actionable results, not just \u201cwe ran updates.\u201d<\/li>\n<li><strong>Practical benefit:<\/strong> Faster remediation: rerun jobs for failed instances only.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Failures often require OS-level troubleshooting (package locks, repo issues).<\/li>\n<li>Reports depend on agent communication and VM reachability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) API-first automation (OS Config API)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enables programmatic creation of patch jobs\/deployments and policy assignments.<\/li>\n<li><strong>Why it matters:<\/strong> Integrates with CI\/CD, change management, and ChatOps.<\/li>\n<li><strong>Practical benefit:<\/strong> Repeatable workflows; easy to standardize across projects.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Requires careful IAM and change controls.<\/li>\n<li>Consider rate limits\/quotas (verify in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Integration with IAM and Cloud Audit Logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Controls who can manage patching\/inventory\/policies; logs administrative changes.<\/li>\n<li><strong>Why it matters:<\/strong> Supports governance and investigations.<\/li>\n<li><strong>Practical benefit:<\/strong> Clear accountability and traceability.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Ensure least privilege; \u201cProject Owner\u201d is convenient but not a best practice for production.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>VM Manager uses a <strong>control-plane + agent<\/strong> pattern:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>An operator (or automation) defines a patch job or policy in the Console or via OS Config API.<\/li>\n<li>The OS Config control plane identifies target instances based on project\/zone\/labels.<\/li>\n<li>Each VM\u2019s <strong>OS Config agent<\/strong> receives instructions, performs OS-level actions (apt\/yum\/zypper or Windows Update), and reports status back.<\/li>\n<li>Results are visible in the Console and available via APIs; administrative actions are captured in Cloud Audit Logs.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow:<\/strong> Operator \u2192 OS Config API \u2192 orchestration \u2192 OS Config agent \u2192 OS actions.<\/li>\n<li><strong>Data flow (inventory):<\/strong> OS Config agent \u2192 OS Config API \u2192 inventory stored\/queried \u2192 Console\/API consumers.<\/li>\n<li><strong>Results flow:<\/strong> Agent \u2192 OS Config API \u2192 patch job results \u2192 Console\/reporting\/logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine:<\/strong> Instances, labels, service accounts, metadata.<\/li>\n<li><strong>Cloud Logging:<\/strong> Operational logs (and optional sinks to BigQuery\/Cloud Storage\/Pub\/Sub).<\/li>\n<li><strong>Cloud Audit Logs:<\/strong> Tracks who created\/modified patch deployments and policies.<\/li>\n<li><strong>VPC networking:<\/strong> Internet access or Private Google Access paths for agent communication and package repositories.<\/li>\n<li><strong>Cloud NAT (common):<\/strong> Enables private VMs to reach update repos and Google APIs without external IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OS Config API<\/strong> (must be enabled)<\/li>\n<li><strong>Compute Engine API<\/strong> (for instance discovery and targeting)<\/li>\n<li><strong>Guest environment inside VM<\/strong> (supported OS + OS Config agent + package manager availability)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Admin\/operator access:<\/strong> IAM controls access to OS Config resources and Compute resources.<\/li>\n<li><strong>VM agent authentication:<\/strong> The OS Config agent uses the VM\u2019s identity and connectivity to communicate with OS Config endpoints. The exact permission model can vary by configuration; validate with official docs for your environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<p>VMs need:\n&#8211; Connectivity to <strong>Google APIs<\/strong> used by OS Config (for example, <code>osconfig.googleapis.com<\/code>)\u2014often via internet, <strong>Private Google Access<\/strong>, or controlled egress.\n&#8211; Connectivity to OS package repositories:\n  &#8211; Debian\/Ubuntu apt mirrors\n  &#8211; RHEL\/CentOS yum\/dnf repositories\n  &#8211; SUSE repositories\n  &#8211; Windows Update endpoints (or your organization\u2019s update infrastructure)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Export patch job outcomes and administrative activity to centralized logging.<\/li>\n<li>Use labels for ownership and environment segmentation.<\/li>\n<li>Consider org policies and change approvals for who can execute fleet-wide patch jobs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Admin[Operator \/ CI Pipeline] --&gt;|Console \/ OS Config API| OSConfig[OS Config control plane\\n(VM Manager workflows)]\n  OSConfig --&gt;|Patch instructions| Agent1[OS Config agent\\non VM A]\n  OSConfig --&gt;|Patch instructions| Agent2[OS Config agent\\non VM B]\n  Agent1 --&gt;|apt\/yum\/Windows Update| Repos[OS update repositories]\n  Agent2 --&gt;|apt\/yum\/Windows Update| Repos\n  Agent1 --&gt;|Status + inventory| OSConfig\n  Agent2 --&gt;|Status + inventory| OSConfig\n  OSConfig --&gt; Results[VM Manager reports\\n(Console\/API)]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    subgraph NetProj[Network Project (Shared VPC)]\n      VPC[VPC + Subnets]\n      NAT[Cloud NAT \/ Egress Controls]\n      PGA[Private Google Access (optional)]\n    end\n\n    subgraph ProdProj[Production Service Project]\n      CE[Compute Engine VM fleets\\n(labels: env=prod, app=...)]\n      OSConf[OS Config API\\n(VM Manager control plane)]\n      Logs[Cloud Logging + Audit Logs]\n      Sink[Log Sink to BigQuery\/Storage\/PubSub]\n      IAM[IAM Roles + Service Accounts]\n    end\n  end\n\n  Admin[Ops\/Sec\/Automation] --&gt; OSConf\n  OSConf --&gt; CE\n  CE --&gt; NAT\n  CE --&gt; PGA\n  NAT --&gt; Repos[External OS repos\\nor internal mirrors]\n  PGA --&gt; GoogleAPIs[Google APIs\\n(osconfig.googleapis.com)]\n  OSConf --&gt; Logs\n  Logs --&gt; Sink\n  IAM --&gt; OSConf\n  IAM --&gt; CE\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before you start using VM Manager in Google Cloud Compute, ensure the following.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with access to a <strong>project<\/strong>.<\/li>\n<li><strong>Billing enabled<\/strong> on the project (Compute Engine resources require billing).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>For a hands-on lab, the simplest is:\n&#8211; <strong>Project Owner<\/strong> on a dedicated sandbox project.<\/p>\n\n\n\n<p>For production, use least privilege. Common role patterns include:\n&#8211; Roles to manage OS Config\/VM Manager resources (patch jobs\/deployments, policies)\n&#8211; Roles to view inventory and results\n&#8211; Roles to view\/operate Compute Engine instances as needed<\/p>\n\n\n\n<p>Role names and exact permissions can change; <strong>verify the recommended IAM roles in the official VM Manager \/ OS Config docs<\/strong>:\n&#8211; https:\/\/cloud.google.com\/compute\/docs\/osconfig<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">APIs to enable<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine API<\/li>\n<li>OS Config API<\/li>\n<\/ul>\n\n\n\n<p>You can enable them via Console or <code>gcloud<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cloud.google.com\/sdk\/docs\/install\">Google Cloud SDK (<code>gcloud<\/code>)<\/a><\/li>\n<li>SSH client (built-in via <code>gcloud compute ssh<\/code> is sufficient)<\/li>\n<li>Optional: <code>curl<\/code> for API calls<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine is regional\/zonal.<\/li>\n<li>OS Config\/VM Manager control plane is accessed globally; availability depends on Google Cloud service availability. Verify if you have strict region residency requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine quotas (vCPUs, instances, disks)<\/li>\n<li>OS Config\/VM Manager quotas (patch job\/deployment API limits, agent interactions). <strong>Verify in official docs<\/strong> if you expect very large fleets or heavy automation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/config<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VM instances must run a <strong>supported OS<\/strong> and have the <strong>OS Config agent<\/strong> installed and running.<\/li>\n<li>VMs must have outbound access to:<\/li>\n<li>OS update repositories (or internal mirrors)<\/li>\n<li>Google APIs required by OS Config (direct internet, Private Google Access, or controlled egress)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (what you pay for)<\/h3>\n\n\n\n<p>VM Manager functionality itself is generally treated as part of Google Cloud\u2019s management capabilities for Compute Engine and is commonly documented as <strong>no additional charge<\/strong> beyond the resources it manages. However, pricing and billing SKUs can evolve\u2014<strong>verify current billing behavior in official docs<\/strong>.<\/p>\n\n\n\n<p>Start with:\n&#8211; VM Manager \/ OS Config documentation: https:\/\/cloud.google.com\/compute\/docs\/osconfig\n&#8211; Compute Engine pricing: https:\/\/cloud.google.com\/compute\/pricing\n&#8211; Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions to understand<\/h3>\n\n\n\n<p>Even if VM Manager does not add a direct fee, patching and inventory drive costs indirectly:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Compute Engine runtime<\/strong>\n   &#8211; Patching consumes CPU, memory, and disk I\/O.\n   &#8211; Reboots can cause availability impacts and sometimes additional operational overhead.<\/p>\n<\/li>\n<li>\n<p><strong>Network egress and NAT<\/strong>\n   &#8211; Downloading OS packages can generate outbound traffic.\n   &#8211; Private VMs commonly use Cloud NAT; NAT has its own cost model and can become a cost driver.<\/p>\n<\/li>\n<li>\n<p><strong>Storage and snapshots (optional)<\/strong>\n   &#8211; Best practice often includes backups\/snapshots before major patching\u2014snapshots cost money.<\/p>\n<\/li>\n<li>\n<p><strong>Cloud Logging<\/strong>\n   &#8211; Patch results and operational logs may increase logging volume (especially with large fleets).\n   &#8211; Exporting logs to BigQuery\/Storage has additional costs.<\/p>\n<\/li>\n<li>\n<p><strong>Internal mirrors\/repositories (architecture-dependent)<\/strong>\n   &#8211; Hosting apt\/yum mirrors or Windows update infrastructure has compute\/storage\/network costs.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine has specific free tier\/always free options in some regions for certain small VM types, but eligibility changes and is region-specific. <strong>Verify on the official pricing page<\/strong>:<\/li>\n<li>https:\/\/cloud.google.com\/free<\/li>\n<li>https:\/\/cloud.google.com\/compute\/pricing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what increases spend)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Fleet size and patch frequency<\/li>\n<li>Download volume (large updates, many packages)<\/li>\n<li>Using Cloud NAT heavily for updates<\/li>\n<li>High logging verbosity and long retention<\/li>\n<li>Frequent snapshots or large disk sizes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Downtime cost<\/strong> if patching triggers reboots unexpectedly<\/li>\n<li><strong>Incident response cost<\/strong> if patching breaks dependencies<\/li>\n<li><strong>Change management overhead<\/strong> for regulated industries<\/li>\n<li><strong>Extra capacity<\/strong> if you need redundancy during patch windows<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>label-based targeting<\/strong> to avoid patching everything unnecessarily.<\/li>\n<li>Use <strong>canary groups<\/strong> to reduce failed broad rollouts.<\/li>\n<li>Patch during <strong>off-peak<\/strong> to reduce performance impact and avoid scaling surges.<\/li>\n<li>For large fleets, consider <strong>internal repository mirrors<\/strong> (balanced against operational cost).<\/li>\n<li>Control <strong>logging retention<\/strong> and use log sinks carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A minimal lab typically uses:\n&#8211; One small VM (for example, an e2-small class instance) for 30\u201360 minutes\n&#8211; Standard persistent disk\n&#8211; Minimal network traffic for package updates\n&#8211; Limited logs<\/p>\n\n\n\n<p>Exact pricing depends on region, machine type, disk size, and traffic. Use:\n&#8211; https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production (hundreds\/thousands of VMs):\n&#8211; Cloud NAT and egress can become significant during patch windows.\n&#8211; Logging volume can grow quickly if you centralize results for compliance.\n&#8211; You may budget for pre-patch snapshots and rollback capacity.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab is designed to be safe and low-cost, while still being \u201creal\u201d: you will create a VM, confirm the OS Config agent, view inventory, run a patch job, and verify results.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Use <strong>VM Manager<\/strong> in Google Cloud to:\n1. Create a small Compute Engine VM with a patch target label.\n2. Confirm OS Config\/VM Manager prerequisites.\n3. View OS inventory.\n4. Run an on-demand patch job and review results.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud:<\/strong> Google Cloud<\/li>\n<li><strong>Category:<\/strong> Compute<\/li>\n<li><strong>Service:<\/strong> VM Manager (via OS Config)<\/li>\n<li><strong>Resources created:<\/strong><\/li>\n<li>1 Compute Engine VM<\/li>\n<li>Optional firewall rules are not required for this lab<\/li>\n<li><strong>Estimated time:<\/strong> 30\u201360 minutes<\/li>\n<li><strong>Cost:<\/strong> Mostly the VM runtime + minimal network; keep VM small and delete after.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create\/select a project and enable required APIs<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Option A: Console<\/h4>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In Google Cloud Console, select or create a project.<\/li>\n<li>Ensure billing is enabled.<\/li>\n<li>Go to <strong>APIs &amp; Services \u2192 Library<\/strong>.<\/li>\n<li>Enable:\n   &#8211; <strong>Compute Engine API<\/strong>\n   &#8211; <strong>OS Config API<\/strong><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs are enabled for the project.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: <code>gcloud<\/code><\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud config set project YOUR_PROJECT_ID\n\ngcloud services enable compute.googleapis.com\ngcloud services enable osconfig.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The APIs are enabled without errors.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a small VM and add patch targeting labels<\/h3>\n\n\n\n<p>Create a Debian-based VM (common for labs). Choose a region\/zone close to you.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export ZONE=us-central1-a\nexport VM_NAME=vmmanager-lab-1\n\ngcloud compute instances create \"$VM_NAME\" \\\n  --zone=\"$ZONE\" \\\n  --machine-type=e2-small \\\n  --image-family=debian-12 \\\n  --image-project=debian-cloud \\\n  --boot-disk-size=20GB \\\n  --labels=env=lab,patch_group=demo \\\n  --scopes=https:\/\/www.googleapis.com\/auth\/cloud-platform\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; The VM is created.\n&#8211; It has labels <code>env=lab<\/code> and <code>patch_group=demo<\/code>.<\/p>\n\n\n\n<p><strong>Why the scope flag matters:<\/strong> Some guest agents and Google APIs rely on VM OAuth scopes for access tokens. Using <code>cloud-platform<\/code> avoids scope-related failures in many labs. In production, you should tighten scopes and IAM where possible\u2014validate with your organization\u2019s standards.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Verify the OS Config agent is installed and running<\/h3>\n\n\n\n<p>Many Google-provided images include the OS Config agent by default, but you should verify.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>SSH into the VM:\n   <code>bash\n   gcloud compute ssh \"$VM_NAME\" --zone=\"$ZONE\"<\/code><\/p>\n<\/li>\n<li>\n<p>On the VM, check for the agent service.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p>For Debian\/Ubuntu, try:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo systemctl status google-osconfig-agent || true\n<\/code><\/pre>\n\n\n\n<p>If the service exists and is active, you should see <code>active (running)<\/code>.<\/p>\n\n\n\n<p>If it\u2019s not found, the agent may not be installed. Exit SSH and consult the official installation instructions for your OS:\n&#8211; OS Config docs: https:\/\/cloud.google.com\/compute\/docs\/osconfig<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> OS Config agent is running.<\/p>\n\n\n\n<p><strong>Notes:<\/strong>\n&#8211; If your VM does not have outbound connectivity (no external IP and no NAT\/Private Google Access), the agent may run but fail to communicate. You\u2019ll fix that by ensuring proper egress in real environments.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: View OS inventory in VM Manager<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In Google Cloud Console, go to:\n   &#8211; <strong>Compute Engine \u2192 VM Manager<\/strong><\/li>\n<li>Open <strong>Inventory<\/strong> (wording can vary slightly by Console updates).<\/li>\n<li>Filter or search for your instance name: <code>vmmanager-lab-1<\/code>.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; You can see inventory details for the VM (OS details and installed packages\/software categories depending on what\u2019s collected).<\/p>\n\n\n\n<p><strong>Verification tip:<\/strong>\n&#8211; If inventory is empty, wait a few minutes and refresh.\n&#8211; If it never appears, troubleshoot agent health and connectivity (see Troubleshooting section).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Run an on-demand patch job (VM Manager)<\/h3>\n\n\n\n<p>You can do this entirely in the Console (recommended for beginners).<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Compute Engine \u2192 VM Manager \u2192 Patching<\/strong>.<\/li>\n<li>Choose <strong>Create patch job<\/strong> (or similar).<\/li>\n<li>Configure:\n   &#8211; <strong>Name:<\/strong> <code>patchjob-lab-1<\/code>\n   &#8211; <strong>Instance filter \/ Target:<\/strong> by label<ul>\n<li><code>env=lab<\/code><\/li>\n<li><code>patch_group=demo<\/code><\/li>\n<li><strong>Patch type:<\/strong> choose the defaults appropriate for your OS (for Debian, this uses apt under the hood).<\/li>\n<li><strong>Reboot options:<\/strong> choose a safe option for a lab.<\/li>\n<li>For example, reboot if required, or never reboot (behavior depends on OS and settings).<\/li>\n<\/ul>\n<\/li>\n<li>Start the patch job.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; Patch job enters a running state.\n&#8211; The VM reports progress and eventually success\/failure.<\/p>\n\n\n\n<p><strong>What is happening:<\/strong> The OS Config control plane instructs the OS Config agent to run OS package updates locally, then report results back.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Review patch job results<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open the patch job details in VM Manager.<\/li>\n<li>Review per-VM results:\n   &#8211; Success \/ failure\n   &#8211; Any error messages\n   &#8211; Whether a reboot was required\/performed (if shown)<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; Your VM shows a completed status.\n&#8211; If it failed, you have an error message to act on.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7 (Optional): Validate from inside the VM<\/h3>\n\n\n\n<p>SSH back in and confirm package updates occurred.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh \"$VM_NAME\" --zone=\"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p>On Debian\/Ubuntu, you can inspect APT history:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo tail -n 50 \/var\/log\/apt\/history.log || true\n<\/code><\/pre>\n\n\n\n<p>You can also run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get update\nsudo apt-get -s upgrade | head -n 40\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; You see evidence of updates in logs or fewer pending upgrades in the simulated output.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\n<p>VM exists and is labeled correctly:\n  <code>bash\n  gcloud compute instances describe \"$VM_NAME\" --zone=\"$ZONE\" \\\n    --format=\"value(labels)\"<\/code><\/p>\n<\/li>\n<li>\n<p>OS Config agent is running:\n  <code>bash\n  gcloud compute ssh \"$VM_NAME\" --zone=\"$ZONE\" --command \\\n    \"systemctl is-active google-osconfig-agent &amp;&amp; systemctl status google-osconfig-agent --no-pager | head\"<\/code><\/p>\n<\/li>\n<li>\n<p>Inventory appears in Console under VM Manager.<\/p>\n<\/li>\n<li>Patch job completes and shows per-VM results in VM Manager.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and realistic fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Inventory never appears<\/strong>\n   &#8211; Causes:<\/p>\n<ul>\n<li>OS Config agent not installed\/running.<\/li>\n<li>VM has no egress path to Google APIs (osconfig endpoints).<\/li>\n<li>OS is unsupported.<\/li>\n<li>Fix:<\/li>\n<li>Confirm agent service status (<code>systemctl status google-osconfig-agent<\/code>).<\/li>\n<li>Ensure VM can reach Google APIs (internet, Cloud NAT, or Private Google Access depending on design).<\/li>\n<li>Verify supported OS list in official docs: https:\/\/cloud.google.com\/compute\/docs\/osconfig<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Patch job fails with repository\/network errors<\/strong>\n   &#8211; Causes:<\/p>\n<ul>\n<li>No access to Debian\/Ubuntu mirrors (or relevant repos).<\/li>\n<li>DNS or firewall restrictions.<\/li>\n<li>Fix:<\/li>\n<li>Check DNS and outbound rules.<\/li>\n<li>If VM has no external IP, confirm Cloud NAT configuration (production pattern).<\/li>\n<li>Consider internal mirrors for locked-down environments.<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Patch job reports package manager lock<\/strong>\n   &#8211; Causes:<\/p>\n<ul>\n<li>Another process is running apt\/dpkg\/yum.<\/li>\n<li>Fix:<\/li>\n<li>Wait and re-run, or investigate running processes.<\/li>\n<li>Avoid overlapping patch jobs.<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Unexpected reboot or service disruption<\/strong>\n   &#8211; Causes:<\/p>\n<ul>\n<li>Reboot settings or package updates that require restart.<\/li>\n<li>Fix:<\/li>\n<li>Use maintenance windows.<\/li>\n<li>Canary first; scale out gradually.<\/li>\n<li>Test in staging and use app-level health checks.<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Permissions errors in Console<\/strong>\n   &#8211; Causes:<\/p>\n<ul>\n<li>Insufficient IAM permissions to create patch jobs or view inventory.<\/li>\n<li>Fix:<\/li>\n<li>For lab: use Project Owner on a sandbox project.<\/li>\n<li>For production: grant appropriate OS Config roles (verify current role names in docs).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances delete \"$VM_NAME\" --zone=\"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p>Optional: If you created a dedicated project for this lab, delete the entire project (most reliable cleanup).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Prefer labels as the primary targeting mechanism<\/strong> (<code>env<\/code>, <code>app<\/code>, <code>tier<\/code>, <code>patch_group<\/code>, <code>owner<\/code>).<\/li>\n<li>Use <strong>canary + phased rollout<\/strong>:<\/li>\n<li>Patch a small group first, validate, then expand.<\/li>\n<li>Align patch scheduling with:<\/li>\n<li>Application maintenance windows<\/li>\n<li>Load balancer draining strategies<\/li>\n<li>Managed instance group update strategies (if used)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid broad roles in production. Prefer:<\/li>\n<li>Separate roles for \u201ccreate\/modify patch deployments\u201d vs \u201cexecute patch job\u201d.<\/li>\n<li>Separate roles for \u201cview inventory\u201d vs \u201cchange policy\u201d.<\/li>\n<li>Use <strong>dedicated automation identities<\/strong> (service accounts) for scheduled operations.<\/li>\n<li>Require approvals for fleet-wide patch actions (process + IAM).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Plan patch windows to avoid triggering unnecessary autoscaling.<\/li>\n<li>For private fleets, evaluate <strong>Cloud NAT and egress<\/strong> cost during patch bursts.<\/li>\n<li>Control logging:<\/li>\n<li>Keep only necessary fields<\/li>\n<li>Set retention policies appropriate for compliance<\/li>\n<li>Export summaries rather than all verbose logs when possible<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid running patch jobs during peak traffic.<\/li>\n<li>Stagger patching across zones\/tiers to keep capacity.<\/li>\n<li>Watch for disk space constraints on <code>\/var<\/code> or package caches.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>multi-zone designs<\/strong> so you can patch one zone while others serve traffic.<\/li>\n<li>Maintain rollback options:<\/li>\n<li>Snapshots (where appropriate)<\/li>\n<li>Immutable rebuild strategy for critical tiers<\/li>\n<li>Treat patching as a change with testing and validation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Track patch SLAs and failures:<\/li>\n<li>Re-run patch jobs for failed instances only<\/li>\n<li>Establish a runbook for common failures<\/li>\n<li>Document exemptions (where patching must be delayed) with time-bound exceptions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize labels:<\/li>\n<li><code>env=dev|test|prod<\/code><\/li>\n<li><code>app=&lt;name&gt;<\/code><\/li>\n<li><code>owner=&lt;team&gt;<\/code><\/li>\n<li><code>patch_group=&lt;group&gt;<\/code><\/li>\n<li><code>compliance=&lt;regime&gt;<\/code><\/li>\n<li>Standardize patch deployment names:<\/li>\n<li><code>pd-&lt;env&gt;-&lt;app&gt;-monthly<\/code><\/li>\n<li>Use separate projects (or folders) for lifecycle separation (dev\/test\/prod).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VM Manager administrative actions are controlled via <strong>IAM<\/strong>.<\/li>\n<li>Prefer:<\/li>\n<li>Least privilege roles<\/li>\n<li>Separate identities for human operators vs automation<\/li>\n<li>Organization policies to restrict who can create service accounts or assign broad roles<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VM Manager control plane uses Google Cloud\u2019s standard encryption for data in transit and at rest (platform behavior).<\/li>\n<li>Your VM disk encryption follows Compute Engine settings (Google-managed keys by default; CMEK optional depending on requirements).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Patching requires outbound connectivity to repositories and Google APIs.<\/li>\n<li>Avoid giving every VM a public IP if not required:<\/li>\n<li>Use <strong>Cloud NAT<\/strong> for outbound internet access from private VMs<\/li>\n<li>Use <strong>Private Google Access<\/strong> for Google APIs where applicable<\/li>\n<li>Restrict outbound traffic with firewall policies and\/or secure egress designs where needed, but ensure required endpoints remain reachable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VM Manager is not a secrets manager.<\/li>\n<li>Don\u2019t store credentials in scripts or OS policies.<\/li>\n<li>Use <strong>Secret Manager<\/strong> for secrets and retrieve them securely at runtime (application-level pattern).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure <strong>Cloud Audit Logs<\/strong> are enabled and retained appropriately:<\/li>\n<li>Track creation\/modification of patch deployments and policies<\/li>\n<li>Centralize logs with sinks for compliance:<\/li>\n<li>BigQuery for reporting<\/li>\n<li>Cloud Storage for archival<\/li>\n<li>Pub\/Sub for automation triggers<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VM Manager can support compliance initiatives by providing:<\/li>\n<li>Evidence of patch operations<\/li>\n<li>Inventory evidence of installed software<\/li>\n<li>Compliance still requires:<\/li>\n<li>Defined policy (what to patch, when, and acceptable exceptions)<\/li>\n<li>Evidence retention and reporting workflows<\/li>\n<li>Change management approvals and documentation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Running patch jobs as broad \u201cOwner\u201d identities in production.<\/li>\n<li>Patching everything at once without canaries and maintenance windows.<\/li>\n<li>Allowing unmanaged outbound access while lacking visibility into what was downloaded.<\/li>\n<li>Assuming \u201cinventory collected\u201d equals \u201cvulnerability-free.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Combine VM Manager with:<\/li>\n<li>Centralized logging and audit retention<\/li>\n<li>Strong IAM role separation<\/li>\n<li>Network egress control (NAT, proxy, internal mirrors if needed)<\/li>\n<li>Regular compliance reporting and exception management<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>These are common real-world issues to plan for (verify any environment-specific constraints in official docs).<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Supported OS constraints:<\/strong> OS Config agent and patching support specific OS distributions\/versions. Unsupported OS images may not work.<\/li>\n<li><strong>Agent dependency:<\/strong> Patch\/inventory relies on the OS Config agent being installed, running, and able to communicate.<\/li>\n<li><strong>Network dependency:<\/strong> If a VM can\u2019t reach required repos or Google APIs, patching\/inventory fails.<\/li>\n<li><strong>Reboot behavior:<\/strong> Some patches require reboot; incorrect reboot settings can cause outage or incomplete patch state.<\/li>\n<li><strong>Package manager locks:<\/strong> apt\/dpkg\/yum locks can cause patch failures.<\/li>\n<li><strong>Repository configuration drift:<\/strong> Custom repos or pinned packages can cause inconsistent outcomes across \u201csimilar\u201d VMs.<\/li>\n<li><strong>Immutable vs in-place tension:<\/strong> If your organization practices immutable rebuilds, in-place patching may conflict with your standards.<\/li>\n<li><strong>Windows specifics:<\/strong> Windows update behavior differs from Linux; patch timing and reboot behavior require careful scheduling.<\/li>\n<li><strong>Scale and quotas:<\/strong> Large fleets may hit API limits or operational timeouts; design for batching and staged rollouts.<\/li>\n<li><strong>Inventory \u2260 vulnerability scanning:<\/strong> Inventory is data; vulnerability assessment and prioritization require additional security tooling\/process.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>VM Manager is one option in a broader operations and configuration landscape.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Cloud VM Manager (OS Config)<\/strong><\/td>\n<td>Patching\/inventory\/baseline OS policy on Compute Engine<\/td>\n<td>Google-native, label targeting, console + API, integrates with IAM\/Audit Logs<\/td>\n<td>Focused on OS-level management; relies on agent and network\/repo access<\/td>\n<td>You want Google Cloud\u2013native OS management for Compute Engine fleets<\/td>\n<\/tr>\n<tr>\n<td><strong>Immutable infrastructure (golden images + instance replacement)<\/strong><\/td>\n<td>High-control environments with standardized builds<\/td>\n<td>Predictable, reduces drift, easier rollback via redeploy<\/td>\n<td>Requires mature image pipeline; may not fit legacy stateful servers<\/td>\n<td>You can rebuild and redeploy instead of patching in-place<\/td>\n<\/tr>\n<tr>\n<td><strong>Configuration management tools (Ansible\/Chef\/Puppet\/Salt)<\/strong><\/td>\n<td>Rich configuration state and app-layer automation<\/td>\n<td>Very flexible; large ecosystem; cross-cloud<\/td>\n<td>You operate the tooling; must design security and reporting<\/td>\n<td>You need deeper configuration\/app orchestration than VM Manager provides<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Ops Agent + Monitoring workflows<\/strong><\/td>\n<td>Observability (metrics\/logs\/traces)<\/td>\n<td>Great telemetry; integrates with alerting<\/td>\n<td>Not a patch\/config orchestrator<\/td>\n<td>You need monitoring; pair it with VM Manager for OS management<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Systems Manager (Patch Manager, Inventory)<\/strong><\/td>\n<td>OS management on AWS EC2<\/td>\n<td>Mature OS management suite in AWS<\/td>\n<td>Not applicable to Google Cloud VMs directly<\/td>\n<td>You run fleets primarily in AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Update Manager \/ Azure Automation<\/strong><\/td>\n<td>OS patching for Azure VMs<\/td>\n<td>Integrated with Azure governance<\/td>\n<td>Not applicable to Google Cloud VMs directly<\/td>\n<td>You run fleets primarily in Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>WSUS \/ on-prem update infrastructure<\/strong><\/td>\n<td>Windows-heavy enterprises with strict control<\/td>\n<td>Central Windows update control<\/td>\n<td>Operational overhead; hybrid complexity<\/td>\n<td>You must tightly control Windows update sources in regulated environments<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated financial services patch governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A bank runs 2,000+ Linux and Windows VMs on Compute Engine. Regulators require monthly patching with evidence, plus emergency patch capability for critical CVEs.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Separate prod and non-prod projects under an organization folder.<\/li>\n<li>VM Manager patch deployments scheduled per tier:<ul>\n<li><code>canary<\/code> group first, then <code>prod<\/code> web\/app tiers, then batch tiers.<\/li>\n<\/ul>\n<\/li>\n<li>Label strategy: <code>env<\/code>, <code>tier<\/code>, <code>app<\/code>, <code>owner<\/code>, <code>patch_group<\/code>, <code>criticality<\/code>.<\/li>\n<li>Private subnets with <strong>Cloud NAT<\/strong> and controlled egress to approved repositories (or internal mirrors).<\/li>\n<li>Cloud Logging sinks export:<ul>\n<li>OS Config patch job outcomes to BigQuery for compliance dashboards<\/li>\n<li>Audit Logs for change tracking<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why VM Manager was chosen:<\/strong><\/li>\n<li>Native integration with Compute Engine targeting and IAM.<\/li>\n<li>Central visibility and standardized job execution.<\/li>\n<li>Reduces need for custom patch orchestration tooling.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Shorter patch cycles, measurable compliance posture<\/li>\n<li>Faster emergency response with repeatable runbooks<\/li>\n<li>Better audit evidence and reduced manual effort<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: small SaaS fleet hygiene<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup runs ~25 VMs (web, workers, databases). They need basic patch hygiene without building a full configuration management platform.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Use VM Manager to schedule weekly patch deployments for non-prod and monthly for prod.<\/li>\n<li>Canary patch on one VM per tier.<\/li>\n<li>Minimal logging: keep patch job results; alert on repeated failures via operational process.<\/li>\n<li><strong>Why VM Manager was chosen:<\/strong><\/li>\n<li>Low operational overhead; quick to adopt.<\/li>\n<li>Console workflow is easy for a small team; API is available later.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced vulnerability exposure<\/li>\n<li>Less time spent manually updating servers<\/li>\n<li>Clear view of patch failures and fleet status<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is VM Manager a separate product from OS Config?<\/strong><br\/>\n   VM Manager is commonly presented as the operational \u201csuite\u201d in Compute Engine. Many capabilities are implemented via the OS Config API. Use VM Manager in the Console for workflows, and OS Config API for automation.<\/p>\n<\/li>\n<li>\n<p><strong>Does VM Manager work for all Compute Engine OS images?<\/strong><br\/>\n   No. Support depends on OS Config agent support for specific OS distributions and versions. Verify supported OS lists in official docs.<\/p>\n<\/li>\n<li>\n<p><strong>Do I need to install an agent?<\/strong><br\/>\n   Typically yes\u2014VM Manager relies on the OS Config agent inside the VM. Some Google-provided images include it by default, but you should verify.<\/p>\n<\/li>\n<li>\n<p><strong>Can VM Manager patch VMs with no external IP address?<\/strong><br\/>\n   Yes, if you provide outbound access via Cloud NAT and\/or Private Google Access (and ensure access to OS repositories). The VM still must reach required endpoints.<\/p>\n<\/li>\n<li>\n<p><strong>Can I patch only security updates?<\/strong><br\/>\n   Patch configuration can often distinguish patch classifications and package sources depending on OS. Verify current patch configuration options in the OS Config patch management docs.<\/p>\n<\/li>\n<li>\n<p><strong>How do I avoid patching everything at once?<\/strong><br\/>\n   Use labels to define canary groups and schedule phased patching (canary first, then expand). Avoid broad \u201call instances\u201d targeting.<\/p>\n<\/li>\n<li>\n<p><strong>Will patching reboot my VM?<\/strong><br\/>\n   Some updates require reboot. VM Manager provides reboot behavior settings, but you must plan maintenance windows and redundancy.<\/p>\n<\/li>\n<li>\n<p><strong>Can I patch Managed Instance Groups (MIGs) with VM Manager?<\/strong><br\/>\n   You can target MIG instances by label or other selectors. However, many teams prefer immutable rebuilds + rolling updates for MIGs. Choose the approach that matches your operational model.<\/p>\n<\/li>\n<li>\n<p><strong>Does VM Manager replace Ansible\/Chef\/Puppet?<\/strong><br\/>\n   Not entirely. VM Manager focuses on OS patching, inventory, and baseline OS policies. Full configuration management tools provide broader app-layer orchestration.<\/p>\n<\/li>\n<li>\n<p><strong>Can I export patch reports for compliance?<\/strong><br\/>\n   Yes. Combine patch job results visibility with Cloud Logging\/Audit Logs exports (for example, to BigQuery). The exact export method depends on your logging strategy.<\/p>\n<\/li>\n<li>\n<p><strong>How do I troubleshoot patch failures?<\/strong><br\/>\n   Start with patch job error details, then check VM-level logs (agent status, package manager logs, repository reachability, DNS).<\/p>\n<\/li>\n<li>\n<p><strong>Can I run patching across multiple projects?<\/strong><br\/>\n   VM Manager operations are typically project-scoped. For multi-project operations, use consistent labeling, central automation, and appropriate IAM across projects.<\/p>\n<\/li>\n<li>\n<p><strong>Is inventory real-time?<\/strong><br\/>\n   Inventory collection depends on agent reporting cadence and connectivity; it\u2019s not typically real-time. Treat it as operational data, not instantaneous truth.<\/p>\n<\/li>\n<li>\n<p><strong>Can I use VM Manager for application updates too?<\/strong><br\/>\n   VM Manager focuses on OS-level management. Application deployments are usually handled by CI\/CD, configuration management, or orchestration systems.<\/p>\n<\/li>\n<li>\n<p><strong>Is there a direct cost for VM Manager?<\/strong><br\/>\n   VM Manager is often documented as not having an extra charge, but you still pay for Compute, network, logging, and related resources. Always verify current billing terms in official docs.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn VM Manager<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>VM Manager \/ OS Config documentation: https:\/\/cloud.google.com\/compute\/docs\/osconfig<\/td>\n<td>Primary source for supported OSes, agent behavior, patching and policy features<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Compute Engine documentation: https:\/\/cloud.google.com\/compute\/docs<\/td>\n<td>Context for VM lifecycle, networking, IAM, and operations<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Compute Engine pricing: https:\/\/cloud.google.com\/compute\/pricing<\/td>\n<td>Understand VM\/disk\/network costs that dominate patching operations<\/td>\n<\/tr>\n<tr>\n<td>Official pricing tool<\/td>\n<td>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build region-specific estimates for VMs, NAT, logging exports<\/td>\n<\/tr>\n<tr>\n<td>Official docs\/tutorials<\/td>\n<td>Google Cloud SDK install: https:\/\/cloud.google.com\/sdk\/docs\/install<\/td>\n<td>Required for <code>gcloud<\/code> workflows in this tutorial<\/td>\n<\/tr>\n<tr>\n<td>Official reference<\/td>\n<td>OS Config API reference (start from docs and API explorer): https:\/\/cloud.google.com\/compute\/docs\/osconfig<\/td>\n<td>Needed for automation at scale and CI\/CD integration<\/td>\n<\/tr>\n<tr>\n<td>Official learning<\/td>\n<td>Google Cloud Skills Boost: https:\/\/www.cloudskillsboost.google<\/td>\n<td>Hands-on labs (search for OS Config \/ patching \/ VM operations)<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Google Cloud Tech YouTube: https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Product walkthroughs and best practices (search for OS Config \/ VM patching)<\/td>\n<\/tr>\n<tr>\n<td>Community (reputable)<\/td>\n<td>Google Cloud Architecture Center: https:\/\/cloud.google.com\/architecture<\/td>\n<td>Patterns for operations, governance, logging, and fleet management (not VM Manager-specific, but highly relevant)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps practices, cloud operations, automation fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>SCM, DevOps tooling, CI\/CD concepts<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams<\/td>\n<td>Cloud operations, monitoring, operational readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability engineers<\/td>\n<td>SRE practices, reliability engineering, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, automation, operations analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify specifics)<\/td>\n<td>Beginners to intermediate<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tooling and practices (verify specifics)<\/td>\n<td>DevOps engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps consulting\/training offerings (verify specifics)<\/td>\n<td>Teams needing targeted help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify specifics)<\/td>\n<td>Operations\/DevOps teams<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service catalog)<\/td>\n<td>Cloud migrations, operations setup, automation<\/td>\n<td>Designing patch governance, setting up fleet labels, operational runbooks<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and enablement<\/td>\n<td>DevOps process\/tooling adoption<\/td>\n<td>Building standardized patch pipelines and compliance reporting workflows<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify service catalog)<\/td>\n<td>CI\/CD, automation, operations<\/td>\n<td>Integrating VM patching with change management and monitoring<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before VM Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine fundamentals:<\/li>\n<li>Instances, images, disks, metadata, instance groups<\/li>\n<li>Linux\/Windows administration basics:<\/li>\n<li>Package managers (apt\/yum\/dnf\/zypper), services, logging, reboots<\/li>\n<li>Networking essentials:<\/li>\n<li>VPC, subnets, routes, firewall rules, DNS<\/li>\n<li>Cloud NAT and Private Google Access concepts<\/li>\n<li>IAM fundamentals:<\/li>\n<li>Roles, service accounts, least privilege, audit logs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after VM Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Fleet governance and automation:<\/li>\n<li>OS Config API automation patterns<\/li>\n<li>Policy-as-code and change management workflows<\/li>\n<li>Observability:<\/li>\n<li>Google Cloud Ops Agent, Cloud Monitoring alerting, log-based metrics<\/li>\n<li>Security posture:<\/li>\n<li>Vulnerability management lifecycle, asset inventory strategies, patch SLAs<\/li>\n<li>Advanced compute operations:<\/li>\n<li>Immutable images pipelines, rolling replacements, managed instance groups operations<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer \/ Cloud Operations Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Security Engineer (vulnerability and patch governance)<\/li>\n<li>Systems Administrator (Linux\/Windows) in cloud environments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>VM Manager itself isn\u2019t typically a standalone certification topic, but it aligns strongly with:\n&#8211; Google Cloud Associate Cloud Engineer\n&#8211; Google Cloud Professional Cloud Architect\n&#8211; Google Cloud Professional Cloud DevOps Engineer<br\/>\nVerify current certification outlines on the official site:\n&#8211; https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a patch governance model for a 3-tier app:<\/li>\n<li>labels, canaries, schedules, reporting<\/li>\n<li>Create a compliance dashboard:<\/li>\n<li>export patch results to BigQuery and build a basic report<\/li>\n<li>Design private patching:<\/li>\n<li>private subnets + Cloud NAT + controlled egress + patch schedules<\/li>\n<li>Implement a baseline OS policy:<\/li>\n<li>enforce specific packages\/services and validate drift handling<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine:<\/strong> Google Cloud service for running virtual machines.<\/li>\n<li><strong>VM Manager:<\/strong> Compute-focused suite for OS patching, inventory, and configuration management across VM fleets.<\/li>\n<li><strong>OS Config:<\/strong> The Google Cloud service\/API that implements many VM Manager features.<\/li>\n<li><strong>OS Config agent:<\/strong> Guest agent installed on the VM to execute patching\/inventory\/policy tasks.<\/li>\n<li><strong>Patch job:<\/strong> An on-demand patch execution against selected VMs.<\/li>\n<li><strong>Patch deployment:<\/strong> A scheduled\/repeating patch configuration applied to a VM set.<\/li>\n<li><strong>Inventory:<\/strong> Collected OS\/software details from VMs (OS version, packages, etc.).<\/li>\n<li><strong>Label:<\/strong> Key\/value metadata attached to resources (like VMs) used for targeting and organization.<\/li>\n<li><strong>Canary:<\/strong> A small subset of VMs patched first to validate safety before broad rollout.<\/li>\n<li><strong>Cloud NAT:<\/strong> Managed NAT service enabling outbound internet access for private VMs.<\/li>\n<li><strong>Private Google Access:<\/strong> Allows private VMs to reach Google APIs without external IPs (configuration-dependent).<\/li>\n<li><strong>IAM:<\/strong> Identity and Access Management; controls who can do what in a project.<\/li>\n<li><strong>Cloud Audit Logs:<\/strong> Logs of administrative actions and API access for governance and investigations.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>VM Manager in Google Cloud (Compute) is the practical, fleet-oriented way to manage <strong>OS patching, OS inventory, and baseline OS configuration<\/strong> for Compute Engine VMs\u2014primarily powered by the <strong>OS Config<\/strong> service and its guest agent.<\/p>\n\n\n\n<p>It matters because patching and inventory are core operational controls: they reduce vulnerability exposure, support compliance evidence, and cut manual toil. VM Manager fits best when you operate VM fleets and need centralized, repeatable OS operations with IAM controls and auditability.<\/p>\n\n\n\n<p>Cost-wise, the biggest drivers are usually <strong>Compute runtime, network egress\/NAT, and logging volume<\/strong>\u2014not a separate \u201cVM Manager license.\u201d Security-wise, the most important design points are <strong>least-privilege IAM<\/strong>, controlled rollout (canary\/maintenance windows), and ensuring <strong>secure, controlled outbound access<\/strong> to required repositories and Google APIs.<\/p>\n\n\n\n<p>Next learning step: move from ad hoc patch jobs to <strong>scheduled patch deployments<\/strong>, define a label taxonomy, and (when ready) automate workflows using the <strong>OS Config API<\/strong> starting from https:\/\/cloud.google.com\/compute\/docs\/osconfig.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Compute<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,51],"tags":[],"class_list":["post-636","post","type-post","status-publish","format-standard","hentry","category-compute","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/636","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=636"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/636\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=636"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=636"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=636"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}