Removing Domain Access Is Not Enough: Audit Knowledge Catalog Bindings

A permission-removal ticket is not complete just because an Identity and Access Management (IAM) update returns successfully. For Knowledge Catalog data domains, that assumption is specifically unsafe in Preview: Google documents that resource authorization is checked when a resource-domain binding is created, while later IAM changes are not continuously synchronized into existing bindings. A resource can therefore remain associated with the domain after the domain principal loses the resource role that originally enabled the binding.

That lifecycle detail matters to data-platform teams, catalog owners, IAM engineers and data stewards because three questions are easy to collapse into one: who can administer the domain, who can discover bound metadata through the domain, and who can actually access the underlying data system. They are not the same control plane.

Google announced Knowledge Catalog data domains as Preview in its Google Cloud release notes dated September 7, 2026. The core data-domain documentation had already been updated on September 3, 2026, so treat September 7 as the release-note announcement date, not the documentation publication date. Google Cloud’s “About data domains,” last updated September 3, 2026 and accessed September 15, 2026, states the critical limitation directly: there is no continuous background IAM synchronization in Preview.

This runbook separates documented product behavior from a proposed operating model. After a revocation, you should be able to prove which association was removed, which metadata paths still work, which underlying-resource paths still work, and what remains unresolved.

Define the access-removal outcome before changing IAM

Start with the desired after-state, not with the IAM command. “Remove access” is ambiguous unless the ticket states what must stop: domain administration, Knowledge Catalog metadata discovery, global or service-native search, or actual resource use. A steward who says “Riley should no longer see Finance data” may mean metadata, rows, schemas, query ability, or all four.

The distinction is operationally important because Knowledge Catalog data domains organize and expose metadata while underlying services retain their own authorization models. Google’s data-domain overview says domain-scoped discoverability can expose a resource within the domain even when the user lacks direct BigQuery access, while a search outside the domain uses underlying-system access instead. That is enough to reject a one-line acceptance criterion such as “user cannot find the dataset.”

Use this proposed desired-after-state table before any change:

A related Refonte overview on data lake and warehouse management is useful background for inventory and governance, but this runbook goes narrower: it treats the binding itself as a lifecycle object that must be reconciled independently.

Proposed acceptance gate: do not begin revocation until the ticket identifies the resource, domain, human or service principals, intended discovery outcome, intended resource-access outcome, and the owners authorized to approve each change. An unknown owner is not a reason to guess; it is a stop condition.

Separate domain roles, resource authorization and bindings

The fastest way to create a revocation incident is to use the word “role” without naming where that role is granted. Data domains have domain-management roles for people and service accounts, domain entry-discovery permissions for users, and a separate domain IAM principal that a resource owner authorizes on an underlying resource. A binding then associates that resource with the domain.

Google’s “Create and manage data domains,” live documentation accessed September 15, 2026 distinguishes the Dataplex Data Domain Configuration Editor, which can update domains and resource bindings, from the Configuration Viewer, which can view configuration and bindings. Entry discovery is a different concern: Google documents the Data Domain Entry Reader role, roles/dataplex.dataDomainEntryReader, as allowing a domain user to discover resources and view their metadata within the domain context.

A human domain user is not the domain IAM principal

Google’s resource-inclusion documentation says a resource owner grants IAM permissions to the data domain IAM principal on the target resource or project, and separately distinguishes that action from granting a user permissions on the data domain. Google Cloud’s “Include resources in data domains,” last updated September 3, 2026 and accessed September 15, 2026.

Do not translate “the domain principal has BigQuery metadataViewer” into “all domain users have BigQuery metadataViewer.” The principal is an authorization actor for the domain. Also do not call it inherently powerless. Google documents Reader, Writer and Admin role types for domain authorization, with recommended underlying roles varying by resource. Some recommended roles are metadata-oriented, while others can carry stronger operational or data permissions; for example, the documented Spanner Reader recommendation includes database read/query capability.

Least privilege therefore has to be evaluated against the exact resource type and role, not against the label “Reader” alone.

A binding is not a continuously synchronized permission mirror

This is the central documented behavior. Google states that authorization is verified when the binding is created; revoking the domain principal’s IAM role later does not automatically unbind the resource. The same page says users holding roles/dataplex.dataDomainEntryReader can continue to discover the resource and view its metadata until the resource-domain binding is explicitly deleted.

That means “IAM policy now correct” and “catalog association now removed” are two separate assertions. The first can be true while the second is false. Treat every resource-role revocation affecting a bound resource as a trigger for binding reconciliation, not as proof that reconciliation has happened.

Inventory existing bindings and their owners

A revocation workflow cannot be reliable if the team cannot enumerate what is bound, why it was bound, and who owns both sides of the trust decision. Google documents that directly included resources can be viewed from the domain’s Resources tab and that bindings can be listed with the projects.locations.dataDomains.bindings.list method. Those are product capabilities. The ledger below is a proposed operating artifact, not a native Google Cloud record format.

The ledger should not infer ownership from who happened to execute a command. Platform operators often have delegated privileges but are not the accountable data owner. The related Refonte discussion of DBA and data engineering responsibilities is useful context for separating operational execution from ownership; for this runbook, that separation becomes an explicit audit field.

Proposed stop rule: if the resource owner is unknown, the domain owner is unknown, or the binding inventory cannot be reconciled to the resources visible in the domain, pause new binding creation for the affected scope. Continue evidence gathering and containment, but do not “clean up” associations based on guesswork. An undocumented binding can be a stale disclosure path, but a blind deletion can also break an intentional discovery workflow.

For existing estates, bootstrap the ledger from product-visible bindings, then have resource owners attest purpose and audience. Mark every unattested row as unresolved rather than silently treating age as approval. The objective is not paperwork volume; it is being able to answer one revocation question quickly: which existing association must be deleted if authorization changes?

Map the distinct visibility and access paths

A defensible test plan needs at least three paths: domain-scoped discovery, discovery outside that domain context, and native access to the underlying resource. Google’s overview gives a concrete BigQuery example: a user with Data Domain Entry Reader can see a bound dataset when searching within the domain even without direct BigQuery permission, while a general search outside the domain does not apply the domain’s discoverability permission.

This is why a catalog test should never be represented as a data-access test. It also explains why a user may still find a resource after unbinding: the user can have independent underlying permissions that make the resource discoverable through a broader path.

A separate Refonte article on business-facing data context shows why semantic discovery matters to consumers, but do not let a useful business-facing search experience blur the source of authorization. Every observed result should be tagged with the path that produced it.

Domain discovery and broader search need different controls

Use two test identities whenever practical. The first is the affected domain user with no intended direct resource entitlement. The second is a control user who deliberately retains direct access to the underlying resource. After unbinding, the first user should no longer rely on the domain association for discovery; the control may still find the resource through broader search or service-native interfaces because its direct authorization is independent.

Record the query context, identity, timestamp, object identifier, expected outcome, actual outcome and an explanation of the permission path. Do not simply capture a screenshot saying “still visible.” Visibility without the context field can be misdiagnosed as a failed unbinding when it is actually direct resource access.

Underlying resource access must be tested independently

The resource test must use a native operation appropriate to the authorization objective: for example, metadata-only inspection if metadata access is in scope, or a read/query attempt if data use is in scope. Do not broaden the test beyond what the incident or offboarding requires.

The result matrix should distinguish metadata visible, binding administrable, and data operation permitted. One can change while another does not. That separation is especially important because the domain IAM principal itself may hold permissions beyond mere metadata inspection depending on the resource authorization role selected.

Design a least-privilege binding creation process

Good revocation starts at creation time. If the binding ticket does not capture the resource owner, intended audience, exact domain principal authorization and expected future removal path, the offboarding team inherits ambiguity later.

Google documents three domain-authorization role types: Reader, Writer and Admin. All three can enable binding creation, while Writer and Admin are intended for broader actions. It also tells administrators to choose based on the long-term level of access intended for the domain. That is not a recommendation to choose the broadest role for convenience. The recommended IAM role differs by resource type, and the effective permission set must be reviewed before grant.

Use this proposed creation gate:

The organization’s broader data governance practices can supply policy context, but the operating control here is narrower: authorization and binding are approved together, recorded separately, and tested separately.

Proposed policy: an operator may create a binding only when the ledger row is complete enough to support later deletion without rediscovering ownership from scratch. If a project-level authorization is used because a resource cannot be directly authorized through the console or because inheritance is intentional, record that broader scope explicitly. Google notes that some supported resource types are authorized at project level in the console, so the evidence should reflect the real grant location rather than an assumed resource-level grant.

Finally, never use successful binding creation as evidence that the selected IAM role is still appropriate indefinitely. Creation-time success proves that the check passed at that moment. Preview behavior expressly means later drift is possible.

Plan revocation as a sequence with explicit checks

There is no documented atomic “revoke domain access and delete every binding” transaction in the sources reviewed. Treat the workflow below as a proposed operating sequence, not a vendor-guaranteed transaction. The product behavior you can rely on is narrower: authorization is checked at binding creation, and explicit binding deletion is available.

The order can vary by incident severity. In an unintended disclosure, containment may require removing the human’s domain discovery permission first, followed by unbinding and resource authorization correction. In planned offboarding, the team may remove direct native access first. What must not vary is the evidence model: every control surface gets an explicit before and after state.

Do not infer that removing the domain principal’s resource authorization will cause the existing binding to disappear later. Google explicitly says there is no continuous background IAM synchronization in Preview. Likewise, do not infer that deleting the binding revokes a user’s independent BigQuery, Spanner, BigLake or other native authorization. Unbinding changes the catalog association; native access must be changed and tested through the underlying service’s authorization model.

Recovery boundary: if the expected binding cannot be found, the resource identifier does not match the ticket, or ownership is disputed, stop destructive steps and return to inventory. A missing association in one UI view is not enough to conclude that all relevant paths are gone.

Handle explicit unbinding without losing evidence

Google’s “Include resources in data domains,” last updated September 3, 2026 and accessed September 15, 2026 states that removing a resource unbinds it from the domain hierarchy. It documents both the console workflow and the REST method projects.locations.dataDomains.bindings.delete. This is the action that changes the existing association; revoking the domain principal’s resource role alone is not a substitute.

Before deletion, preserve the minimum evidence needed to review the decision later. Do not copy sensitive schemas, row samples or secrets into the ticket merely because metadata was visible.

Do not promise that every search surface, cache or downstream catalog immediately reflects deletion unless you have product-specific evidence for that surface. The Google documentation establishes the logical unbinding operation, but the sources reviewed here do not provide a universal propagation-time guarantee for every possible external or cached search path.

A safe acceptance rule is therefore state-based rather than time-based: the authoritative binding listing no longer contains the association, and repeatable visibility tests produce the intended results for the named identities. If a broader search still returns the resource to a directly authorized control user, that can be expected behavior rather than a failed unbind.

When evidence conflicts, such as when the binding list shows no association but the domain-only user still sees the resource, keep the ticket open, capture the exact search context, and investigate effective permissions and product behavior. Do not “fix” the discrepancy by escalating role breadth or deleting unrelated IAM grants.

Work through a revoked role with lingering metadata

The following is a fictional exercise, not a claim about a real customer or a performed production test.

Assume a Finance domain contains a BigQuery dataset called finance_curated. Dana is the data steward and domain owner delegate. Riley is a domain entry reader with no direct BigQuery access to that dataset. Omar is the resource operator who can modify the dataset’s IAM policy and the catalog binding under approved change control. Casey is the control user who intentionally retains direct BigQuery permissions sufficient for the organization’s approved resource test.

Before the change, Riley can find the dataset inside the Finance domain and inspect its catalog metadata. Casey can find or access the dataset through paths enabled by direct resource permissions. The domain IAM principal has the resource authorization that allowed the binding to be created.

Permission removal without binding removal

Google documents the expected hazard directly: when the domain principal’s IAM role on a resource is revoked, the resource is not automatically unbound, and domain users with Data Domain Entry Reader continue to discover the resource and view its metadata until the binding is explicitly deleted.

So, after Omar removes the domain principal’s resource role, an IAM success response is only evidence that the resource policy changed. It is not evidence that Riley’s domain-scoped metadata visibility ended. Dana should require the binding inventory to be checked immediately. If the binding remains and the desired outcome is removal from Finance, explicit unbinding is the next control action.

This is the key data domain binding revocation proof: the lifecycle object survives the authorization change unless separately deleted. A closure note that says “role removed successfully” is incomplete for metadata-discovery revocation.

Explicit unbinding with a directly authorized control user

After Omar deletes the binding, Riley’s Finance-domain discovery result should be retested. Casey is deliberately kept as a control because Casey’s independent underlying permission may still support broader discovery or actual resource access. Google’s search limitation says domain discoverability does not apply to searches outside the domain; broader results depend on underlying-system access.

Therefore, Casey still seeing the dataset after unbinding does not, by itself, prove that the binding persists. Conversely, Riley failing to find the dataset in the Finance domain does not prove that Riley lacks all native access; that must be tested separately.

Exercise acceptance: close only when the authoritative binding is absent, Riley’s domain-only discovery path behaves as intended, Casey’s retained visibility is attributable to direct authorization, and the native read/query tests match each identity’s approved after-state.

Test negative access as carefully as successful discovery

Positive tests are easy to celebrate and easy to overinterpret. A successful search proves that one path works; it does not tell you why every other path works. Negative tests are more demanding because a denial can come from the intended revocation, an unrelated missing permission, a wrong scope, or a test identity that was never representative.

Use the following proposed data governance revocation test matrix. Blank result cells are intentional; teams should fill them with observed evidence rather than copied expectations.

Google’s resource-inclusion documentation supports the product-specific behavior in the first row. The expected outcomes in the other rows are an operating model that follows the separation of control planes; they still require local verification, especially where IAM is inherited.

A related Refonte discussion of database administration foundations provides broader security and operational context. Here, the practical discipline is to preserve the exact identity and control path for every negative test.

Do not invent propagation service-level objectives. Google’s resource-authorization instructions mention waiting two to three minutes after certain authorization grants in the console before proceeding, but that is not evidence for a universal revocation or search-propagation guarantee across every path. Your runbook should therefore record observation times without converting them into an unsupported promise.

A sound negative test has a positive control. If Riley is expected to lose Finance-domain discovery, also test an unaffected domain entry that Riley should still see, or use another authorized user to prove the search feature itself is functioning. If native query access should be denied, use Casey’s approved direct access to prove the dataset is reachable and the test failure is identity-specific rather than a service outage.

Respond to unintended metadata visibility

When a user can still see metadata that should have been removed, treat it as a disclosure-path incident until you can explain the authorization path. Do not automatically describe it as proven access to the underlying data. Metadata can itself be sensitive: names, schemas, descriptions, ownership context and usage guidance may reveal information, but a catalog result does not prove that rows were readable.

The first containment decision is which path can be safely narrowed without destroying evidence. If the affected human should not discover the domain at all, removing the relevant domain-user permission can be appropriate. If the resource should not be associated with the domain for anyone, explicit unbinding is the relevant association control. If the underlying resource authorization is also wrong, correct that separately.

Proposed containment checklist: freeze new bindings for the affected scope if ownership is uncertain; snapshot binding and IAM state; remove only the permissions/associations supported by approved ownership decisions; execute the three-path test plan; and keep the incident open for any unexplained visibility.

The most important evidence-minimization rule is not to reproduce the disclosure in more places than necessary. Record identifiers, role paths and test outcomes. Use restricted evidence storage for screenshots if they reveal sensitive schema or descriptions. A revocation record can itself become a secondary metadata leak if copied into broadly readable tickets or chat channels.

Finally, resist the urge to label every post-change search hit a “cache issue.” That is an unverified assumption unless the relevant product documentation or support evidence says so. First test whether the identity has an independent direct permission or inherited domain role.

Reconcile drift and reopened access paths

Preview limitations make drift reconciliation a first-class control. Google says there is no continuous background IAM synchronization for domain authorization, so a permission change after binding creation does not automatically update the association. The operational consequence is straightforward: you need a scheduled comparison between what is bound, what is still authorized, who is allowed to discover it, and who owns the resource.

This review does not need invented native metrics. Build local governance metrics from your binding ledger and test results, clearly labeled as organizational measures.

A reasonable proposed schedule is owner-approved rather than arbitrary: review after any relevant IAM change, after ownership transfer, after resource moves or project-level policy changes, and on a recurring cadence selected by risk. Do not present a monthly or quarterly frequency as a Google requirement; it is your governance choice.

The reconciliation job should compare identifiers, not display names. It should also preserve exceptions. A binding can intentionally outlive one authorization change if the owner replaces the required permission through another approved path, but that decision must be recorded and re-tested. Conversely, an old binding that still “works” is not automatically justified merely because no user complained.

Drift review should include inherited permissions. Google’s domain-access documentation notes that a user’s access can be inherited from a higher-level IAM policy and therefore cannot always be removed at the domain level. Effective-access testing is necessary because looking only at the local domain policy can miss the path that reopened discovery.

Make the revocation record independently reviewable

A good revocation record lets a reviewer who did not execute the change reconstruct what happened without relying on the operator’s memory. The evidence should show identities, resource scope, prior state, change, final state, binding status and test results. It should also say what remains intentionally accessible.

Keep the packet precise. Do not attach raw IAM policies containing unrelated principals if a scoped extract can prove the change. Do not include secrets, tokens, query results with business data, or personal information that is irrelevant to the control decision.

A Refonte article on DBA communication and handover skills provides useful background on operational handoffs. In this runbook, the handoff standard is technical: another engineer should be able to distinguish a binding deletion from a domain-user IAM removal and from an underlying-resource revocation.

Use explicit evidence labels. “Documented behavior” should cite the Google source establishing the product rule. “Proposed control” should name the local owner and acceptance criterion. “Observed result” should include identity, time and path. “Unverified assumption” should never be allowed to masquerade as a passed test.

The record should also capture negative findings such as “broader search still visible to Casey due to approved direct BigQuery permission.” That sentence is valuable because it prevents a later reviewer from reopening a resolved binding incident based on an expected control-user result.

Proposed closure condition: every requested removal maps to an observed denial or association absence, every retained path has an owner-approved explanation, and no unknown ownership or unexplained discovery path remains.

Pilot one domain and rehearse its removal workflow

Because Knowledge Catalog data domains were announced in Preview on September 7, 2026, treat rollout as a controlled pilot rather than assuming the feature’s lifecycle behavior will remain unchanged. Recheck the living documentation before broad production adoption or later publication, especially the authorization limitation and binding-removal procedure.

Use this proposed 30-day pilot, which is an operating model rather than a Google schedule:

Keep the pilot narrow enough that every association is explainable. Include at least one deliberate direct-access control user and one domain-only entry reader. Rehearse the failure case that matters most: remove the domain principal’s resource role without deleting the binding, confirm that this is not sufficient evidence of metadata revocation, then perform the explicit unbind and re-test. The drill validates the team’s procedure against the documented Preview limitation without claiming a universal outcome beyond what is observed in the pilot.

Pilot checklist: verify owner names before binding; record the domain principal and exact resource scope; create positive and negative discovery baselines; rehearse explicit unbinding; store a reviewable closure packet.

For practitioners building the underlying skills to operate such controls, Refonte Learning’s Data Engineering Program page lists a three-month format at 12–14 hours per week and covers data pipelines, batch and streaming ingestion, encryption techniques, data protection, and data-governance/compliance controls; its admissions information says learners should be engaged in bachelor’s or postgraduate study. The page does not establish a dedicated Knowledge Catalog data-domain module, so treat those as supporting foundations rather than feature-specific training.

Answer the binding questions and close only verified removals

The operating rule is simple even though the control planes are not: do not close on the success of a single IAM change. Close on a verified after-state across association, discovery and resource access.

Does removing the domain principal’s resource IAM role automatically remove an existing binding? No. Google explicitly documents that authorization is checked at binding creation and that revoking the domain principal’s IAM role does not automatically unbind the resource in Preview.

What requires explicit unbinding? When the desired outcome is to remove the resource from the domain association, delete the resource-domain binding. Google documents that removing the resource unbinds it from the domain hierarchy and provides a binding-delete operation.

Does metadata disappearance prove underlying data access is revoked? No. Domain-scoped discoverability and underlying-service access are separate. Google’s search limitation shows that domain search and broader search can produce different results depending on direct resource authorization. Native access therefore needs its own test.

Is Preview ready for unattended, policy-only revocation automation? The sources reviewed do not support that conclusion. The documented lack of continuous background IAM synchronization means an operating process must reconcile existing bindings explicitly. Whether your organization automates that reconciliation is an architecture decision that should be validated against current APIs, ownership controls and Preview changes, rather than assumed from the IAM event alone.

Completion checklist: binding state reconciled; domain-user discovery tested; broader search tested with a direct-access control; native resource access tested; owner and evidence packet complete. If any one of those remains unknown, the access-removal case is not verified closed.