Prepare and test your skills

Prepare and test your skills

Free sample question, answered and explained below. The Professional Data Engineer practice bank has 1,353 more like it. Try 10 free: instant score, no account.
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:
Which combination of Looker access controls and LookML configurations should the data engineer implement?
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.
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.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.access_filter) ensure that filtering cannot be bypassed or removed by report viewers or dashboard creators.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.
This option attempts to enforce row-level filtering using static LookML parameters (sql_always_where), relies on database-level authorized views for model isolation, and duplicates Explores while hardcoding hidden: yes to hide sensitive metrics.
sql_always_where applies a static, unconditional SQL filter to every user querying that Explore unless paired with complex conditional Liquid templating. It does not natively map dynamically to user identity without user attributes, unlike access_filter.hidden: yes hides a field permanently from the field picker for all users, including finance personnel. Creating duplicate Explores violates the "Don't Repeat Yourself" (DRY) principle and increases maintenance overhead.hidden: yes does not provide selective role-based visibility.This approach would be partially applicable if an organization did not use Looker's semantic security layer and instead required strict, physical database isolation where different groups connect to completely different database endpoints.
This option suggests configuring the entire security framework inside Looker Studio (formerly Data Studio) using Viewer's Credentials, email-based data source filters, and report-level calculated field logic.
The architecture relied exclusively on standalone Looker Studio reports connected directly to Google Sheets or BigQuery tables without a central Looker (LookML) semantic layer.
This option suggests using folder (space) permissions to control model access, placing dynamic SQL filtering logic in database connection configurations, and attempting to parse OAuth tokens directly inside LookML view files.
access_grant and required_access_grants referencing Looker user attributes.The requirement were purely about organizing shared dashboards and preventing unauthorized users from editing curated visualization folders.
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
Keep the momentum going with these hand-picked practice scenarios
Last updated Validated