Cloud Tag Collection with CIE

The IP Tag Cloud Connection feature in the Cloud Identity Engine connects to cloud provider APIs, reads resource tags attached to compute instances, and registers IP-to-tag mappings on connected firewalls. One credential configuration and one monitor configuration per cloud account are all that is needed.

The collection process has two parts:

1. Credential Configuration -- provide CIE with authentication credentials for the cloud account (AWS access keys or Role ARN, Azure service principal, or GCP service account JSON key).
2. Monitor Configuration -- select which regions, VPCs, or projects to monitor, set the polling interval (range: 60-1800 seconds, default 60), and assign a segment that determines which firewalls receive the IP-tag mappings.

Once configured, CIE polls the cloud provider API at the specified interval. It performs incremental syncs -- only new or modified mappings are transferred each cycle. A manual Full Sync option forces a complete re-read of all mappings.

The value of CIE tag collection is the automation chain it enables. When a cloud resource is tagged, that tag propagates automatically through CIE to become an enforceable policy object on the firewall -- no manual IP address management required.

The end-to-end flow works as follows:

1. Cloud resource tag -- an EC2 instance, Azure VM, or GCP Compute Engine instance has a resource tag (e.g., env=prod).
2. CIE polls cloud API -- CIE reads the tag and the instance's private IP address, creating an IP-to-tag mapping (e.g., 10.0.1.5 mapped to env.prod).
3. CIE distributes to firewalls -- CIE pushes the IP-tag mapping to all firewalls in the assigned segment.
4. Firewall registers IP-tag pair -- the firewall stores the mapping in its registered-IP table (viewable via show object registered-ip all).
5. DAG match criteria evaluates -- a Dynamic Address Group configured with match criteria 'env.prod' evaluates the registered tags and adds 10.0.1.5 as a member.
6. Security rule enforces -- a security policy rule referencing the DAG as source or destination address automatically applies to traffic from/to 10.0.1.5.

When the instance is terminated or its tag is removed, CIE detects the change on the next poll, deregisters the IP-tag mapping, the DAG membership updates, and the policy stops matching -- all without manual intervention.

End-to-end tag collection and policy flow:

Each cloud provider exposes resource metadata differently. CIE normalizes these into IP-tag mappings, but the tag names and available attributes vary. The table below summarizes what CIE collects from each cloud.

Before CIE IP Tag Cloud Connection existed, the only way to collect cloud resource tags was VM Monitoring -- a per-firewall or per-Panorama-plugin approach where each device polled cloud APIs independently. CIE replaces this with a centralized, cloud-hosted model. The table below compares the two approaches.

This guide applies when all of the following conditions are true:

• Cloud workloads exist in AWS, Azure, or GCP with meaningful resource tags or labels already applied (e.g., env, app-tier, team).
• Tag-driven security policy is the goal -- security rules should automatically adapt as workloads scale, move, or change tags, without manual IP address updates.
• CIE is activated -- the Cloud Identity Engine service has been enabled and initial setup (activation, tenant onboarding) is complete. If not, complete Phase 1 and Phase 2 of the CIE Implementation Guide first.
• PAN-OS 10.1 or later runs on all firewalls that will receive IP-tag registrations from CIE.

IP Tag Cloud Connection configuration requires an active CIE tenant. Confirm activation before proceeding.

1. Open https://hub.paloaltonetworks.com and log in with Palo Alto Networks credentials.
2. Navigate to Cloud Identity Engine in the hub.
3. Confirm the CIE dashboard loads and the tenant status shows as active.
4. Navigate to User Context > IP-Tag Collection. Confirm the page loads with Credential Configuration and Monitor & Status tabs visible.

CIE IP-tag redistribution requires PAN-OS 10.1 or later on every firewall that will receive IP-tag mappings from CIE. Firewalls on older versions cannot subscribe to CIE segments.

Check the PAN-OS version on each firewall:

show system info | match sw-version

Check the Panorama version (if applicable):

show system info | match sw-version

CIE is a cloud-hosted service that connects outbound to cloud provider APIs and redistributes IP-tag mappings to firewalls. Two connectivity paths must be open.

Path 1: CIE to cloud provider APIs

CIE polls cloud provider APIs over HTTPS to read resource tags. The following endpoints must be reachable from the CIE service (these are outbound from Palo Alto Networks infrastructure, not from the customer network):

Path 2: Firewalls to CIE

Firewalls initiate outbound HTTPS connections to CIE to receive IP-tag redistribution. The management interface (or a dedicated service route) must have outbound access to CIE service endpoints on port 443.

Check the CIE service status page to confirm the service is operational:

1. Open status.paloaltonetworks.com.
2. Confirm the Cloud Identity Engine service shows a green status.

Each cloud provider requires specific credentials for CIE to authenticate and read resource tags. This step is a planning checklist; the actual credential creation is covered in Phase 2.

Identify which cloud accounts will be onboarded and gather the following information for each:

Record the information below for each cloud account to onboard. These values are needed in Phase 2.

CIE collects all resource tags from monitored cloud accounts, but only tags referenced in Dynamic Address Group (DAG) match criteria drive security policy. Identify the tag keys and values that will form the basis of tag-based policy before configuring collection.

Common tag patterns for security policy

Tag naming recommendations

• Standardize tag keys across clouds. Use the same key name (e.g., env) in AWS, Azure, and GCP. The cloud prefix (aws.tag., azure.tag., gcp.label.) differentiates them in DAG match criteria, but consistent key names simplify policy design.
• Use lowercase tag keys and values. Tag names in DAG match criteria are case-sensitive. Mixing cases (e.g., Env vs env) creates match failures.
• Keep tag values short and predictable. Tags longer than 127 characters are not retrieved by CIE. Avoid special characters ({, ", non-ASCII).
• Avoid spaces in tag keys. Spaces in tag keys create unexpected tokens in the CIE tag format, which complicates match criteria.

CIE uses an IP Tag Cloud Connection to read resource tags from each cloud provider via API polling. Each cloud account, subscription, or project gets its own connection. The connection consists of two objects:

• Credential Configuration — authenticates CIE to the cloud provider (IAM role, service principal, or service account key).
• Monitor Configuration — defines what to collect (regions, VPCs, projects) and where to send it (segment). The monitor configuration also sets the polling interval.

CIE syncs only new or modified mappings on each poll cycle. Per region, a single monitor configuration supports up to 60,000 IP-tag mappings.

Reference: Configure an IP Tag Cloud Connection

The polling interval set during monitor configuration creation determines how frequently CIE checks for new or modified tags. Adjust it based on the rate of change in the environment.

To change the polling interval on an existing monitor configuration:

1. Navigate to User Context > IP-Tag Collection > Monitor & Status tab.
2. Click Edit on the target monitor configuration.
3. Update the Polling Interval value.
4. Click Submit.

Confirm that all configured cloud connections are syncing and that tag data is visible in the centralized CIE dashboard.

1. Navigate to User Context > Mappings and Tags.
2. Select IP Tags.
3. Search by Tag to confirm tags from each configured cloud provider appear (e.g., search for env to find environment tags across providers).
4. Search by IP address for a known cloud workload IP and confirm the associated tags are listed.
5. (Optional) Filter by Segment to confirm mappings are landing in the intended segment for redistribution to firewalls.

Reference: View Data Collected by Cloud Identity Engine

DAG match criteria determine which registered IP-tag mappings populate the group. Before creating DAGs, understand the tag format and the operators available.

Tag format from CIE

Tags registered by CIE IP Tag Cloud Connections use cloud-provider-prefixed dot notation. The format is <provider>.tag.<key>.<value> (or <provider>.label.<key>.<value> for GCP labels):

Boolean operators

Match criteria support two operators:

• and — the IP must have all specified tags. Example: 'aws.tag.env.prod' and 'aws.tag.tier.web' matches IPs tagged with both env=prod AND tier=web.
• or — the IP must have at least one of the specified tags. Example: 'aws.tag.env.prod' or 'aws.tag.env.staging' matches IPs tagged with either environment.

Operator precedence

The and operator binds more tightly than or. In the expression 'aws.tag.env.prod' and 'aws.tag.tier.web' or 'aws.tag.tier.app', the effective evaluation is ('aws.tag.env.prod' AND 'aws.tag.tier.web') OR 'aws.tag.tier.app'. Use explicit grouping when the intent differs from this default precedence.

Additional rules

• Tag names in match criteria are case-sensitive.
• Each tag string must be enclosed in single quotes in the match criteria expression.
• A single IP address can carry up to 32 tags.
• Tags longer than 127 characters are not registered by CIE.

Reference a Dynamic Address Group in a security rule so that the rule automatically applies to every IP address currently tagged with matching cloud attributes. This is the foundational mechanism; all subsequent patterns build on it.

Cloud environments often share the same VPC, VNet, or project. When production and development workloads coexist in overlapping IP ranges, tags are the only reliable differentiator. Blocking cross-environment traffic limits blast radius during a compromise and satisfies compliance requirements (PCI DSS, SOC 2) that mandate environment separation.

Create two deny rules using the dag-prod and dag-dev DAGs from Phase 3.

A standard 3-tier architecture separates web frontends, application servers, and databases. Even when all tiers share the same network zone or subnet, tag-based segmentation enforces directional traffic flow: web → app → db. Direct web → db access is blocked, preventing SQL injection and data exfiltration attacks from bypassing the application layer.

Create three rules using the dag-web-tier, dag-app-tier, and dag-db-tier DAGs from Phase 3.

DAG-based security rules enforce access control (allow/deny). Security profiles add threat inspection (antivirus, anti-spyware, vulnerability protection, URL filtering, file blocking, and WildFire analysis) to allowed traffic. Without profiles attached, allowed traffic passes without deep packet inspection.

Security rules require a commit to take effect. Unlike DAG membership (which updates dynamically via CIE), rule creation and modification must be committed to the running configuration.

show running security-policy

show object dynamic-address-group all

show running security-policy

show object dynamic-address-group all

show running security-policy

show object dynamic-address-group all

Confirm that all IP Tag Cloud Connections are actively syncing and that CIE has current tag data from each cloud account.

1. Log in to the CIE dashboard.
2. Navigate to User Context > IP-Tag Collection.
3. Select the Monitor & Status tab.
4. For each monitor configuration, verify:

   Field	Expected Value
   Status	Connected
   Last Sync	A timestamp within the configured polling interval (e.g., within the last 5 minutes for a 300-second interval)
   IPs (tag count)	Non-zero — at least one IP-tag mapping exists

5. Click the monitor configuration name to open the detail view.
6. Select the Tag To IP tab. Search for a known tag (e.g., env:prod for AWS, env:prod for Azure, or a known GCP label). Confirm matching IPs appear.
7. Select the IP To Tag tab. Search for a known cloud instance IP address and confirm its tags are listed.

CIE distributes IP-tag mappings to firewalls in the assigned segment. This step confirms that the firewall has received and stored those mappings in its registered-IP table.

1. SSH to a firewall that is assigned to the CIE segment.
2. Run the following command to view all registered IP-tag pairs:

show object registered-ip all

Expected output format:

registered IP                         Tags
---------------------------------------- --------
10.0.1.5  *                           "aws.tag.env.prod (never expire)"
                                      "aws.tag.tier.web (never expire)"
10.0.2.10 *                           "aws.tag.env.staging (never expire)"
10.0.3.22 *                           "azure.tag.app.payments (never expire)"

Total: 3 registered addresses

The * next to each IP indicates a dynamically registered entry (from CIE or another dynamic source). The (never expire) suffix means CIE manages the lifetime of these entries; they persist until CIE deregisters them.

3. To filter by a specific tag, run:

show object registered-ip tag aws.tag.env.prod

4. Cross-reference the IPs returned with the cloud console. Confirm that the listed IPs match the private IP addresses of instances tagged with env=prod (or whichever tag was queried).

DAGs evaluate their match criteria against the registered-IP table in real time. This step confirms that each DAG has resolved to the correct set of member IPs.

1. List all DAGs and their member counts:

show object dynamic-address-group all

The output shows each DAG name, its match criteria, and the number of resolved members. Every DAG created in Phase 3 should appear with a non-zero member count.

2. View members of a specific DAG:

show object dynamic-address-group name DAG-PROD-WEB

Replace DAG-PROD-WEB with the actual DAG name created in Phase 3. The output lists every IP address that matches the DAG's criteria.

3. Cross-reference the DAG members with the cloud console:
   • Open the cloud provider console (AWS EC2, Azure VMs, or GCP Compute Engine).
   • Filter instances by the tag that the DAG matches (e.g., env=prod and tier=web).
   • Confirm that the private IPs of the filtered instances match the DAG member list.

The test security-policy-match CLI command simulates a policy lookup for a given traffic flow without sending actual packets. Use it to confirm that DAG-based security rules match traffic between tagged instances.

1. Identify a source IP and destination IP from the DAG members verified in Step 5.3. For example, a production web server (10.0.1.5) connecting to a production database server (10.0.2.10) on port 443.
2. Run the policy match test:

test security-policy-match source 10.0.1.5 destination 10.0.2.10 protocol 6 destination-port 443

The output shows which security rule matches the simulated flow, including the rule name, action (allow/deny), and the security profile group applied.

3. Confirm the matched rule is the DAG-based rule created in Phase 4, not a catch-all or default rule.
4. (Optional) Add zone parameters for a more precise test. The from and to zone fields narrow the match to rules scoped to specific zones:

test security-policy-match from TRUST to TRUST source 10.0.1.5 destination 10.0.2.10 protocol 6 destination-port 443

5. Test additional traffic patterns:
   • Outbound (tagged source to internet): test security-policy-match source 10.0.1.5 destination 8.8.8.8 protocol 6 destination-port 443
   • Denied traffic: test a flow that should be blocked by the policy. Confirm the matched rule has action deny or drop.

After confirming policy match via CLI simulation, verify that live traffic is hitting the DAG-based rules by checking the traffic logs.

1. Navigate to Monitor > Logs > Traffic on the firewall or Panorama.
2. Add a filter for the DAG-based security rule name. Enter the following in the filter bar:

( rule eq 'ALLOW-PROD-WEB-TO-DB' )

Replace ALLOW-PROD-WEB-TO-DB with the actual rule name created in Phase 4.

3. Click Apply Filter (or press Enter).
4. Review the log entries. For each entry, confirm:

   Log Field	Expected Value
   Rule Name	The DAG-based rule name (e.g., ALLOW-PROD-WEB-TO-DB)
   Source Address	An IP that is a member of the source DAG
   Destination Address	An IP that is a member of the destination DAG
   Action	allow or deny (matching the rule's configured action)
   Application	The expected application (e.g., ssl, web-browsing)

The full value of CIE tag collection is its automation: when a cloud resource tag changes, the policy automatically adapts. This step validates the dynamic update loop end-to-end by modifying a tag in the cloud and observing the result on the firewall.

Add a tag to a new or existing instance

1. In the cloud provider console, select an instance that is not currently a member of any DAG (or launch a new instance).
2. Add a resource tag that matches an existing DAG's criteria. For example, add tag env=prod and tier=web to make the instance match the DAG-PROD-WEB group:
   • AWS: EC2 Console > select instance > Tags tab > Manage tags > Add new tag.
   • Azure: VM blade > Tags > add key-value pair.
   • GCP: Compute Engine > VM instances > edit instance > Labels section.
3. Note the instance's private IP address.

Wait for CIE sync

4. Wait for one polling interval to elapse (the interval configured in the monitor configuration — default 60 seconds, or 300 seconds if the recommendation from Phase 2 was followed).
5. (Optional) Force an immediate sync: in the CIE console, navigate to IP-Tag Collection > Monitor & Status, click the Actions menu for the connection, and select Full Sync.

Verify the update propagated

6. On the firewall CLI, verify the new IP appears in the registered-IP table:

show object registered-ip tag aws.tag.env.prod

Replace aws.tag.env.prod with the tag format matching the cloud provider (e.g., azure.tag.env.prod or gcp.label.env.prod).

7. Verify the new IP is now a member of the target DAG:

show object dynamic-address-group name DAG-PROD-WEB

8. Confirm the new IP appears in the DAG member list.
9. Test that traffic from the newly tagged instance matches the correct security rule:

test security-policy-match source <new-instance-ip> destination 10.0.2.10 protocol 6 destination-port 443

(Optional) Remove the tag and verify cleanup

10. Remove the tag added in step 2 from the cloud instance.
11. Wait for one polling interval (or trigger a Full Sync).
12. Run show object dynamic-address-group name DAG-PROD-WEB again. The instance's IP should no longer appear as a member.

The CIE IP-Tag Collection page shows no tags, the connection status is Not connected or Partially connected, or the tag count is zero despite active cloud resources.

1. Navigate to User Context > IP-Tag Collection > Monitor & Status in the CIE app. Check the Connection Status column. Click Click to see details for any configuration that is not Connected.
2. If the status is Not connected, navigate to the Credential Configuration tab and verify the cloud credentials:
   • AWS — confirm the Access Key ID and Secret Access Key are valid and not rotated. If using a cross-account role, verify the Role ARN is correct.
   • Azure — confirm the Client Secret has not expired. Azure AD app registrations generate secrets with expiration dates; an expired secret silently fails authentication.
   • GCP — confirm the service account JSON key file is still active. Keys deleted or disabled in the GCP IAM console cause connection failures.
3. In the Monitor Configuration, verify the correct regions, VPCs (AWS), subscriptions (Azure), or Project IDs (GCP) are selected. If All Regions is deselected but no specific region is chosen, CIE polls nothing.
4. Check the Polling Interval in the Monitor Configuration. The default is 60 seconds (range: 60–1800). If set to the maximum (1800 seconds / 30 minutes), initial tag population is delayed.
5. Verify the CIE service is operational at status.paloaltonetworks.com.
6. Click Full Sync on the Monitor & Status page to force a complete re-sync of all IP-tag mappings from the cloud provider.

Tags appear in the CIE dashboard (User Context > Mappings & Tags > IP Tags) but the firewall shows no registered IPs when running show object registered-ip all.

1. On the firewall, verify the CIE connection is configured and enabled. Navigate to Device > User Identification > Cloud Identity Engine and confirm a profile exists with status Enabled.
2. Verify the Region and Cloud Identity Engine Instance selected in the firewall profile match the CIE tenant where tags are collected.
3. Check the segment and redistribution configuration in CIE:
   • Navigate to User Context > Segments in the CIE app.
   • Confirm the firewall is assigned to a segment.
   • Confirm IP Tag Mappings is set to Enabled for that segment.
   • If using the Monitor Configuration, confirm the Segment field is set to the correct segment (not None). Setting it to None makes the configuration monitoring-only — no tags are sent to firewalls.
4. On the firewall, verify the User Context Cloud Service is enabled: Device > Setup > Management > PAN-OS Edge Service Settings. The User Context Cloud Service must show Enabled.
5. Verify network connectivity. The firewall must reach Palo Alto Networks cloud service endpoints over HTTPS. If the management interface uses a dedicated management plane, confirm the service route for CIE traffic is correct.
6. Check the Update Interval in the CIE profile on the firewall. The default is 60 minutes (range: 5–1440). If recently configured, wait for at least one full interval to elapse.
7. Run the following CLI command to check the CIE connection status on the firewall:

   show user cloud-identity-engine status

   Copy

A Dynamic Address Group is configured but show object dynamic-address-group name <DAG-name> returns zero members, even though tags should be registered on the firewall.

1. First, confirm tags are actually registered on the firewall:

   show object registered-ip all

   Copy
   If this returns no output, the problem is upstream; see Tags Sync to CIE But Not to Firewall above.
2. Check the tag format. CIE registers tags with a cloud-specific prefix (e.g., aws.tag.<key>.<value>, azure.tag.<key>.<value>, gcp.label.<key>.<value>). Verify the exact format by examining the output of show object registered-ip all and noting the exact tag strings.
3. Check the DAG match criteria syntax. Navigate to Objects > Address Groups, select the DAG, and review the Match field. Common errors:
   • Wrong tag prefix — using 'Environment.Production' instead of the full cloud-prefixed format (e.g., 'aws.tag.Environment.Production').
   • Wrong case — match criteria are case-sensitive. 'aws.tag.environment.production' does not match 'aws.tag.Environment.Production'.
   • Wrong delimiter — using commas or semicolons instead of and / or operators between tag names.
   • Missing quotes — each tag name must be wrapped in single quotes within the match expression.
4. Verify that IP Tag Collection is enabled on the zone. Navigate to Network > Zones, select the zone, and under the User Identification tab confirm Enable IP Tag Collection is checked.
5. After correcting match criteria, commit the change and re-check:

   show object dynamic-address-group name <DAG-name>

   Copy

'aws.tag.Environment.Production' and 'aws.tag.Team.Engineering'

'aws.tag.Environment.Production' or 'aws.tag.Environment.Staging'

A security rule references a DAG but traffic that should match the rule is being handled by a different rule or denied by the default interzone rule.

1. Confirm the DAG has members. An empty DAG causes the security rule to never match any traffic:

   show object dynamic-address-group name <DAG-name>

   Copy
   If the member list is empty, see DAG Shows Zero Members above.
2. Check rule ordering. Security rules are evaluated top-down. An earlier, broader rule may match the traffic before the DAG-based rule is reached. Navigate to Policies > Security and review the position of the DAG rule relative to other rules.
3. Verify zone configuration. Both the source zone and destination zone on the rule must match the actual zones the traffic traverses. A zone mismatch causes the rule to be skipped entirely.
4. Confirm the rule has been committed. Uncommitted rules exist only in the candidate configuration and do not affect traffic. On Panorama-managed firewalls, both a Panorama commit and a push to the device are required.
5. Use the test security-policy-match command to identify which rule matches specific traffic:

   test security-policy-match source <SRC-IP> destination <DST-IP> protocol 6 destination-port 443 from <SRC-ZONE> to <DST-ZONE>

   Copy
   The output shows the rule name that matches. If a different rule matches instead of the DAG-based rule, adjust rule ordering or tighten the broader rule's match criteria.
6. Check the Traffic log (Monitor > Logs > Traffic) for the session. The Rule column shows which rule matched. Filter by source or destination IP to find the relevant entries.

Tag collection from AWS fails or returns incomplete results despite a valid CIE configuration.

STS Assume-Role Failures

1. Verify the trust policy on the CIE-IPTag-AssumeRole role in the target account trusts the correct principal. The Principal must be the source account IAM user (or account root) where the cie-iptag-collector user lives — not a Palo Alto Networks account ID. Navigate to IAM > Roles > CIE-IPTag-AssumeRole > Trust relationships and confirm the Principal shows your source account ID.
   Common mistake: wrong trust principal

   If the trust policy Principal contains a Palo Alto Networks account ID or any account ID other than your source account (where the cie-iptag-collector user was created), the assume role call will fail with AccessDenied. Update the trust policy to reference your source account: arn:aws:iam::<SOURCE-ACCOUNT-ID>:user/cie-iptag-collector.

2. Verify the Role ARN value entered in the CIE Credential Configuration matches the ARN of the role in the target account exactly. Copy the ARN from IAM > Roles > CIE-IPTag-AssumeRole > Summary. ARNs are case-sensitive.
3. Verify the cie-iptag-collector IAM user in the source account has the CIE-IPTag-AssumeRole-Policy attached and that the policy Resource includes the target account's role ARN. Navigate to IAM > Users > cie-iptag-collector > Permissions and confirm the policy is present.
4. Confirm the access keys entered in CIE belong to the cie-iptag-collector user in the source account and have not been rotated or deactivated. Navigate to IAM > Users > cie-iptag-collector > Security credentials and confirm the key status is Active.
5. If using CloudFormation templates (Open CFT (Application Account Prerequisites) or Open CFT (Security Account Prerequisites)), confirm the stacks completed successfully in the AWS CloudFormation console in each respective account.

IAM Permission Errors

1. The IAM user or role used by CIE requires all seven permissions from the CIE-IPTag-ReadOnly policy: ec2:DescribeInstances, ec2:DescribeTags, ec2:DescribeNetworkInterfaces, ec2:DescribeVpcs, ec2:DescribeVpcEndpoints, ec2:DescribeSubnets, and ec2:DescribeRegions. Missing permissions cause partial or empty tag collection.
2. Check the IAM policy attached to the user or role in the AWS IAM console. Use the IAM Policy Simulator to test whether the required actions are allowed.

Region Filtering Not Working

1. In the CIE Monitor Configuration, verify the selected regions are correct. Deselecting All Regions without selecting specific regions results in no regions being polled.
2. Confirm the IAM credentials have permission to describe resources in the selected regions. Some organizations apply region-level Service Control Policies (SCPs) that block API calls to specific regions.

Tag collection from Azure fails or returns tags from only some subscriptions.

Service Principal Authentication Failures

1. Verify the Client Secret has not expired. Navigate to Azure Portal > Azure Active Directory > App Registrations > select the app > Certificates & secrets. Check the Expires column. An expired secret causes Not connected status in CIE with no further error detail.
2. Verify the Client ID and Tenant ID in the CIE Credential Configuration match the values shown in the Azure app registration's Overview page.
3. If the secret was recently rotated, update the Client Secret in the CIE Credential Configuration and re-submit.

Subscription Scope Issues

1. The service principal must have the Reader role assigned on every subscription from which tags should be collected. Navigate to each target subscription > Access control (IAM) > Role assignments and confirm the app registration has the Reader role.
2. If tags appear from some subscriptions but not others, the missing subscriptions lack the Reader role assignment for the CIE service principal.
3. Verify the Subscription ID in the CIE Credential Configuration matches the primary subscription. Additional subscriptions are covered if the service principal has Reader access to them.

API Throttling with Large Tag Sets

1. Azure Resource Manager applies API rate limits per subscription. Environments with thousands of tagged resources may experience throttling, resulting in Partially connected status.
2. Increase the Polling Interval in the CIE Monitor Configuration (up to 1800 seconds) to reduce API call frequency and avoid hitting rate limits.

Tag collection from GCP fails, returns no labels, or shows fewer resources than expected.

Service Account Key Issues

1. Verify the JSON key file uploaded to CIE corresponds to an active service account. Navigate to GCP Console > IAM & Admin > Service Accounts and confirm the service account is not disabled.
2. Check whether the specific key used by CIE is still listed under the service account's Keys tab. Keys deleted from the GCP console invalidate the credential immediately.
3. If the key has been rotated, download the new JSON key file and re-upload it in the CIE Credential Configuration.

API Not Enabled

1. The Compute Engine API (compute.googleapis.com) must be enabled in the GCP project for CIE to read instance metadata and labels. Navigate to APIs & Services > Enabled APIs & services and search for Compute Engine API.
2. If not enabled, click Enable APIs and Services, search for Compute Engine API, and enable it. Wait 2–3 minutes before retrying the CIE connection.

Project-Level vs Organization-Level Access

1. CIE credentials are scoped to a specific GCP project. To collect tags from multiple projects, configure a separate Credential Configuration for each project, or grant the service account cross-project IAM roles at the organization level.

Labels vs Network Tags

1. GCP distinguishes between labels (key-value pairs on resources) and network tags (simple strings used for GCP firewall rules). CIE collects both types. Labels appear as gcp.label.<key>.<value> and network tags appear as gcp.tag.<value> in the IP-tag registry.
2. To verify, navigate to a GCP Compute Engine instance > Details tab and check both the Labels section and the Network tags section. Then confirm the expected entries appear on the CIE Tag To IP tab.

Use the following PAN-OS CLI commands to diagnose CIE cloud tag collection, DAG membership, and security policy matching issues.