› CIS-DF Hub › Part 2 › Service Graph Connectors
⬡ Part 2 · Topic 5

Service Graph Connectors & the MID Server

ServiceNow cannot always reach your infrastructure directly. Service Graph Connectors (SGC) are pre-built integrations that pull discovery data from third-party sources — cloud providers, CMDBs, monitoring tools — and route it through ServiceNow's Identity and Reconciliation Engine (IRE) to create accurate, deduplicated CI records. This topic introduces the MID Server, the on-premise bridge that makes it all work.

📋 10 sections ⏱ ~35 min read 🎯 ~19% exam weight (INGEST domain) 🏷 SGC · MID Server · IRE · CI Lifecycle
🔗
Forward References — Concepts Introduced Here, Covered Later This topic introduces two key concepts that are covered in depth in later parts: MID Server (covered fully in Part 3 Topic 2 — Discovery Architecture) and IRE — the Identity and Reconciliation Engine that processes all SGC data (covered fully in Part 4). You only need a working understanding of both here; the exam details are in those dedicated topics.
Section 1

Why Direct Table Writes Break Your CMDB

In the previous topics you learned how Import Sets work: data lands in a staging table, Transform Maps move it to the target CMDB table, and Coalesce fields decide whether to create a new record or update an existing one. That pipeline is powerful for one-time migrations and scheduled batch loads.

But imagine you have five different tools that all know about your servers — AWS Config, VMware vCenter, a monitoring agent, a manual spreadsheet import, and your own homegrown CMDB. All five start writing to the same cmdb_ci_server table. What happens?

  • Duplicates. Tool A writes a server with IP 10.0.0.5. Tool B also writes it, but with a slightly different hostname. Now you have two CI records for the same physical machine.
  • Overwriting good data with bad data. Your authoritative source set serial_number = SN-12345. A less-reliable source overwrites it with serial_number = UNKNOWN. The good data is gone.
  • No audit trail. You cannot tell which source populated which field, making it impossible to debug quality problems.
🏗️
Analogy — Multiple Contractors, No Foreman Imagine building a house where five contractors show up and each one starts framing walls without coordinating. One builds the east wall. Another demolishes it because their blueprint was different. A third comes back and builds it again in a different spot. The result is chaos. What you need is a foreman who receives all inputs, applies rules, and issues the one authoritative instruction. In ServiceNow, that foreman is the Identity and Reconciliation Engine (IRE). Service Graph Connectors are the contractors — each brings specialized data — but IRE is the one who decides what actually gets written to the CMDB.

Direct Table API writes (a REST POST directly to cmdb_ci_server.do?sysparm_action=insert) bypass IRE entirely. This is the single most important exam trap in this domain: direct writes skip IRE, which means no deduplication, no source precedence rules, no reconciliation. Service Graph Connectors exist precisely to fix this — they route all incoming data through IRE before anything touches the CMDB.

⚠
Critical Exam Trap — Direct Table API Bypasses IRE A REST POST directly to cmdb_ci_server (Table API) bypasses IRE completely. No deduplication, no reconciliation, no source precedence. This is always wrong for multi-source CMDB environments. SGC data, by contrast, always flows through IRE. This distinction appears in scenario questions: "A developer writes a script that inserts CIs via Table API. What quality risk does this introduce?"
Section 2

What Is a Service Graph Connector?

A Service Graph Connector (SGC) is a pre-built integration package available on the ServiceNow Store that connects a specific third-party data source to your ServiceNow CMDB. Each SGC knows:

  • How to authenticate to the source system (API key, OAuth, certificate)
  • What data to pull and how often (scheduled polling vs. push/webhook)
  • How to map the source's data model to ServiceNow CI classes
  • How to route that data through IRE rather than writing directly to tables

Instead of a developer spending weeks building a custom integration for AWS, you install the "Service Graph Connector for AWS" from the Store, configure credentials, and it starts pulling EC2 instances, RDS databases, S3 buckets, and VPCs as properly classified CIs — all deduplicated through IRE.

💡
Key Concept — SGC vs. Discovery Both SGC and Discovery populate the CMDB, but they work differently. Discovery actively scans your network using probes (we cover this in Part 3). SGC passively polls an external API or receives pushed data. For cloud resources (AWS, Azure, GCP), SGC is the primary method because cloud providers expose rich APIs. For on-premise servers and network devices, Discovery is typically used. Many organizations use both.

Available Service Graph Connectors (Examples)

SGC for AWS
Pulls EC2, RDS, EKS, Lambda, S3, VPC, and IAM resources. Requires MID Server for private VPCs or can connect directly for public endpoints.
SGC for Microsoft Azure
Pulls VMs, App Services, SQL Databases, AKS clusters, Storage Accounts. Uses Azure service principal authentication.
SGC for VMware vCenter
Pulls virtual machines, datastores, ESXi hosts, clusters. Requires MID Server — vCenter is always on-premise.
SGC for ServiceNow Discovery
Correlates Discovery results with data from other SGCs to enrich CI records with network-scanned attributes.
SGC for GitHub
Pulls repositories, organizations, users as CI records. Used for software asset tracking in the CMDB.
SGC for Qualys
Pulls vulnerability scan results and maps them to existing CIs, enriching security-related attributes.
Section 3

The MID Server — ServiceNow's On-Premise Proxy

Many of your data sources sit inside a private network — on-premise servers, private cloud VPCs, internal databases. ServiceNow runs in the cloud (on ServiceNow's own data centers). These two worlds cannot talk directly because your firewall blocks inbound connections from the internet.

The Management, Instrumentation, and Discovery (MID) Server solves this problem. It is a Java application that you install on a server inside your private network. The MID Server makes an outbound connection to your ServiceNow instance — outbound connections are allowed by most firewalls — and maintains a persistent, bidirectional channel. ServiceNow can then ask the MID Server to reach internal resources on its behalf.

📮
Analogy — A Trusted Mailroom Inside the Building Think of your corporate network as a locked office building. ServiceNow (in the cloud) cannot walk through the front door — the firewall won't let it in. But you hire a mailroom employee (the MID Server) who lives inside the building and has a P.O. Box on the street. ServiceNow sends letters to the P.O. Box. The mailroom employee picks them up, executes the instructions inside the building, and sends the results back. The firewall never needed to open an inbound port.

How the MID Server Communication Works

1
Dispatch
ServiceNow Posts Instructions to ECC Queue
ServiceNow writes outbound instructions (e.g., "collect data from vCenter") to the ecc_queue table inside the instance. The MID Server is not contacted directly — ServiceNow simply writes a record and waits.
2
Poll
MID Server Polls ECC Queue
The MID Server makes outbound HTTPS requests to poll the ECC Queue for pending work. This outbound-only model requires no inbound firewall holes — the MID Server initiates all connections.
3
Execute
MID Server Reaches Internal Resource
From within the private network, the MID Server connects to the target resource (vCenter, database, server) using local network access. No VPN or special routing required — the MID Server is already inside the network.
4
Return
Results Posted Back to ECC Queue
MID Server writes collected data back to the ECC Queue as inbound results. ServiceNow picks up these results from the queue for processing.
5
Process
IRE Processes Results → CMDB
ServiceNow passes the structured CI data through IRE — identification, reconciliation, and deduplication — before writing the final result to the CMDB.

Key MID Server Facts for the Exam

  • Operating System: Windows or Linux. Java 11+ required.
  • Network requirement: Outbound HTTPS (port 443) to your ServiceNow instance. No inbound ports needed.
  • Authentication: MID Server authenticates to ServiceNow using a dedicated service account with the mid_server role.
  • ECC Queue: The External Communication Channel queue is the message bus between ServiceNow and MID Server. Input = commands to MID. Output = results from MID.
  • High availability: Multiple MID Servers can exist. They are assigned to IP ranges or applications. Cluster mode provides redundancy.
  • Not always required: For cloud APIs accessible from ServiceNow's network (public AWS endpoints), SGC can call the API directly without a MID Server. MID Server is required when the target is on a private network.
⚠
Exam Trap — MID Server Optional for Cloud, Required for On-Premise SGC for AWS can run without a MID Server if your ServiceNow instance has network access to AWS APIs (typically true for cloud-to-cloud). SGC for VMware vCenter always needs a MID Server because vCenter sits inside your corporate network. Exam questions often ask: "In which scenario is a MID Server required for an SGC?"
Section 4

SGC Data Flow — End to End

Understanding the exact path data takes from a third-party source to a CI record in your CMDB is critical for the exam. Let's trace it step by step.

Step-by-Step: SGC Pulls AWS EC2 Instances

  1. Scheduled trigger fires. The SGC has a scheduled job configured to poll every 4 hours. At 9:00 AM the job fires.
  2. SGC calls AWS EC2 API. Using stored credentials (an IAM role or access key), the SGC calls DescribeInstances. This returns raw JSON with instance IDs, AMIs, tags, IPs, etc. If a MID Server is configured, this API call is proxied through the MID Server.
  3. Payload transformation. The SGC transforms the raw AWS JSON into ServiceNow's internal Identification and Reconciliation API (IRE API) format. At this stage, data is NOT written to any CMDB table. It is packaged as a structured payload.
  4. IRE receives the payload. The payload is handed to IRE. IRE looks at each CI in the payload and asks: "Does this CI already exist in the CMDB?" using Identification Rules (covered deeply in Part 4). If a match is found, this is an update. If not, this is a new CI.
  5. Reconciliation decides field values. For update scenarios, IRE checks Reconciliation Rules: which data source has authority for each field? If AWS says cpu_count=4 but a prior Discovery scan said cpu_count=8, Reconciliation Rules determine which wins.
  6. CMDB record created or updated. IRE writes the final, reconciled values to the appropriate CMDB table (e.g., cmdb_ci_vm_instance for an EC2 instance). A last_discovered timestamp is updated. The discovery_source field is set to the SGC name.
  7. IRE log updated. The result of each CI's processing is written to the IRE log, not the Import Set log. This is a key distinction — SGC processing is visible in IRE logs, not Transform Map logs.
💡
Key Concept — SGC Does Not Use Import Sets Import Sets (covered in Topics 1–4) use a staging table. SGC does NOT use Import Sets. SGC bypasses the staging table entirely and sends data directly to the IRE API. This means you will NOT see SGC data in the sys_import_set_row table or in Transform Map logs. You look for SGC activity in: CMDB IRE Log, Data Source logs, and the SGC connector's own scheduled job log.
⚠
Warning — SGC Errors Hide in IRE Logs, Not Transform Logs If an SGC stops creating CIs correctly, most admins check Transform Map logs first — those are empty because SGC doesn't use Import Sets. The real error will be in the CMDB Identification & Reconciliation log under Configuration → CMDB → Identification/Reconciliation. Also check the connector's own Scheduled Import log under Data Sources → Scheduled Imports.
Section 5

SGC vs. Direct Table API vs. Import Sets — Full Comparison

Knowing when to use each ingestion method — and what each method guarantees — is a recurring exam theme. Study this table carefully.

Dimension Service Graph Connector Import Set + Transform Map Direct Table API (REST)
Goes through IRE? ✅ Yes — always ⚠️ Only if Transform Map calls IRE API (requires explicit configuration) ❌ No — bypasses IRE entirely
Deduplication ✅ Automatic via IRE ⚠️ Only via Coalesce field in Transform Map ❌ None — can create duplicates
Multi-source reconciliation ✅ Full source precedence via Reconciliation Rules ❌ Last-write-wins (no source weighting) ❌ None
Staging table used ❌ No staging table ✅ Yes — sys_import_set ❌ No
Best for Continuous sync from cloud/ITSM/monitoring tools One-time migrations, periodic batch loads, CSV/Excel files Quick scripted updates by developers who accept the risks
Error visibility IRE logs + connector job logs Import Set row status + Transform log HTTP response codes only
Requires MID Server? Only for on-premise targets Only if data source is on-premise No
Custom CI class mapping Preconfigured by ServiceNow per connector Fully customizable in Transform Map You specify the table in the URL
Section 6

Understanding SGC Categories

SGCs are organized into categories based on what type of data source they connect to. Knowing the categories helps you answer "which connector should be used for X" questions.

Cloud Infrastructure Connectors

These connectors pull compute, storage, networking, and managed service resources from cloud providers. They are the most common SGC category.

  • AWS: EC2, RDS, EKS, Lambda, S3, VPC, CloudFormation stacks, IAM roles
  • Azure: Virtual Machines, App Services, AKS, SQL Managed Instance, Blob Storage
  • GCP: Compute Engine VMs, GKE clusters, Cloud SQL, Cloud Storage

Cloud connectors typically use the cloud provider's read-only IAM permissions. They do NOT modify any resources in the cloud — they only read.

Virtualization & On-Premise Connectors

These always require a MID Server because the data source is on-premise.

  • VMware vCenter: VMs, hosts, datastores, clusters, resource pools
  • Microsoft Hyper-V: VMs, virtual switches
  • Nutanix: VMs, clusters, storage

Software Asset & DevOps Connectors

Track software, repositories, and pipelines as CIs in the CMDB.

  • GitHub / GitLab: Repositories, organizations, branches, pipelines
  • Jira: Projects mapped to application CIs
  • Dynatrace / Datadog: Monitored services and hosts as CIs

Security & Vulnerability Connectors

  • Qualys: Maps scan results to existing CIs, enriching vulnerability data
  • Tenable.io: Asset inventory with CVE associations
  • CrowdStrike: Endpoint agents mapped to CIs
💡
Tip — SGC Enriches, Not Just Creates SGCs do not always create new CI records. When a CI already exists (created by Discovery or manually), an SGC can enrich it with additional attributes. For example, Discovery finds a server and creates the CI. The Qualys SGC then adds vulnerability scan data to that same CI record. IRE's Reconciliation Rules govern which attributes each source is allowed to write.
Section 7

Configuring a Service Graph Connector

All SGC configurations follow the same general workflow. Understanding this helps you answer procedural questions on the exam.

Installation

  1. Search the ServiceNow Store for the connector (e.g., "Service Graph Connector for AWS").
  2. Install the application to your instance. This creates the connector's scheduled jobs, data source records, and IRE configuration.
  3. The connector appears under Configuration → Connections & Credentials or under its own application menu.

Authentication Setup

Each connector has a Connection & Credential record. You configure:

  • Connection alias — A named connection (e.g., "AWS Production Account"). Allows multiple accounts per connector.
  • Credential record — API key, OAuth client ID/secret, certificate. Stored encrypted using ServiceNow's credential vault.
  • MID Server selection — If required, which MID Server to route through.

Data Scope Configuration

Most connectors let you scope what gets imported:

  • Filters/tags: Only pull AWS resources tagged with Environment=Production
  • Regions/accounts: Pull from us-east-1 and eu-west-1 only
  • CI classes: Only pull EC2 instances, skip Lambda functions

Scheduling

Each SGC creates one or more Scheduled Data Imports. You can configure:

  • Frequency (every 4 hours, daily, weekly)
  • Full sync vs. incremental sync (delta-based)
  • Run immediately for an initial baseline population
💡
Tip — Run Full Sync First, Then Incremental When setting up a new SGC, always run a Full Sync first. This establishes the baseline — all CIs from the source are pulled and IRE processes them. Subsequent runs use Incremental Sync which only pulls changes (new, modified, deleted CIs). Incremental sync is much faster but requires a complete baseline to be accurate.
Section 8

How SGC Works with IRE (Preview)

You will study IRE in depth in Part 4. For now, you need to know enough to understand what happens when SGC data arrives at IRE. This section introduces the concepts; Part 4 covers the full detail.

Three Questions IRE Answers for Every CI

  1. "Does this CI already exist?" (Identification)
    IRE uses Identification Rules to match incoming CI data against existing CMDB records. For a server, this might check: serial number, MAC address, or hostname. If a match is found, this is an update. If not, this is a new CI.
  2. "If it exists and I have multiple sources — what is the true value?" (Reconciliation)
    IRE uses Reconciliation Rules to determine source precedence per field. "AWS is authoritative for instance_type. Discovery is authoritative for cpu_count. Manual entry is authoritative for owned_by."
  3. "Are there duplicate CIs for this same physical/logical entity?" (Deduplication)
    IRE detects duplicate CI records and can either merge them automatically or flag them for manual review via Remediation Playbooks.

The discovery_source Field

When IRE processes SGC data, it sets the discovery_source field on the CI record to the name of the SGC. This is how you can later query "which CIs came from AWS SGC?" You can filter cmdb_ci where discovery_source = ServiceNow AWS.

What to Check When SGC Is Not Creating CIs

  1. Check the Scheduled Import job log — did the job run? Did it pull data?
  2. Check the CMDB IRE Log (cmdb_ire_event) — did IRE receive the data? Were there identification errors?
  3. Check Identification Rules — is there a rule for the CI class being imported? (Part 4)
  4. Check MID Server status — if on-premise, is the MID Server up and connected?
  5. Check credentials — have API keys expired?
⚠
Exam Scenario — "SGC ran but no CIs were created" Common exam scenario: "The AWS SGC ran successfully (job log shows 500 records fetched), but no new CIs appeared in the CMDB. What is the most likely cause?" Answer: Missing or misconfigured IRE Identification Rules for the cmdb_ci_vm_instance class. If IRE cannot identify whether incoming records are new or existing (because no rule exists), it may drop or fail them rather than creating new records.
Section 9

MID Server Roles, Clusters, and Management

Because MID Server is introduced here and will appear repeatedly in Discovery (Part 3), let's cover the management concepts the exam tests.

MID Server Applications

A single MID Server can handle multiple types of work. Each type is called an Application:

  • Discovery — Runs probes and sensors to scan IP ranges (Part 3)
  • Service Graph Connectors — Proxies API calls to on-premise sources
  • Orchestration — Runs workflow activities on remote systems
  • Event Management — Receives alerts from monitoring tools
  • IntegrationHub — Executes spoke actions against on-premise systems

MID Server Clusters

For high availability and load distribution, you can group MID Servers into a cluster. Work items are distributed across cluster members. If one MID Server fails, others pick up its work. Key exam points:

  • Cluster members must be in the same network segment to be useful for Discovery
  • Primary and secondary MID Server designation within a cluster
  • Cluster affinity — certain work items can be pinned to specific MID Servers

MID Server Validation

Before a MID Server can be used, it must be validated. Validation confirms the MID Server meets security and version requirements set by your ServiceNow instance. Key facts:

  • MID Server auto-upgrade is configurable — ServiceNow can push updates automatically
  • If a MID Server is not validated, jobs assigned to it will not run
  • Validation status is visible at MID Server → Servers

MID Server IP Ranges

For Discovery, each MID Server is assigned one or more IP ranges. When a Discovery schedule fires for a range, ServiceNow routes the work to the MID Server that owns that range. This ensures that a MID Server in the US east data center handles US east server scans, not a MID Server in Europe.

MID Server Property Where to Configure Why It Matters
Service account credentials config.xml on the MID Server host Authenticates MID Server to ServiceNow instance
IP Range assignment MID Server record → IP Ranges related list Routes Discovery work to correct MID Server
Application assignment MID Server record → Applications related list Controls what types of work this MID Server handles
Cluster membership MID Server record → Cluster field High availability and load distribution
Validation status MID Server record → Validated field Must be Validated before use; auto-checked on startup
Exam Quick Reference

SGC & MID Server — Key Facts

  • SGC always routes through IRE. Direct Table API writes bypass IRE — this is always wrong for multi-source environments.
  • SGC does NOT use Import Sets. Look for SGC activity in IRE logs and connector job logs, not Transform Map logs.
  • MID Server = outbound proxy inside your private network. Makes outbound connections to ServiceNow — no inbound firewall holes needed.
  • MID Server required for on-premise targets (vCenter, Hyper-V, internal DBs). Optional for cloud APIs accessible from ServiceNow's network.
  • ECC Queue = message bus between ServiceNow and MID Server. Input queue = instructions to MID. Output queue = results from MID.
  • MID Server must be Validated before it can run jobs. Validation auto-runs on startup.
  • discovery_source field = which SGC or Discovery schedule created/last updated the CI.
  • Full sync first, then incremental. Full sync establishes baseline; incremental only pulls deltas.
  • SGC troubleshooting order: Job log → IRE log → Identification Rules → MID Server status → Credentials.
  • Multiple MID Servers can form a cluster for high availability and IP range-based routing.

Term Grid — SGC Key Vocabulary

Service Graph Connector (SGC)
Pre-built integration that pulls data from a third-party source into CMDB via IRE. Installed from ServiceNow Store.
MID Server
Java app installed on-premise. Bridges private network to ServiceNow via outbound HTTPS. Proxies Discovery and SGC jobs.
ECC Queue
External Communication Channel. Message queue between ServiceNow and MID Server. Input = to MID, Output = from MID.
IRE (Identity & Reconciliation Engine)
ServiceNow's engine that identifies existing CIs, reconciles multi-source field conflicts, and detects duplicates. All SGC data passes through it.
discovery_source
Field on CI records recording which tool last populated it. Set by IRE when processing SGC or Discovery data.
Connection & Credential Alias
Named authentication record for an SGC. Allows multiple accounts (e.g., multiple AWS accounts) per connector type.
Full Sync
SGC run that fetches ALL records from the source. Used for initial baseline population.
Incremental Sync
SGC run that fetches only changed/new/deleted records since last run. Faster but requires a valid baseline.
Exam Checkpoint

Practice Questions

Click any question to reveal the answer and explanation.

1. A developer writes a Python script that uses the ServiceNow Table API to insert 500 new server CI records directly into cmdb_ci_server. What is the primary CMDB quality risk of this approach?
A) The records will fail validation and not be saved
B) The records bypass IRE, so deduplication and reconciliation rules do not apply
C) The records are saved to a staging table and require manual approval
D) The records will be deleted after 24 hours
💡 Think about what IRE provides that a direct API call does not.
Answer: B — Direct Table API writes bypass IRE entirely. This means no deduplication (duplicates can be created), no reconciliation (last-write-wins instead of source precedence), and no identification matching against existing records. The records are saved but without any quality controls.
2. Your organization runs VMware vCenter on-premise. You want to use the Service Graph Connector for VMware to populate CI records. Which statement is true?
A) No MID Server is needed because SGC always connects directly to data sources
B) A MID Server is required because vCenter is on a private network inaccessible from ServiceNow's cloud
C) A MID Server is optional — the connector will try direct connection first and fall back to MID Server
D) MID Server is only needed for Discovery, not SGC
💡 Can ServiceNow's cloud servers reach your internal vCenter API?
Answer: B — vCenter runs on your private corporate network. ServiceNow (in the cloud) cannot reach it directly through your firewall. A MID Server installed inside your network makes outbound connections to ServiceNow and proxies the vCenter API calls. This is required, not optional.
3. An SGC for AWS ran successfully — the job log shows 300 EC2 instances were fetched — but no CI records appeared in the CMDB. What is the MOST likely cause?
A) The Transform Map is misconfigured
B) The Import Set staging table is full
C) IRE Identification Rules for cmdb_ci_vm_instance are missing or misconfigured
D) The MID Server is offline
💡 Data was fetched, so connectivity works. The failure is in processing. SGC does not use Transform Maps or Import Sets.
Answer: C — Since the job fetched data successfully, the MID Server and credentials work. SGC does not use Import Sets or Transform Maps. The data was handed to IRE, but without Identification Rules for the CI class, IRE cannot process it. Missing or inactive Identification Rules are the most common cause of "data fetched but no CIs created."
4. Where do you check for errors when an SGC job appears to run but produces incorrect or missing CI data?
A) Transform Map log and Import Set row status
B) CMDB IRE Log and the connector's Scheduled Import job log
C) Discovery schedule log and MID Server probe results
D) Business Rule execution log
💡 SGC data flows through IRE, not Import Sets.
Answer: B — SGC does not use Import Sets or Transform Maps, so options A and C are wrong. SGC errors appear in: (1) the CMDB Identification & Reconciliation log (cmdb_ire_event) which shows whether IRE accepted or rejected each CI, and (2) the connector's Scheduled Import job log which shows whether data was successfully fetched from the source.
5. You are deploying a new MID Server. After installation and configuration, the assigned Discovery schedule runs but no work is executed. What is the most likely reason?
A) The MID Server has not been validated yet
B) The MID Server service account has too many roles
C) The ECC Queue is disabled
D) The MID Server is running on Windows instead of Linux
💡 What status must a MID Server have before ServiceNow will assign work to it?
Answer: A — A MID Server must be Validated before ServiceNow will route work to it. Validation confirms the MID Server meets security and version requirements. After installation, the admin must validate it in the ServiceNow console (MID Server → Servers → Validate). Until validated, all assigned jobs will queue but not execute.
6. Which MID Server concept allows work items to be distributed across multiple servers for high availability?
A) IP Range assignment
B) MID Server Cluster
C) ECC Queue partitioning
D) Application-based routing
💡 Which feature groups multiple MID Servers together?
Answer: B — MID Server Clusters group multiple MID Servers. Work is distributed across cluster members, and if one fails, others pick up the work. IP Range assignment routes work to the correct network segment. Application-based routing controls what type of work each MID Server handles, not redundancy.
7. A company wants to track their AWS infrastructure in ServiceNow. They have both public-facing EC2 instances and EC2 instances in private VPCs. Which statement about MID Server requirements is accurate?
A) No MID Server is needed — AWS is always cloud-accessible
B) A MID Server is always required for all AWS SGC connections
C) A MID Server is needed for private VPC resources but may not be needed for public endpoints
D) Two MID Servers are required — one for public and one for private
💡 The AWS API is cloud-accessible. Private VPCs are not.
Answer: C — The AWS EC2 API itself (used by the SGC to list instances) is publicly accessible, so ServiceNow can call it directly without a MID Server. However, if the SGC needs to reach resources inside a private VPC (e.g., performing additional checks via private IP), a MID Server deployed inside that VPC is needed. The exam often draws this distinction.
Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Service Graph Connectors Quiz 1 / 4

A Service Graph Connector (SGC) is configured to ingest data from a cloud provider. How does SGC process the ingested CI data before writing it to CMDB?

💡 Explanation

B is correct. SGC always routes through the IRE. This is the key distinction that makes SGC the preferred CMDB ingestion method — it ensures identification rules run, deduplication occurs, and reconciliation rules determine field authority. A is wrong (that's the dangerous direct-write pattern). C is wrong (SGC does NOT use Import Sets). D is for agentless Discovery probes.

An SGC job is failing to create CI records. A colleague suggests checking Transform Map logs. Is this the right approach?

💡 Explanation

B is correct. SGC does NOT use Import Sets or Transform Maps. SGC activity is tracked in the connector job logs and IRE logs (cmdb_ire_event). Looking at Transform Map logs would yield no relevant results. A and C are incorrect because they incorrectly assume SGC uses the Import Set pipeline. D is incorrect — SGC has its own dedicated logs.

An SGC is configured to pull from an on-premise VMware vCenter server. Which component is required for the SGC to reach vCenter?

💡 Explanation

B is correct. On-premise targets like vCenter are inside the corporate network and unreachable from ServiceNow's cloud. A MID Server deployed inside the network makes outbound connections to ServiceNow — no inbound firewall holes are needed. A is not how ServiceNow connectivity works. C requires inbound connections which is the opposite of MID Server architecture. D is for agentless Discovery, not SGC.

What does the discovery_source field on a CI record represent?

💡 Explanation

B is correct. The discovery_source field records which SGC connector or Discovery schedule last successfully updated the CI. It is a string field and is overwritten each time a source successfully processes the CI. A is incorrect — it reflects the last source, not the first. C and D are not what this field stores.

Score: 0 / 4
← Coalesce & Transform Scripts Non-Discoverable CIs →