A data engineer is designing security controls for an enterprise Looker deployment that queries a central data warehouse. The implementation must satisfy the following governance requirements: Model-Level Access: Users must only be allowed to see and query specific LookML models assigned to their department. Row-Level Security: Within a shared sales Explore, users must only view records associated with their assigned sales region. Field-Level Security: Sensitive financial metrics (such as gross profit margin) within the shared Explore must only be visible to authorized finance personnel. Which combination of Looker access controls and LookML configurations should the data engineer implement?

Assign user groups to roles combining model sets and permission sets, configure the access_filter parameter on the Explore using a region user attribute, and define an access_grant in the model file and apply required_access_grants on the sensitive fields.: ### What the Solution Is This approach leverages Looker's native governance framework by combining **role-based access control (RBAC)**, **user attributes**, and **declarative LookML security parameters** (`access_filter` and `access_grant`) to enforce granular data access. ### How It Meets the Requirements - **Model-Level Access**: **Model sets** group specific LookML models together. When combined with a **permission set** into a **role** and assigned to user groups, users are strictly prevented from viewing or querying models outside their assigned model set. - **Row-Level Security**: The `access_filter` parameter binds an Explore dimension directly to a Looker **user attribute** (e.g., `sales_region`). When a user runs a query, Looker automatically injects a parameterized `WHERE` clause into the generated SQL, restricting row-level data access seamlessly. - **Field-Level Security**: An `access_grant` defined at the model level checks a user attribute (e.g., `department: finance`). By applying `required_access_grants` on specific dimensions or measures, Looker hides those fields completely from unauthorized users in the field picker and prevents them from querying that data. ### Key Advantages - **Centralized Administration**: Access policies are defined declaratively in LookML and administered centrally via groups and user attributes. - **Single Source of Truth**: Eliminates the need to create duplicate Explores or views just to hide sensitive columns or filter rows. - **SQL Injection Prevention**: Built-in Looker parameters (`access_filter`) ensure that filtering cannot be bypassed or removed by report viewers or dashboard creators. - **Scalable Role Management**: Assigning roles to groups rather than individual users prevents permission creep and simplifies onboarding. ### Why This Is Optimal This is the native, recommended architectural pattern in Looker for multi-tier access control. It fully satisfies model restriction, row restriction, and field restriction within a unified semantic layer without code duplication or database-side schema sprawl.

Deploy Secure Looker Models And Explores | professional-cloud-data-engineer

Deploy Secure Looker Models And Explores

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A data engineer is designing security controls for an enterprise Looker deployment that queries a central data warehouse. The implementation must satisfy the following governance requirements:

Model-Level Access: Users must only be allowed to see and query specific LookML models assigned to their department.
Row-Level Security: Within a shared sales Explore, users must only view records associated with their assigned sales region.
Field-Level Security: Sensitive financial metrics (such as gross profit margin) within the shared Explore must only be visible to authorized finance personnel.

Which combination of Looker access controls and LookML configurations should the data engineer implement?

Manage model isolation using BigQuery authorized views, apply sql_always_where with static SQL values for each user group, and set hidden: yes on sensitive dimensions while creating duplicate Explores for finance users.

Assign user groups to roles combining model sets and permission sets, configure the access_filter parameter on the Explore using a region user attribute, and define an access_grant in the model file and apply required_access_grants on the sensitive fields.

Configure Looker Studio reusable data sources with Viewer's Credentials, implement filter-by-email at the data source level, and use report-level calculated fields to restrict sensitive measures to specific email addresses.

Configure folder-level permissions in shared spaces to restrict model access, implement dynamic Liquid SQL parameters directly in database connections for row filtering, and apply OAuth token claims inside view files to hide sensitive fields.

Professional Cloud Data Engineer

Deploy Secure Looker Models And Explores

Related questions