> ## Documentation Index > Fetch the complete documentation index at: https://docs.plerion.com/llms.txt > Use this file to discover all available pages before exploring further. # GCP workload scanning coverage > Which GCP workloads Plerion scans, which it skips and why, and the conditions that decide whether a given asset is scanned With **[GCP workload scanning](/guides/integrations/gcp/workload-scanning/overview)**, Plerion decides at the start of each scan run whether each asset can be scanned. Use this page to tell a coverage gap from a missing finding. *** ## Supported workloads | Workload type | Toggle in Plerion | Scanned from | Notes | | - | - | - | - | | Compute Engine instances | **Compute Engine instances** | Snapshot of the boot disk | `RUNNING` and `TERMINATED` (stopped) instances only. CMEK-encrypted disks are supported (see below) | | Compute Engine custom images | **Compute Engine custom images** | A disk created from the image | `READY` and `DEPRECATED` images, up to 2048 GB. Linux and Windows images | | Compute Engine managed instance groups | **Compute Engine managed instance groups** | One sampled member per boot image | Findings attach to the group. Members stop being scanned individually | | Cloud Run services | **Cloud Run services** | The container image each serving revision runs | Every container in the revision, including sidecars | | Cloud Functions (2nd gen) | **Cloud Functions (2nd gen)** | The image Google built for the function | Stored in your project's `gcf-artifacts` repository | | Cloud Functions (1st gen) | **Cloud Functions (1st gen)** | The deployed source archive | Dependency findings need pinned versions (see below) | Every workload type supports all three scan types: **Vulnerabilities**, **Software bill of materials (SBOM)**, and **Sensitive data**. GKE Standard node pools are ordinary Compute Engine instances, so Plerion scans each node the way it scans any instance. This is node-level coverage only. Pods, deployments, and other Kubernetes objects are covered by the [Kubernetes integration](/guides/integrations/kubernetes/overview). GKE Autopilot nodes don't appear in the Compute Engine API, so they can't be scanned. *** ## What is skipped, and why | Skipped | Why | Notes | | - | - | - | | **Instances that aren't running or stopped** | Only `RUNNING` and `TERMINATED` instances are scanned | Suspended, staging, or stopping instances are picked up on a later run | | **Instances whose only disks are Local SSD** | Local SSD can't be snapshotted | A GCP limitation, not a Plerion one | | **Confidential VMs** | Plerion doesn't snapshot the disks of Confidential VMs | | | **CSEK-encrypted disks** | Plerion can't supply a customer-supplied encryption key at snapshot or disk creation | No decryption path exists for this case | | **Projects with the Compute Engine API disabled** | Plerion can't list instances, images, or groups in a project that has never enabled `compute.googleapis.com` | Posture scanning of the project is unaffected, so it still has findings, just no workload findings | | **GKE Autopilot nodes** | Not visible in the Compute Engine API | | | **Managed instance groups owned by GKE node pools** | Skipped at the group level | Their nodes are scanned individually as instances | | **Workloads outside your Workload regions** | Out of scope by configuration, not a coverage gap | See [Regions](#regions) | | **Cloud Run services with no ready revision**, and **revisions receiving no traffic** | Nothing is serving | | | **Cloud Functions that aren't `ACTIVE`** | The function is deploying, failed, or being deleted | | | **1st gen functions with source over 100 MB compressed or 500 MB unpacked** | Too large for the scan job | | | **Google-managed projects** | Excluded from Plerion entirely, not only from workload scanning | See [Projects Plerion does not scan](/guides/integrations/gcp/overview#projects-plerion-does-not-scan) | A skipped asset has no workload scan for that run. The reason isn't shown in the dashboard. Plerion records it in its operational logs, which Plerion support can check for you. If an asset you expect to be scanned has no workload findings, check this table and [Why does one of my projects have findings but no vulnerabilities?](/guides/integrations/gcp/workload-scanning/faq#why-does-one-of-my-projects-have-findings-but-no-vulnerabilities) first. An asset Plerion tried to scan but couldn't is different. A disk that wouldn't mount, an image that couldn't be pulled, or a source archive that was too large produces a scan record with a failed status and an error message on the project's **Workload scans** tab. A run that an [organization policy check](/guides/integrations/gcp/workload-scanning/prerequisites#organization-policies) blocked also shows there as failed, for the whole project. *** ## CMEK-encrypted disks Instances and custom images protected by a customer-managed encryption key (CMEK) are scanned. The snapshot keeps your key, but the scan disk Plerion creates in the scanning project uses Google-managed encryption for the minutes it exists, because Plerion creates it without your key. See [Encrypted disks and images](/guides/integrations/gcp/workload-scanning/how-scanning-works#encrypted-disks-and-images). `PlerionAccess: Denied` is a resource tag you apply to a project yourself (see [Excluding a project's custom images](/guides/integrations/gcp/overview#excluding-a-projects-custom-images)). If custom image scanning is on, it removes Plerion's ability to read that project's custom images. It doesn't stop the project's workloads from being scanned, and that includes instances with CMEK-encrypted disks. Plerion holds no access to your keys and never needs it. Your project's Compute Engine service agent, which already holds your key because it created the encrypted disk, decrypts the snapshot when the scan disk is created. The scan disk itself uses Google-managed encryption, so no key is involved after that point. To stop scanning a project altogether, exclude it from the organization integration under **Manage projects**. Excluding a project that is already onboarded deletes its project integration and all the findings and scan history Plerion holds for it, for both posture scanning and workload scanning. This can't be undone, and Plerion asks you to confirm first. *** ## Compute Engine custom images Plerion scans every custom image a project owns, including images nothing has ever booted from. Whether an image is scanned depends on its state: * `READY` images are scanned. `DEPRECATED` images are scanned too, because they're marked as on the way out but are still bootable. * Images that aren't ready yet (`PENDING`, `FAILED`, `DELETING`) and images that can no longer be booted (`OBSOLETE`, `DELETED`) are skipped. * Images larger than 2048 GB are skipped. * An image Plerion can't read is skipped. This happens when the access command hasn't been re-run since you turned on the custom image type, when the grant has been removed, or when the image's project is tagged `PlerionAccess: Denied`. * An image whose CMEK key Plerion can't use is skipped without affecting the rest of the run. Findings attach to the image (`GCP::Compute::Image`) and are independent of findings on instances booted from it. Image identity follows the image's numeric ID, so rebuilding an image under the same name creates a new asset with its own finding history. *** ## Compute Engine managed instance groups Plerion samples one member per distinct boot image in the group, scans each sample like a standalone instance, and reports the merged result against the group. A group on one image produces one sample. A group mid-rolling-update produces one sample per image, each labeled with its image. Groups are capped at 10 samples per run. While managed instance group scanning is on, members of a scanned group aren't scanned or reported as standalone instances. A group with no members has nothing to sample and is skipped for that run. Sampling has two limits: * **A member patched after boot can differ from the sample.** The sample reflects one member's disk, not every member's current state. Patch the image, not individual members, so future samples and every member built from them reflect the fix. * **Only the sampled member's boot disk is scanned.** Data disks attached to group members aren't covered while group scanning is on. *** ## Cloud Functions (1st gen): dependency findings need pinned versions Secrets scanning works on any deployed source. Dependency vulnerability findings need the function's dependencies declared with exact versions or a lockfile in the deployed archive, because no scanner can tell which version of an unpinned dependency is deployed. A function without pinned dependencies still gets a completed scan, with secrets findings but no dependency findings. | Ecosystem | What the deployed source needs | | - | - | | Node.js | `package-lock.json` | | Python | Exact pins in `requirements.txt` (`==1.2.3`, not a range) | | Ruby | `Gemfile.lock` | | PHP | `composer.lock` | | Java | `pom.xml` gives partial results: versions resolve, but transitive dependency locations don't, since that lookup needs a repository the scanner doesn't call out to | `gcloud functions deploy` helps: its default `.gcloudignore` excludes `node_modules` but keeps `package-lock.json`, so most Node.js deployments qualify without changes. If you deploy with Terraform or a custom build, check that the lockfile or pinned manifest is in the uploaded archive. *** ## Regions Scan disks and scanner VMs are always created in the same region as the instance being scanned, and image and source scan jobs run in the region of the service or function. Cross-region scanning never happens. If you've limited scanning with the **Workload regions** setting, workloads outside those regions are skipped as out of scope. A custom image is a global resource, so Plerion scans it in the first region in that list. If the list is empty, it uses a region the project's instance scans already use. Otherwise, it uses `us-central1`. *** ## Next step * [Managing workload scanning](/guides/integrations/gcp/workload-scanning/managing-workload-scanning) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.