12.5 SageMaker Unified Studio Domains, Projects & Catalog Governance

12.5 SageMaker Unified Studio Domains, Projects & Catalog Governance

Amazon SageMaker Unified Studio brings analytics, data, machine learning, and generative AI tools into a governed project experience. The exam focuses on the hierarchy and access path, not on treating Unified Studio as a replacement for IAM or Lake Formation.

Domain hierarchy

A domain is the top-level collaboration and governance boundary. It has a portal, identity configuration, root domain unit, and execution roles. Administrators make capabilities available to users and establish authorization policies.

Domain units organize assets and projects around business structures such as Finance, Risk, or Retail. A domain-unit owner can receive delegated authority to manage policies for that part of the organization. Domain units are not AWS accounts or VPC subnets; they are governance groupings inside the domain.

A useful hierarchy is:

Domain → domain unit → project → resources and catalog inventory

Place a project in the domain unit that owns its business purpose and policies. Moving a project or changing policy needs impact analysis because its resource and access context can change.

Projects and project profiles

A project is a collaboration boundary for one business use case. Project members share files, tools, data access, and resources. A project profile defines which tools and infrastructure are provisioned or made available when the project is created, potentially including Redshift, SageMaker AI, query, notebook, and other capabilities.

Do not grant every domain user membership in every project. Assign project owners and members from job function, separate development and production duties, and review membership. The project has an execution role used by tools to query and process data. Human permission to open the portal and data-plane permission for that execution role are separate layers.

Managed versus unmanaged responsibility

Unified Studio is managed: AWS operates substantial portal and service infrastructure. Managed does not mean ungoverned. Customers still configure identities, project memberships, authorization policies, VPC access, KMS choices, execution roles, Lake Formation integration, resource limits, and data approvals.

Likewise, a self-managed Spark cluster offers host and framework control but requires patching and capacity operations; a managed or serverless service reduces those duties. Choose from functional and control requirements, then secure the controls that remain yours.

Inventory, publish, and subscribe

A producer first brings an asset into a project's inventory. Inventory is visible to that project's members. The producer enriches it with business names, descriptions, glossary terms, metadata forms, ownership, and quality context.

Publishing the latest inventory asset version makes it discoverable in the SageMaker Catalog to domain users. If the producer later updates the inventory, the newest version must be published again; discovery should not silently expose an unreviewed draft.

A consumer searches the catalog and requests a subscription. After approval, the system grants access to the consumer project's execution role, commonly through Lake Formation for governed tables. The individual who clicks Request is not necessarily the principal that reads the data.

This distinction explains common failures:

• Catalog asset is visible, but the execution role lacks Lake Formation or IAM access.
• Lake Formation grant exists, but the project tool uses a different execution role.
• Subscription is revoked in catalog workflow, but a separate broad S3 permission still bypasses it.
• User leaves the team, but stale project membership remains.

Authorization policy design

Use domain-unit authorization policies to delegate only the needed actions, such as creating projects from approved profiles. Project profiles should embed secure defaults: encryption, logging, private connectivity, bounded compute, and approved resource roles.

Separate these roles:

Avoid one execution role shared by unrelated projects; it blurs attribution and can make one project's grant available to another.

End-to-end governed query

For a project member to query a catalog table:

1. The person authenticates and is authorized to enter the project.
2. The table is inventoried, curated, and published.
3. A subscription or direct grant authorizes the project.
4. Lake Formation and IAM grant the project's execution role the required metadata and data access.
5. The query tool assumes or uses that role.
6. CloudTrail, query logs, and catalog history provide evidence.

Network reachability and KMS decrypt permission must also succeed. Authorization does not repair a missing VPC route, and connectivity does not grant table access.

Operational governance

Track project owner, member review date, profile version, execution role, active subscriptions, resource cost, and last activity. On project closure, revoke shares, preserve required evidence, expire temporary resources, and delete derived data according to retention policy.

Use lineage and quality results in the catalog so consumers can judge fitness. A technically queryable table without ownership, freshness, or business definition should not be promoted as a trusted asset.