Servicenow - Google Cloud Platform Discovery setup-readiness, responsibilities, data model, and troubleshooting - Support and Troubleshooting

Servicenow - Google Cloud Platform Discovery setup-readiness, responsibilities, data model, and troubleshooting Summary .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } :root{color-scheme:light;--navy:#062f4f;--ink:#17324d;--teal:#0b7f72;--paper:#f4f8fb;--line:#d7e3ec} *{box-sizing:border-box}html{scroll-behavior:smooth;scroll-padding-top:86px}body{margin:0;padding:0 18px 44px;background:radial-gradient(circle at 12% 0,rgba(60,183,168,.18),transparent 31rem),linear-gradient(160deg,#eaf3f7,#f8fbfd 48%,#eaf4f3);color:var(--ink);font-family:Inter,Segoe UI,Arial,sans-serif}a{overflow-wrap:anywhere}code{font-family:ui-monospace,SFMono-Regular,Consolas,monospace}.skip{position:absolute;left:-9999px;top:12px;background:#fff;color:#062942;padding:10px 14px;border-radius:8px;z-index:20;font-weight:800}.skip:focus{left:14px}.jumpbar{position:sticky;top:0;z-index:10;max-width:1180px;margin:0 auto 18px;background:rgba(6,47,79,.96);backdrop-filter:blur(10px);border-radius:0 0 15px 15px;box-shadow:0 9px 28px rgba(7,31,55,.18)}.jumpbar nav{display:flex;align-items:center;gap:6px;overflow-x:auto;padding:10px 12px;scrollbar-width:thin}.jumpbar strong{color:#fff;white-space:nowrap;padding:7px 9px;font-size:13px}.jumpbar a{color:#d9f4f2;text-decoration:none;white-space:nowrap;padding:7px 10px;border:1px solid rgba(255,255,255,.18);border-radius:999px;font-size:12px;font-weight:700}.jumpbar a:hover,.jumpbar a:focus-visible{background:#fff;color:#082b45;outline:none}details{transition:box-shadow .2s ease,transform .2s ease}details:hover{box-shadow:0 7px 20px rgba(13,43,69,.09)}summary:focus-visible,a:focus-visible{outline:3px solid #f1b642;outline-offset:3px}summary::marker{color:#0c8d7e}section{scroll-margin-top:86px}@media(max-width:720px){body{padding:0 8px 28px}.jumpbar{margin-bottom:8px}.jumpbar strong{display:none}h1{font-size:29px!important}section{padding:20px!important}}@media print{body{background:#fff;padding:0}.jumpbar,.skip{display:none}details{break-inside:avoid}details>div{display:block!important}}

Skip to article

JUMP TO Owners Prerequisites IAM & APIs MID & network Setup 29 patterns 37 CMDB tables Troubleshoot Escalate Sources Google Cloud Platform + ServiceNow Discovery GCP Discovery setup-readiness, responsibilities, data model, and troubleshooting A public, end-to-end handbook for coordinating cloud, security, network, MID Server, Discovery, and CMDB teams before onboarding—and for isolating failures without guesswork.

REQUIREMENTS 29 PATTERN GROUPS 37 CMDB TARGETS ERROR PLAYBOOK This is a detailed setup-readiness and support handbook—not a customer-specific implementation commitment. It defines the inputs, ownership, supported setup sequence, acceptance evidence, pattern/API coverage, and troubleshooting handoffs needed for a controlled implementation. Adapt scope, IAM, network, and governance to the customer’s architecture and security policy. The one diagnostic rule Find the first layer that diverges: schedule → ECC output → MID execution → OAuth authentication → GCP authorization/API → pattern response → IRE → CI/relationship. A downstream empty table is a symptom; the first upstream error is the cause to fix.

1. Purpose, scope, and success criteria This guide covers MID Server-based, pattern-driven Google Cloud discovery into the CMDB. It includes organization/folder/project enumeration, compute, network, storage, load balancing, certificates, managed databases, serverless functions, resource inventory, labels/tags, optional Cloud Logging events, and the operational records used to troubleshoot the pipeline.

Cloud API Discovery Uses a Google service account and HTTPS APIs through a Cloud Management-capable MID Server. No guest OS credential is required. Guest OS Discovery Optional, separate IP-based discovery for operating system, processes, and software. Requires network routes and SSH/Windows credentials. Event-driven refresh Optional near-real-time change path after full discovery. It complements—but does not replace—scheduled authoritative collection. Acceptance criteria The chosen hierarchy root and project/region scope are documented and approved. A dedicated, validated, Up MID Server with Cloud Management capability consumes and returns ECC work. The runtime identity authenticates without exposing its private key and has only the approved effective permissions. Every in-scope pattern returns expected resources or a defensible zero-resource result. IRE creates one CI per provider-native identity, expected relationships exist, and source traceability is preserved. A repeat discovery updates existing CIs instead of creating duplicates, and the operating teams can collect a redacted escalation package. Official basis: ServiceNow GCP discovery and GCP discovery methods and use cases .

2. Architecture and the first-divergence method The ServiceNow instance orchestrates work; the MID Server performs outbound authentication and API calls; GCP returns resource metadata; delivered patterns transform that metadata and send identification/reconciliation payloads to the CMDB. Relationships are as important as CI rows: the expected hierarchy includes cloud service account → logical datacenter → availability zone/resource, plus VM/network/storage/load-balancer/database relationships.

A schedule sends ECC output to a MID Server, which obtains an OAuth token and calls Google APIs. Results return through ECC input, patterns and IRE create CIs and relationships, and optional Cloud Logging events refresh them. Discovery scheduleaccount • projects • regions ECC outputHorizontal Pattern Dedicated MIDcredential • proxy • TLS Google OAuthservice-account token Google Cloud APIsResource Manager • Compute • services ECC inputpayload or first error Pattern + IREidentify • reconcile • relate CMDBCIs • relationships • tags • source Optional Cloud Logging eventsrefresh selected discovered resources Original explanatory visual based on the official ServiceNow Cloud Discovery, MID Server, and ECC flow. It is intentionally not a tenant screenshot. Authentication answers: Can this JSON key obtain a token for the service-account identity? Authorization answers: May that principal call this method on this exact org, folder, project, bucket, or resource? IRE answers: Which existing CI owns this provider-native identity, and which source may update each attribute? Official basis: MID Server ECC Queue and ServiceNow network security .

3. People, responsibilities, and handoff contract Assign named owners before any credential is created. “Cloud team” is not a sufficient escalation target: runtime IAM, organization policy, API enablement, VPC Service Controls, proxy/TLS, MID operations, and CMDB governance can be owned by different teams.

Legend: A = accountable, R = responsible, C = consulted, I = informed.

Activity GCP/IAM admin ServiceNow Discovery admin Security/network MID owner CMDB/service owner Scope: organization/folder/projects/regions/services A/R C C C C Create runtime service account and IAM bindings A/R C C I I Approve user-managed key and rotation R C A I I Enable Google APIs and review quotas A/R C C I I Firewall, DNS, proxy, TLS inspection, NTP C C A/R R I MID sizing, validation, capability, service health I C C A/R I ServiceNow credential/account/schedule/property C A/R C C I Pattern/ECC/log troubleshooting C A/R C R C IRE, identification, reconciliation, lifecycle I R I I A/R Service-specific result attestation C C I I A/R Required handoff package Approved hierarchy root type and ID, project list/exclusions, regions, and required services. Runtime service-account email, key ID/creation date/owner/rotation date—never the private key in tickets or chat. IAM bindings with resource scope and conditions; enabled-API export; VPC Service Controls/deny-policy decision. MID name/cluster, network zone, proxy path, supported TLS interception decision, and monitoring owner. Discovery schedule name, cadence/time window, event and guest-discovery decisions, CMDB data-owner acceptance criteria. 4. Application, role, property, and content prerequisites Keep the application set release-neutral by using the newest mutually compatible content that is offered for the customer’s supported platform. Version numbers are deliberately omitted because pattern/API coverage changes independently of the platform family.

Application/component Requirement Why it is needed Acceptance check Discovery Required Cloud discovery schedules, credentials, ECC orchestration, pattern execution, and Discovery logs. Licensed/active; a discovery_admin can create credentials and schedules. Discovery and Service Mapping Patterns Required Delivered GCP entry/helper patterns and API transforms. Install the latest compatible content available to the instance; do not clone delivered patterns. CMDB CI Class Models Required Cloud, GCP, network, compute, storage, load-balancer, database, and serverless classes. Latest compatible class model is installed before pattern content is tested. Visibility Content Required Supporting classifications, metadata, relationships, and content used by Discovery. Latest compatible content is installed and synchronized. MID Server Required component Executes Google authentication/API calls and returns results through ECC. Dedicated for cloud discovery; validated, Up, monitored, and Cloud Management-capable. Discovery Admin Workspace Required for the documented workflow Creates and manages cloud-based Google schedules and scope. Workspace loads and the operator has discovery_admin. Service Mapping/tag-based discovery Optional Uses cloud CI relationships/tags to build application-service context. Enable only when service modeling is in scope; validate required relationship types. Cloud Logging event collection Optional Near-real-time refresh of supported resource changes. Initial full discovery works; Pull Events, logging coverage, polling job, and event permissions are configured. IP-based server discovery Optional, separate Enriches guest OS, software, and process attributes. MID-to-VM routing plus SSH/Windows credentials; not required for API-only cloud inventory. ServiceNow roles discovery_admin : configure Google credentials, cloud accounts/service accounts, schedules, and troubleshoot Discovery. MID administration roles: grant only to the MID operations team for validation, capabilities, parameters, and log access. CMDB administration/steward roles: review identification, reconciliation, class models, relationships, and lifecycle; do not grant to the cloud runtime identity. Documented special property: for BigQuery and Bigtable table-level collection, navigate to Discovery → MID Server → Properties and set sn_itom_pattern.google_dbservice_table_collection=True in the scope used by the executing MID. Table collection can be high-volume: test one project, measure duration/ECC payload/CI growth, then expand. Do not add undocumented properties from old KBs. Official basis: ServiceNow GCP discovery prerequisites .

5. GCP hierarchy, IAM, APIs, and credential requirements Decide whether the onboarding root is a single project, a folder, or an organization. Granting a permission in the wrong project does not authorize access to a resource in another project; granting at a folder or organization can inherit broadly and therefore requires security approval.

Organization at the top, optional folders below, then projects and service resources. IAM allow policies inherit downward while deny policies and conditions can still block discovery. Organization Folder A Folder B Project 1 Project 2 Project 3VMs • APIs • buckets • DBs IAM allow policies can inherit downwardConditions, deny policies, API state, and perimeters still apply. Original explanatory visual based on Google Cloud’s official resource hierarchy documentation. Runtime identity versus setup identities Runtime discovery service account Read/list/get and approved asset-export actions only. It does not need key-administration, API-enablement, IAM-policy editing, or resource mutation. GCP setup administrator Creates the service account, enables APIs, and applies IAM bindings. Those elevated setup rights remain with the cloud team. Security/key custodian Approves a user-managed key exception, securely transfers the one-time JSON, tracks rotation, and revokes old/compromised keys. Supported permission posture Supported baseline: assign Google’s Viewer role to the runtime member at the approved scope, then add any permissions that the current Cloud Discovery pattern spreadsheet requires but Viewer does not supply. Least-privilege option: create a custom role from the exact in-scope pattern permissions in section 10. This must be retested whenever pattern coverage changes. Resource Inventory exception: Cloud Asset Inventory requires serviceusage.services.use and content-specific cloudasset.assets.export* permission. Export to Cloud Storage also requires the documented destination access; do not assume Viewer is enough. Policy evaluation: review allow-policy inheritance, IAM Conditions, principal access boundary/deny policies, organization constraints, and VPC Service Controls. A visible role binding can still be ineffective. API enablement The cloud administrator enables each API represented by the selected permissions: Cloud Resource Manager, Compute Engine, plus the in-scope services such as GKE, Certificate Manager, Cloud Asset Inventory, Cloud Storage, Cloud Functions/Cloud Run, AlloyDB, BigQuery, Bigtable, Cloud SQL, Firebase Realtime Database, Firestore/Datastore, Memorystore Redis/Memcached, and Spanner. Enabling services requires serviceusage.services.enable ; that permission belongs to the setup administrator, not the runtime account.

JSON key contents and controls Use JSON format and verify type , project_id , private_key_id , private_key , client_email , client_id , and token_uri are intact. The private key is downloadable only at creation. Transfer through the approved secret channel, import directly into the ServiceNow credential record, and securely remove temporary copies. Track key ID, owner, creation/rotation/revocation dates outside the private key. Rotate by importing a new key, validating it, switching the credential, then revoking the old key. If iam.disableServiceAccountKeyCreation is enforced, do not bypass policy. Obtain a security-approved exception or confirm a supported alternative authentication design with ServiceNow. Never place JSON, PEM text, tokens, service-account secrets, or full credential payloads in Discovery logs, screenshots, KB examples, or support tickets. Official basis: Google resource hierarchy , service-account security , key management , API enablement , and Cloud Asset IAM .

6. MID Server sizing, capability, network, DNS, proxy, and TLS Use a dedicated cloud-discovery MID Server. The official baseline calls for 16 CPU cores, 8 GB RAM, and 4 GB JVM allocation , with internet/API access. Treat this as a starting minimum: project count, API families, table-level database collection, parallel schedules, events, proxy latency, and payload size determine real capacity.

Status is Up and validation is successful. Capability includes Cloud Management (or an equivalent eligible capability delivered by the platform). Host and Java time are synchronized; monitor CPU, heap, disk, file descriptors, service restarts, and log growth. Use a MID cluster when failover/load distribution is required, but test credential affinity and capability on every node. Do not combine a large cloud schedule with unrelated high-volume workloads until baseline duration and capacity are known. Flow Transport Requirement/validation MID → ServiceNow instance Outbound HTTPS/TCP 443 Instance FQDN, DNS, proxy route, trusted certificate chain. No inbound connection to the MID is required for this channel. MID → Google OAuth Outbound HTTPS/TCP 443 The token URI from the JSON key, commonly oauth2.googleapis.com or accounts.google.com; DNS, TLS, proxy, and accurate system time. MID → Google APIs Outbound HTTPS/TCP 443 *.googleapis.com endpoints required by selected patterns, including Resource Manager, Compute, Cloud Asset, Storage, and service-specific APIs. Private Google API access Optional private/hybrid design Use documented private.googleapis.com or restricted.googleapis.com DNS/routes. restricted.googleapis.com exposes only services supported by VPC Service Controls; test every selected API. MID → guest VM Optional, separate Only when server discovery is enabled: routes/firewalls for approved SSH or Windows management ports and matching OS credentials. Security services Environment-dependent CRL/OCSP and enterprise proxy/TLS-inspection endpoints if required by local policy; the Java trust chain must validate. Read-only transport tests from the MID host # DNS resolution nslookup oauth2.googleapis.com nslookup compute.googleapis.com # HTTPS/TLS path. Any real HTTP response proves transport farther than a DNS/TLS failure. curl -sS -o /dev/null -w '%{http_code} ' https://www.googleapis.com/discovery/v1/apis curl -sS -o /dev/null -w '%{http_code} ' https://oauth2.googleapis.com/token Run tests from the same host and service context as the MID where possible. A browser test from an administrator laptop does not prove the MID path. If a proxy is mandatory, test through the same proxy and compare the certificate chain with what Java sees.

Official basis: ServiceNow GCP MID baseline , cloud MID configuration , network security , and Private Google Access .

7. Detailed end-to-end setup sequence The GCP console setup path covers project selection, service accounts, IAM, APIs, and logging. The ServiceNow path covers credentials, cloud service account, MID capability, property, schedule, status, ECC, and CMDB validation. Google Cloud console Project selectorchoose admin/target project IAM & Admin → IAMscope bindings and conditions IAM & AdminService Accounts → Keys → JSON APIs & ServicesLibrary / Enabled APIs Optional eventsCloud Logging coverage • filters • event permissionsOnly after full discovery succeeds ServiceNow Discovery → CredentialsGoogle API Credentials Cloud Service Accountproject/folder ID + credential MID ServersUp • validated • capability • property Discovery WorkspaceSchedules → Cloud-based → Google Validate in this orderDiscovery Status → Discovery Log → ECC QueuePattern/IRE result → CIs → relationships → source trace Release-neutral navigation map. Labels may move in a future UI; record types and validation order remain the operational anchors. Approve scope and method. Owner: service owner + GCP admin + CMDB owner. Record root type/ID, projects/exclusions, regions, services, labels/tags, full-discovery cadence, event decision, and guest-discovery decision. Evidence: signed onboarding worksheet. Prepare ServiceNow content. Owner: ServiceNow platform/Discovery admin. Verify required applications in section 4 are active and mutually compatible. Confirm delivered GCP patterns and classes exist. Evidence: application/content readiness record with no version-specific text in the public runbook. Prepare the dedicated MID. Owner: MID + network. Install/register/validate, set Cloud Management capability, confirm Up status and sizing, configure proxy/TLS trust, monitor resources, and test instance/OAuth/API paths. Evidence: successful validation and transport test from the MID host. Create the GCP runtime service account. Owner: GCP IAM admin. In the approved administrative project, use IAM & Admin → Service Accounts → Create service account . Give it a purpose-based name/description and no broad role during creation if centralized IAM will be applied separately. Evidence: account email and unique ID (no secret). Enable APIs. Owner: GCP project admin. In each in-scope project, use APIs & Services → Library or governed automation to enable Resource Manager/Compute plus every service selected in the pattern matrix. Evidence: enabled-service list by project. Grant runtime permissions at the correct resource. Owner: GCP IAM + security. Apply Viewer plus required supplemental permissions, or an approved tested custom role. Include hierarchy and Resource Inventory exceptions. Review conditions, deny policies, and perimeters. Evidence: binding export showing principal, role, resource, condition. Create and transfer the JSON key. Owner: key custodian. Use Service Accounts → selected account → Keys → Add key → Create new key → JSON . Transfer once through the approved secret channel. Record key metadata separately. Evidence: custody/rotation record; never attach the key to the onboarding ticket. Create Google API Credentials in ServiceNow. Owner: Discovery admin. Navigate to Discovery → Credentials → New → Google API Credentials . Choose Import JSON File , upload the intact key, confirm Name/Active/email/secret key/order/credential alias fields, and save. Restrict use/affinity to the intended MID where supported by local credential policy. Evidence: credential name, active state, intended MID eligibility, and successful test—no secret screenshot. Create the GCP cloud service account record. Owner: Discovery admin. Open cmdb_ci_cloud_service_account.list , select New , choose the credential, enter a unique name, set Account ID to the GCP project ID for a project root, leave Datacenter URL empty, and use Google Datacenter as datacenter type. For workspace onboarding at folder scope, use the Project/Folder ID field supplied by the cloud-account workflow. Evidence: one unambiguous record resolves to the approved root. Configure table collection only if required. Owner: Discovery admin + database service owner. Set sn_itom_pattern.google_dbservice_table_collection=True for BigQuery/Bigtable table collection, refresh MID configuration, and measure one project before expanding. Create the schedule. Owner: Discovery admin. Go to Discovery Admin Workspace → Schedules → New Discovery → Cloud-based discovery → Google . Use a unique name, select the Up/validated Cloud Management MID or cluster, select the account, all/specific projects, regions, frequency, window, and timeout. Enable the separate server-discovery schedule only if guest OS discovery is approved. Evidence: peer-reviewed schedule configuration. Run a controlled pilot. Start with one representative project and limited regions. Record discovery status, ECC correlation, first pattern/API errors, duration, quotas, CI/relationship counts, and retry behavior. Fix the first divergent layer, rerun the same pilot, then expand in batches. Enable optional events after baseline acceptance. Enable Cloud Logging/event prerequisites, set Pull Events on the service account, validate the event polling job, produce one controlled change, and prove it reaches IRE. Retain periodic full discovery as the repair/reconciliation mechanism. Operationalize. Agree credential rotation, content review, schedule capacity, quota monitoring, CI lifecycle, duplicate prevention, evidence retention/redaction, and escalation ownership. Test a repeat discovery and a key rotation before closure. Official basis: Google credential configuration , GCP service-account record , and GCP schedule creation .

8. Pilot validation and acceptance checklist Validate one representative resource through all layers. Do not declare success from a green schedule alone, and do not declare failure from an empty table until GCP confirms that the resource type actually exists in the selected scope.

Layer Pass condition Evidence to retain 1. Control plane Schedule saved/active; approved account/project/region scope; correct MID/cluster. Peer-reviewed schedule screenshot with identifiers redacted for public sharing. 2. ECC dispatch A new output row targets the selected MID and moves beyond Ready. Queue, topic/name/source, timestamps, state; do not export credential payloads. 3. MID execution MID logs show receipt and execution without connectivity, memory, proxy, or TLS failure. Narrow log excerpt around the correlated ECC timestamp. 4. Authentication OAuth token acquisition succeeds; no 401/invalid_grant/key error. HTTP status and sanitized error reason only. 5. Authorization/API The exact API method succeeds at the exact resource scope; zero results are reconciled with GCP inventory. Permission, API service, project/folder/org, error reason/domain. 6. Pattern Entry and helper steps complete; payload contains provider-native identity and expected attributes. Pattern name/step, row count, sanitized response shape. 7. IRE Item is inserted/updated or intentionally skipped with a clear reason; repeat run updates the same CI. IRE result, class, source-native key, operation; no tenant identifiers in public material. 8. CMDB Expected class, relationships, tags, project/region/zone, state, and source trace are present. Class-level counts and one redacted example relationship path. Read-only GCP evidence examples # Effective project bindings for the discovery principal gcloud projects get-iam-policy PROJECT_ID --flatten='bindings[].members' --filter='bindings.members:SERVICE_ACCOUNT_EMAIL' --format='table(bindings.role,bindings.condition.title)' # Enabled APIs in a target project gcloud services list --enabled --project=PROJECT_ID --format='value(config.name)' # Provider-side object existence checks (choose only in-scope services) gcloud compute instances list --project=PROJECT_ID gcloud asset search-all-resources --scope=projects/PROJECT_ID --limit=20 Run with an approved administrative/test identity or the runtime identity according to the test purpose. Do not print access tokens or private keys. Compare the exact resource scope and API response with the matching Discovery pattern step.

9. How GCP patterns are selected and chained The cloud schedule is the entry point. Delivered orchestration first validates the account and discovers hierarchy/logical datacenters, then launches the applicable resource patterns and shared/helper patterns. The 29 logical pattern groups in section 10 are therefore not 29 independent schedules .

Entry/orchestrator patterns Receive schedule scope and launch hierarchy/resource collection. Resource patterns Call one or more Google APIs and construct resource/relationship payloads. Shared/helper patterns Get regions, zones, networks, tags, endpoints, or other reusable data; do not schedule them directly. Extensions/customization Preserve delivered content. Use supported extensions and CMDB governance; cloning an out-of-box pattern creates upgrade drift. Pattern requirement logic A pattern is useful only if the service exists in scope, its API is enabled, its permissions are effective at that resource, the target class/content exists, and its dependencies returned identities/locations. Global and regional/zonal resources follow different enumeration paths. A correct project with a wrong region filter can yield a legitimate zero result. Errors in a shared region/network/instance-group helper can make several downstream patterns look empty. Repair the shared dependency first. After content updates, compare the current official Cloud Discovery pattern spreadsheet with the customer’s custom role and enabled-API list. 10. Complete GCP pattern and API permission catalog This catalog covers every logical GCP pattern group in the supplied Cloud Discovery API inventory. It is a planning baseline, not a static replacement for the official spreadsheet: permissions and pattern coverage can change with current content. Always reconcile the customer’s role against the latest published inventory before production rollout.

Permission interpretation: every listed permission must be effective at the resource that owns the API object. API enablement is separate. Resource Inventory also requires Cloud Asset and destination storage access. A malformed permission in the source sheet was normalized to the valid compute.instances.list permission below. Domain Pattern group Use Primary CMDB targets Required API permissions Operational note Foundation Validate Service Account Proves the credential can resolve the configured project/folder before broad collection. cmdb_ci_cloud_service_account resourcemanager.folders.get resourcemanager.projects.get Run first. A failure here makes downstream pattern errors secondary. Foundation Discover Google Organization Builds the organization → folder → project → logical-datacenter hierarchy and tag context. cmdb_ci_cloud_org cmdb_ci_gcp_folder cmdb_ci_gcp_project cmdb_ci_google_datacenter cmdb_key_value resourcemanager.organizations.get resourcemanager.folders.get resourcemanager.projects.list resourcemanager.projects.getAncestry Grant at the hierarchy root that is intentionally in scope. Foundation Discover Related Projects Enumerates projects below the selected organization/folder so schedules can cover all or selected projects. cmdb_ci_cloud_service_account resourcemanager.folders.list resourcemanager.projects.list resourcemanager.projects.getAncestry Missing folder inheritance commonly produces an incomplete project picker. Foundation Get Logical Datacenters Returns regional containers available to the service account. cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.regions.list Shared helper used before region-scoped discovery. Foundation Logical Datacenters Creates/updates Google regions and zones used as location parents for resource CIs. cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.regions.list compute.zones.list Expected before most compute, network, database, and storage CIs. Foundation Resource Inventory Uses Cloud Asset Inventory to collect supported resources not covered by a specialized class and preserves provider metadata/tags. cmdb_ci_cmp_resource cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter cmdb_key_value serviceusage.services.use cloudasset.assets.exportResource or the exact required cloudasset.assets.export* permissions compute.regions.list compute.zones.list storage.buckets.get storage.buckets.list storage.objects.get Cloud Asset export and its Cloud Storage destination are separate permission checks. Compute Virtual Server Discovers VM instances, templates, images, machine types, disks, NIC/VNIC endpoints, public IPs, SSH-key references, zones, and tags. cmdb_ci_vm_instance cmdb_ci_compute_template cmdb_ci_instance_template cmdb_ci_cloud_os_image cmdb_ci_storage_volume cmdb_ci_nic cmdb_ci_endpoint_vnic cmdb_ci_endpoint_block cmdb_ci_cloud_public_ipaddress cmdb_ci_cloud_key_pair cmdb_key_value compute.instances.list compute.instanceTemplates.list compute.images.list compute.machineTypes.list compute.disks.list compute.regions.list compute.zones.list API discovery identifies the cloud object; optional guest discovery identifies the operating system and installed software. Compute Disk Types Discovers Google disk-type offerings used by storage and VM relationships. cmdb_ci_disk_type cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.diskTypes.list A prerequisite for complete disk/type relationships. Compute External IP Addresses Discovers reserved/assigned external addresses and links them to cloud resources. cmdb_ci_cloud_public_ipaddress cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.addresses.list compute.regions.list compute.zones.list Validate global and regional address scope. Compute SSH Keys Collects project-level SSH key metadata and represents cloud key pairs. cmdb_ci_cloud_key_pair cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.projects.get compute.regions.list compute.zones.list This does not provide an operating-system login credential. Compute Get Kubernetes Clusters Discovers Google Kubernetes Engine cluster inventory and cloud placement. cmdb_ci_kubernetes_cluster cmdb_ci_cloud_service_account cmdb_ci_google_datacenter container.clusters.list Cluster internals may require separate Kubernetes discovery and credentials. Network Networking Discovers VPC networks, subnets, firewall ACLs/rules, regions, and zones. cmdb_ci_network cmdb_ci_cloud_subnet cmdb_ci_network_acl cmdb_ci_network_acl_rule cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.networks.list compute.subnetworks.list compute.firewalls.list compute.regions.list compute.zones.list Foundation for VM NIC and load-balancer relationships. Network Networking Events Processes network change events for near-real-time CMDB updates after full discovery. cmdb_ci_network cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.networks.list compute.regions.list compute.zones.list Optional event path; not a substitute for initial or periodic full discovery. Network Networking Firewall Events Processes firewall change events and refreshes network ACL/rule CIs. cmdb_ci_network cmdb_ci_network_acl cmdb_ci_network_acl_rule cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.firewalls.list compute.networks.list compute.regions.list compute.zones.list Requires the event collection path and Cloud Logging coverage. Network Subnetwork Events Processes subnetwork changes and refreshes subnet/network relationships. cmdb_ci_cloud_subnet cmdb_ci_network cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.subnetworks.list compute.networks.list compute.regions.list compute.zones.list Use full discovery to repair missed events. Load balancing Load Balancer HTTP Builds HTTP/HTTPS load balancers, services, pools, members, health services, proxies, forwarding rules, and URL-map relationships. cmdb_ci_cloud_load_balancer cmdb_ci_lb_service cmdb_ci_lb_pool cmdb_ci_lb_pool_member cmdb_ci_lb_health_service cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.backendServices.list compute.forwardingRules.list compute.healthChecks.list compute.httpHealthChecks.list compute.httpsHealthChecks.list compute.instanceGroupManagers.list compute.instanceGroups.list compute.instances.list compute.regions.list compute.targetHttpProxies.list compute.targetHttpsProxies.list compute.targetSslProxies.list compute.targetTcpProxies.list compute.urlMaps.list compute.zones.list Corrected permission spelling: compute.instances.list. Load balancing Load Balancer TCP/UDP Builds TCP/UDP load-balancer topology, pools/members, health checks, target pools/proxies, and forwarding rules. cmdb_ci_cloud_load_balancer cmdb_ci_lb_service cmdb_ci_lb_pool cmdb_ci_lb_pool_member cmdb_ci_lb_health_service cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.forwardingRules.list compute.healthChecks.list compute.httpHealthChecks.list compute.httpsHealthChecks.list compute.instanceGroupManagers.list compute.instanceGroups.list compute.instances.list compute.regions.list compute.targetHttpProxies.list compute.targetHttpsProxies.list compute.targetPools.list compute.targetSslProxies.list compute.targetTcpProxies.list compute.zones.list Missing instance-group permissions typically leaves pools without members. Security Certificate Manager Certificates Discovers certificates managed by Certificate Manager plus relevant regional context. cmdb_ci_certificate certificatemanager.certs.list certificatemanager.locations.list compute.sslCertificates.list Certificate Manager uses certificatemanager.certs.list even though the REST resource is named certificates. Security Classic Certificates Discovers Compute Engine SSL certificates used by classic load-balancing resources. cmdb_ci_certificate compute.sslCertificates.list Keep both certificate patterns if both certificate models exist. Storage Storage Discovers persistent disks and snapshots and links them to zones, VMs, and cloud accounts. cmdb_ci_storage_volume cmdb_ci_storage_vol_snapshot cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter compute.disks.list compute.snapshots.list compute.regions.list compute.zones.list This row is Compute persistent storage; Cloud Storage is used separately by Resource Inventory export. Database GCP AlloyDB for PostgreSQL Discovers AlloyDB clusters/instances, database services, zones, tags, and account relationships. cmdb_ci_cloud_database cmdb_ci_cloud_db_cluster cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter cmdb_key_value alloydb.clusters.list alloydb.instances.list compute.regions.list compute.zones.list Enable AlloyDB API in every project that is in scope. Database BigQuery DB Discovers BigQuery datasets and, when enabled by the MID property, table-level records. cmdb_ci_cloud_database cmdb_ci_cloud_public_database cmdb_ci_database cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter cmdb_key_value bigquery.datasets.get bigquery.tables.list resourcemanager.projects.get compute.regions.list compute.zones.list Set sn_itom_pattern.google_dbservice_table_collection=True for table collection; assess volume before enabling broadly. Database Bigtable DB Discovers Bigtable instances, clusters, and tables when table collection is enabled. cmdb_ci_cloud_database cmdb_ci_cloud_db_cluster cmdb_ci_database cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter cmdb_key_value bigtable.instances.list bigtable.clusters.list bigtable.tables.list compute.regions.list compute.zones.list Uses the same table-collection property as BigQuery. Database Cloud SQL DB Discovers Cloud SQL instances/databases and relates them to the cloud account, region/zone, and tags. cmdb_ci_cloud_database cmdb_ci_database cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter cmdb_key_value cloudsql.instances.list cloudsql.databases.list compute.regions.list compute.zones.list Cloud SQL Admin API must be enabled; discovery does not need a database login for the API inventory layer. Database Firebase Realtime DB Discovers Firebase Realtime Database instances and regional/account placement. cmdb_ci_cloud_database cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter firebasedatabase.instances.list compute.regions.list compute.zones.list Empty results can be valid when no instances exist in selected projects. Database Firestore DB Discovers Firestore/Datastore databases and regional/account placement. cmdb_ci_cloud_database cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter datastore.databases.list compute.regions.list compute.zones.list Verify the API is enabled in the resource-owning project. Database Memorystore DB Discovers Redis, Redis Cluster, and Memcached instances/clusters and tags. cmdb_ci_cloud_database cmdb_ci_cloud_db_cluster cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter cmdb_key_value redis.instances.list redis.clusters.list memcache.instances.list compute.regions.list compute.zones.list Enable and grant for only the services actually used. Database Spanner DB Discovers Spanner instances, instance configurations, databases, region/zone placement, and tags. cmdb_ci_cloud_database cmdb_ci_database cmdb_ci_availability_zone cmdb_ci_cloud_service_account cmdb_ci_google_datacenter cmdb_key_value spanner.instances.list spanner.instanceConfigs.list spanner.databases.list compute.regions.list compute.zones.list Database list is evaluated within discovered instances. Serverless Cloud Functions Discovers first- and later-generation function resources, including Cloud Run-backed services where applicable. cmdb_ci_cloud_function cmdb_key_value cloudfunctions.functions.list run.services.list Enable the Cloud Functions and Cloud Run APIs for projects that host the corresponding function generation. Source basis: the current ServiceNow GCP pattern documentation and its regularly updated Cloud Discovery API-permissions inventory, cross-checked with Google IAM documentation for Cloud Asset Inventory and Certificate Manager.

11. End tables, meanings, important values, and validation The first table lists the 37 primary CMDB targets represented in the GCP API inventory. Field availability varies by installed class model and content. Validate provider-native identity, source, location/account context, lifecycle/state, and relationships rather than relying on display name alone.

CMDB target tables Table Label What it represents Important values/validation cmdb_ci_cloud_service_account Cloud Service Account Discovery root for a GCP project or folder; references the Google API credential. Unique name; Account ID/Project or Folder ID; Google datacenter type; credential reference; Pull Events only when event collection is intended. cmdb_ci_cloud_org Cloud Organization Top-level Google organization container. Provider-native organization identity; relationships to folders/projects. cmdb_ci_gcp_folder Google Organization Folder Folder hierarchy and delegated discovery scope. Provider-native folder identity and correct parent organization/folder. cmdb_ci_gcp_project Google Organization Project GCP project container discovered below the selected root. Project ID/native identity and correct parent folder/organization. cmdb_ci_google_datacenter Google Datacenter Logical region container for Google resources. Region name/provider identity and Hosted on::Hosts relationship to the cloud service account. cmdb_ci_availability_zone Availability Zone Zone container used by zonal resources. Zone name, logical datacenter relationship, provider identity. cmdb_ci_vm_instance Virtual Machine Instance Provider-side VM object. Native object ID, name, lifecycle/power state, project, region/zone, machine type, discovery source, relationships to disks/NICs/images. cmdb_ci_compute_template Hardware Type Machine type or compute sizing template. Provider name/type and region/zone applicability. cmdb_ci_instance_template Instance Template Reusable VM instance template. Native template ID/name and project relationship. cmdb_ci_cloud_os_image Cloud Image Provider image used to create a VM. Image identity, project/family metadata, VM relationship. cmdb_ci_os_template Image Generic image/template superclass used by dependent relationships. Class/model relationship; do not validate this table alone when the Google subclass is populated. cmdb_ci_disk_type Cloud Disk Type Persistent disk performance/type offering. Type name and location relationship. cmdb_ci_storage_volume Storage Volume Persistent disk attached or available to VMs. Native disk ID, state, type, size, zone/region, attachment relationships. cmdb_ci_storage_vol_snapshot Storage Volume Snapshot Persistent-disk snapshot. Native snapshot ID, status, source-volume relationship, project. cmdb_ci_network Cloud Network GCP VPC network. Native network identity, project, auto/custom mode metadata, relationships. cmdb_ci_cloud_subnet Cloud Subnet Regional VPC subnetwork. Native subnet identity, region, CIDR metadata, parent network. cmdb_ci_nic Cloud Mgmt Network Interface VM network interface. Native interface identity, VM/network/subnet relationships, IP associations. cmdb_ci_endpoint_vnic VNIC Endpoint Endpoint representation for a virtual NIC. Bound NIC/VM and address relationships. cmdb_ci_endpoint_block Block Endpoint Endpoint representation for block storage attachment. VM-to-volume attachment identity and relationship. cmdb_ci_cloud_public_ipaddress Cloud Public IP Address Reserved or assigned external address. Address, region/global scope, state, target relationship. cmdb_ci_network_acl Network ACL Logical container for a cloud firewall policy/rules. Network/project scope and relationship to rules. cmdb_ci_network_acl_rule Network ACL Rule Individual firewall rule. Direction, priority, action, protocol/ports, source/destination ranges, parent ACL. cmdb_ci_cloud_load_balancer Cloud Load Balancer Top-level load balancer CI. Native identity, scheme/scope, frontend/backend relationships. cmdb_ci_lb_service Load Balancer Service Frontend/listener or service component. Protocol/port, forwarding rule or proxy relationship. cmdb_ci_lb_pool Load Balancer Pool Backend pool or instance group. Backend service/group identity and parent load balancer. cmdb_ci_lb_pool_member Load Balancer Pool Member VM/backend membership. Pool and VM/endpoint relationships; health is evaluated separately. cmdb_ci_lb_health_service Cloud Load Balancer Health Service Health-check configuration used by a backend. Protocol, port/path, interval/thresholds, pool/service relationship. cmdb_ci_cloud_key_pair Cloud Key Pair Cloud SSH-key metadata. Key name/fingerprint/owner metadata only; never expect a private key. cmdb_ci_certificate Unique Certificate Certificate Manager or classic SSL certificate metadata. Name, fingerprint/serial/validity where returned, and load-balancer relationship. cmdb_ci_kubernetes_cluster Kubernetes Cluster GKE cluster resource. Native cluster identity, endpoint/location/project, cloud account relationship. cmdb_ci_cloud_function Cloud Function Serverless function resource. Native identity, region, runtime/generation/status where returned, tags. cmdb_ci_cloud_database Cloud Database Managed database service/instance. Native identity, engine/service type, state, region/zone, project, cluster relationship. cmdb_ci_cloud_db_cluster Cloud Database Cluster Managed database cluster container. Native cluster identity, service type, member-database/instance relationships. cmdb_ci_cloud_public_database Cloud Public Database Public cloud database specialization used by supported patterns. Provider/project/location identity and subclass consistency. cmdb_ci_database Database Database or table-level logical record used by database patterns. Name/native key and parent managed database/cluster; table-level volume depends on the collection property. cmdb_ci_cmp_resource Cloud Resource Generic cloud asset when no specialized CMDB class is used. Provider asset type, native name/key, project/location, source, tags. cmdb_key_value Key Value Cloud labels/tags associated with a CI. Key, value, and the correct CI reference; duplicate/stale labels indicate source-key or reconciliation issues. Operational and governance tables Table Meaning Important fields/values How it is used discovery_schedule Discovery schedule definition Name, active, type=cloud-based, provider=Google, MID/cluster, account, project/region scope, frequency, timeout. Configuration exists and scope matches the approved onboarding worksheet. discovery_status One execution of a schedule Start/end, state/result, devices/resources processed, errors, linked logs/ECC activity. Latest run completes; compare elapsed time and error count with prior runs. discovery_log Human-readable Discovery messages Level, source, message, status/run association, pattern/step context. Filter to one run and find the first error, not the final cascade. ecc_queue Instance↔MID work transport Queue=output means instance to MID; queue=input means MID to instance. State commonly ready, processing, processed, or error. Topic may be Horizontal Pattern. Output is consumed by the intended MID; correlated input returns; error_string/payload show the first transport or pattern failure. sa_pattern Pattern definitions Name, active, target CI type, extensions/shared libraries. Delivered GCP entry patterns are active and compatible; helper patterns are invoked by orchestration, not scheduled independently. cmdb_rel_ci CMDB relationship graph Parent, child, relationship type. Cloud account→logical datacenter→zone/resource and resource-to-resource relationships are present, not only standalone CIs. sys_object_source Source/native-key trace for IRE Source name, source-native key, target CI/reference, last-seen/source metadata. A stable provider-native identity maps to one target CI; use this when duplicates or non-updates occur. cmdb_identifier / cmdb_identifier_entry Identification rules Class, active entries, attributes, priority/independence. Do not change for one incident until source-native identity and delivered rules have been proven insufficient. cmdb_reconciliation_definition Reconciliation authority Target class/attributes, data source, precedence/conditions. A lower-authority source is not blocking the expected Discovery attribute updates. Value semantics that prevent false conclusions Name is not identity. GCP display names can repeat; provider-native object IDs/self-links and project/location context drive stable identification. Power/lifecycle state is not CMDB install status. A stopped VM still exists. Do not retire it merely because the provider power state is stopped. Discovery source is provenance, not ownership. Use sys_object_source and reconciliation rules to determine which source may update attributes. Tags/labels are separate rows. Validate cmdb_key_value is linked to the correct CI; an empty tag table does not mean the resource CI failed. CI presence is not relationship completeness. Validate cmdb_rel_ci paths such as account→datacenter→zone/resource and VM→NIC/network/disk. Zero records can be correct. Reconcile with provider inventory for the same principal, project, API, region, and timestamp before classifying a Discovery defect. 12. Troubleshooting by first divergent layer Start with schedule and ECC, then MID transport, authentication, authorization/API, pattern/IRE, and finally CMDB records and relationships. Schedule/ECCwork dispatched? MID transportDNS • proxy • TLS? OAuth401 / invalid key? IAM/API403 • 404 • quota? Pattern/IREpayload accepted? CMDBCI + relationship? No output/ReadyNo input/timeoutFix key/time firstExact method + scopeParser/IRE resultSource/relations Stop at the first failing box. Later symptoms are expected until it passes. Use one run, one resource, and one correlated timestamp to avoid mixing unrelated failures. Preserve the exact HTTP code, Google ErrorInfo.reason , API domain, permission, resource name/scope, pattern step, and correlated ECC timestamp. Google standardizes machine-readable error details; the text alone can change and is less reliable than code/reason/domain metadata.

Symptom/error Most likely layer Resolution sequence Primary owner No ECC output created Schedule/account selection, application/content, UI validation, permissions before execution. Open the schedule and one discovery status. Confirm it launched, is active, has a Google account, regions/projects, and an Up/validated Cloud Management MID. ServiceNow Discovery admin ECC output remains Ready The selected MID is not polling/eligible or cannot reach the instance. Verify MID status/validation/capability, agent name match, outbound HTTPS to the instance, proxy, certificate trust, and MID logs. MID owner + network No correlated ECC input MID accepted work but cannot complete/return it. Correlate by response-to/source; inspect MID agent and wrapper logs, proxy/DNS/TLS, process memory, and request timeout. MID owner 401 UNAUTHENTICATED / invalid_grant Invalid/deleted key, wrong service-account email/private key pairing, malformed JSON, token endpoint blocked, or clock skew. Re-import an intact JSON key; confirm key is enabled and belongs to client_email; verify token_uri reachability and NTP. Rotate rather than editing PEM text. GCP IAM + ServiceNow Discovery 403 PERMISSION_DENIED Principal authenticated but lacks an action at the requested resource scope; API may be disabled or VPC Service Controls may deny it. Record error reason/domain/resource. Test the exact permission on the exact org/folder/project. Check inheritance, IAM conditions, deny policies, API enablement, and perimeter audit logs. GCP IAM/security 403 API not enabled / SERVICE_DISABLED The API is disabled in the project used for the request or quota attribution. Enable the API in every resource-owning project that uses the pattern. Wait for propagation and rerun only the affected scope. GCP project admin 403/429 QUOTA_EXCEEDED or RATE_LIMIT_EXCEEDED Concurrent schedules, broad scope, database table collection, or provider quota. Stagger schedules, reduce concurrency/scope, check IAM & Admin > Quotas & System Limits, and request quota adjustment only with measured evidence. GCP admin + Discovery admin 404 NOT_FOUND Wrong Project/Folder ID, deleted resource, unsupported location, or permission masking depending on API. Confirm the provider-native ID from GCP, schedule scope, and error resource. Re-test with an identity known to have permission before declaring the object missing. GCP resource owner 5xx / UNAVAILABLE / timeout Transient provider service, proxy idle timeout, DNS/TLS failure, oversized response, or MID resource pressure. Check provider service status, retry with backoff, test DNS/TLS from the MID host, inspect proxy timeout/response limits, and compare CPU/heap during the run. Network + MID + GCP SSL handshake / PKIX / certificate error TLS interception or missing trust chain on MID Java runtime. Compare the certificate chain seen from the MID with the expected endpoint; import only approved enterprise CA chains using supported MID procedures; do not disable verification globally. Security + MID Proxy authentication / 407 MID proxy settings or service-account operating-system permissions are wrong. Validate authenticated proxy configuration, credential ownership/file permissions, service restart, and a direct HTTPS test from the MID service context. Network + MID Folder/project picker is empty or incomplete Missing hierarchy list/get/getAncestry permissions, wrong root ID, IAM condition, or non-inherited grant. Test organization/folder/project enumeration independently; verify the grant is on the intended hierarchy root and the projects are active. GCP IAM Credential validates, but one resource family is empty A service-specific API/permission is missing; empty may also be a valid zero-resource result. Find the first failing pattern/API call. Compare its prefix to the permission matrix, verify API enablement, then confirm a resource actually exists in selected projects/regions. GCP service owner + Discovery BigQuery/Bigtable datasets appear but tables do not Table collection property is false/not read by the executing MID, permission missing, or volume/timeout issue. Set sn_itom_pattern.google_dbservice_table_collection=True on the appropriate MID property scope, refresh MID configuration, verify tables.list, and test one project first. Discovery admin Load balancer exists but pools/members are missing Instance group/backend/health/target-proxy permission gap or relationship step failure. Verify each required compute.*.list permission, then inspect the first load-balancer pattern step that returned zero/error and validate source object IDs. GCP network + Discovery Pattern reports success but no CI is created Payload is empty, class model is missing, parser/transform failed, or IRE rejected/skipped the item. Review pattern step output and IRE result for one resource; verify class exists, native key is present, and rejection/duplicate details before editing identifiers. Discovery + CMDB Duplicate CIs Provider-native keys changed/missing, multiple sources use inconsistent identity, or identifiers were customized. Compare object IDs, sys_object_source mappings, Discovery source, and identification attempts. Repair authoritative keys/rules through governed CMDB change; do not bulk-merge blindly. CMDB owner CIs are stale after deletion or scope change Events were missed, full discovery cadence is too long, or retirement/deletion behavior is not aligned with governance. Run a controlled full discovery, review last-discovered/source records and stale-CI policy, and agree whether to retire, mark absent, or delete through CMDB governance. CMDB + service owner Event-driven updates do not arrive Initial full discovery/hierarchy absent, Pull Events disabled, Cloud Logging/API/permissions missing, polling job unhealthy, or log scope excludes the event. Confirm full discovery first; verify Pull Events and event job, Cloud Logging coverage, API access, event timestamp/filter, and IRE outcome. Keep periodic full discovery. GCP logging + Discovery HTTP distinction: 401 generally means the caller was not authenticated; 403 means an authenticated principal was denied or a policy/API/quota condition blocked it; 404 means not found when the caller is authorized, although some services can intentionally mask existence. 429 and some 403 variants indicate quota/rate limits. Retry transient 5xx/UNAVAILABLE with backoff; do not retry permanent 401/403 without a configuration change. Official basis: Google API error model , IAM permission errors , and quota troubleshooting .

13. Detailed diagnostic procedures A. Schedule does not start or account/regions do not appear Confirm operator has discovery_admin and the required workspace/content loads. Verify one active Google credential and a unique cloud service-account record with the correct Project/Folder ID. Confirm the MID is Up, validated, and Cloud Management-capable; the schedule picker intentionally filters ineligible MIDs. Use Verify information after any IAM/policy change. An empty project/region list is usually hierarchy permission, root-ID, API, or MID reachability—not CMDB. Save a new pilot schedule with one project/region and run on demand. B. Credential test fails with 401 or invalid_grant Do not grant more IAM roles; 401 occurs before resource authorization. Confirm the JSON belongs to the intended service account and that client_email , private_key_id , PEM boundaries/newlines, and token_uri are intact. Check the key still exists and is enabled; if uncertain, create/approve a new key, import it, validate, then revoke the old key. Verify MID host clock/NTP and OAuth DNS/TLS/proxy path. Do not copy private-key content into logs for comparison. Compare key ID and account email only. C. Credential works but folder/project enumeration fails Confirm whether the configured root is an organization, folder, or project and use its correct ID—not display name. Test resourcemanager.organizations.get , folders.get/list , projects.list , and projects.getAncestry at the intended root. Inspect binding inheritance, IAM conditions, group membership, deny policies, and organization restrictions. Confirm the project is active and actually below the selected root. After IAM changes, allow propagation, reverify the account, refresh project/region choices, and rerun the same pilot. D. One service pattern is empty while compute works Prove the resource exists in the same project/region by using the provider console or a read-only API list with the same principal. Find the first API call in the failing pattern and note service domain and permission. Enable that service’s API in the resource-owning project; verify the precise list/get permission and any parent-resource permission. Check whether the class/pattern is present in current compatible content and whether the service uses global, regional, or zonal enumeration. Rerun one project. A zero-resource result with no error and matching provider inventory is successful discovery. E. ECC output is Ready or processing for too long Output/Ready means work is waiting for the target MID. Confirm Agent equals the intended MID, status is Up, validation/capability are current, and service is running. Inspect MID agent and wrapper logs at the ECC creation time. Check instance connectivity, proxy authentication, certificate chain, thread/worker exhaustion, heap, and disk. Correlate output with its input response. Do not treat every input/Ready row as stuck; some input rows await instance processing. Avoid deleting ECC rows as a first response. Preserve evidence, fix the cause, then rerun a controlled schedule. F. Pattern completes but IRE does not create/update the CI Inspect the pattern payload/result for class name, provider-native key, project/account/location, and relationship identifiers. Read the IRE result to distinguish insert, update, skip, duplicate, identification failure, or reconciliation block. Confirm the target class exists and sys_object_source maps the native key to the expected CI. Review delivered identifier and reconciliation rules with the CMDB owner. A lower-authority source may block attributes even when identification succeeds. Do not modify an identifier, reconciliation rule, or CI manually until a repeatable authoritative-key problem is proven. G. Duplicate or wrong relationships Compare provider object ID, project, region/zone, source-native key, Discovery source, and account relationship across candidate CIs. Trace relationship creation in the same pattern/IRE payload. Missing parent identities can create orphan or incomplete topology. Check multiple integrations/manual imports for different identity conventions. Repair the authoritative input or governed identification rule, test one resource twice, then use approved deduplication—not direct mass deletion. H. Event updates fail but full discovery works Confirm full discovery produced the account/logical datacenter/resource before enabling events. Verify Pull Events, Cloud Logging service/coverage, event filters, permissions, and the GCP event polling job. Generate one controlled supported resource change; correlate cloud log timestamp to polling, ECC/pattern, IRE, and CI update. Review VPC Service Controls and logging-project placement when logs are centralized. Retain scheduled full discovery to reconcile missed/out-of-order events and deletions. I. Network, DNS, proxy, or TLS error Test DNS and TCP/TLS from the MID host/service context to the instance, OAuth endpoint, and the exact failing API domain. Confirm proxy bypass/allow rules, authentication, idle/response-size timeouts, and TLS inspection policy. Compare the certificate chain with Java trust; add only approved CA chains through supported MID procedures. For private Google access, validate private DNS CNAME/VIP routes and that every required service is supported by the chosen private/restricted endpoint. Never disable certificate validation globally to make Discovery pass. J. Safe rerun sequence Capture one failing run’s status, ECC correlation, first error, API domain/permission/scope, and MID log timestamp. Make one controlled correction at the first failing layer. Refresh MID configuration/restart only when the changed setting requires it. Rerun the same one-project pilot; compare duration, API result, IRE action, and CI count. Repeat to prove idempotence, then expand scope in batches and monitor quota/capacity. 14. Security, lifecycle, and operational controls Control Minimum operating requirement Credential inventory Owner, purpose, service-account email, key ID, created/last-rotated/next-rotation dates, approved scopes; never private key. Least privilege Current selected-pattern permission list, effective hierarchy scope, conditions/denies/perimeter decision, change review after content updates. MID hardening Dedicated service identity, patched host/runtime, restricted admin access, outbound allow policy, proxy/TLS configuration, monitored resources/logs. Schedule governance Non-overlapping windows, controlled concurrency, project/region allowlist, timeout baseline, owner, maintenance calendar. CMDB governance Identification/reconciliation ownership, required relationships, source precedence, stale-CI and decommission handling, duplicate remediation approval. Evidence privacy Redact project/customer identifiers, emails, IPs, object IDs where sensitive, tokens, secrets, raw payloads, instance URLs, and private keys before public sharing. Recurring review After pattern/content changes: diff permissions/APIs/target classes and retest the custom role. After hierarchy/IAM/policy changes: reverify project enumeration and one service family. Before key rotation: create/import/test new key; after success, revoke old key and record evidence. Monthly or at agreed cadence: compare schedule duration/errors, MID capacity, API quota, CI freshness, orphan relationships, and duplicates. After adding new GCP services/projects/regions: update the onboarding worksheet, API list, IAM, schedule scope, and acceptance evidence. 15. Evidence package for a fast, privacy-safe escalation Collect one failing resource and one run. Redact secrets and customer identifiers before external sharing.

Problem statement: expected resource/class versus actual result; when it last worked; blast radius. Approved scope: root type, affected project/region/service, event or full discovery, guest discovery yes/no. Schedule and run: schedule configuration summary, discovery-status start/end/state/error count. ECC correlation: output and input timestamps, agent, topic/name/source, state, error string; sanitized payload excerpt only when needed. MID evidence: status/validation/capability, resource metrics, agent/wrapper log excerpt at the exact timestamp, proxy/TLS/DNS test. GCP evidence: HTTP code, ErrorInfo.reason , API domain/method, denied permission, resource scope, enabled-API result, relevant IAM binding/condition/deny/perimeter result. Pattern/IRE: pattern and first failing step, row count/response shape, IRE operation/rejection, target class and source-native-key shape. CMDB: expected/actual class counts, one redacted CI, relationships, source mapping, identification/reconciliation customization status. Change history: key/IAM/API/network/content/schedule changes around the first failure. Never attach: service-account JSON, PEM/private key, OAuth token, proxy password, complete raw payload with sensitive labels, full instance URL, or unredacted customer/project identifiers. 16. Official references and maintenance note Source policy: ServiceNow documentation defines supported navigation, components, and pattern requirements; Google Cloud documentation defines resource hierarchy, IAM/API behavior, key controls, private connectivity, and error semantics. The customer must compare permissions with the latest official Cloud Discovery pattern spreadsheet whenever content changes.

ServiceNow: GCP discovery: prerequisites, MID baseline, Viewer role, BigQuery/Bigtable property, pattern/API inventory ServiceNow: Configure Google API credentials for Cloud Discovery ServiceNow: Create GCP service accounts ServiceNow: Create a GCP Discovery schedule in Discovery Admin Workspace ServiceNow: GCP Cloud Discovery methods and use cases ServiceNow: Install and configure MID Servers to access cloud environments ServiceNow: MID Server ECC Queue ServiceNow: Network security for MID Server communication Google Cloud: Resource hierarchy Google Cloud: Service-account security best practices Google Cloud: Create and delete service-account keys Google Cloud: Enable and disable APIs/services Google Cloud: Cloud Asset Inventory roles and permissions Google Cloud: Certificate Manager roles and permissions Google Cloud: Configure Private Google Access Google AIP: Canonical API error model and ErrorInfo Google Cloud: IAM permission error messages Google Cloud: Troubleshoot quota and rate-limit errors Release-neutral maintenance rule: do not freeze plugin versions, screenshots, IAM permissions, or navigation labels into an evergreen public KB. Review official references and the current permission inventory before each new onboarding or material content update.