A retail analytics team runs a Looker dashboard on a 6 TB BigQuery orders table in the EU region. Each tile reissues the same aggregation over the last 90 days, and analysts must never see the raw card_number column although they group revenue by region and product. The team wants sub-second tile rendering and wants the masking enforced in the same physical table at query time based on the caller's group. Which TWO preparation steps, applied together, will both accelerate the dashboard and secure the card_number column? (Select TWO.)
- ACreate a BI Engine reservation in the EU region so the repeated aggregation queries are served from in-memory cache. Correct
- BExport the orders table to a Looker Studio extract refreshed every twelve hours so tiles read the cached extract instead of BigQuery.
- CApply a BigQuery column-level dynamic data masking policy on card_number that returns masked values to the analyst group while privileged callers see the raw value. Correct
- DGrant the analyst group the BigQuery Data Viewer role on the dataset and rely on that role to hide the card_number column.
- ECluster the orders table by card_number so the masked column is pruned and the aggregation queries scan less data.
Why A is correct: A regional BI Engine reservation co-located with the dataset caches hot columnar data in memory and accelerates the repeated aggregate scans, which is the correct path to sub-second tiles.
Why B is wrong: A twelve-hour extract is tempting because it caches data, but it does not enforce column-level masking and is not the in-engine acceleration the requirement asks for, so it fails the security goal.
Why C is correct: Dynamic data masking with a data policy on a policy-tagged column enforces masking at query time on one physical table based on the caller's group, exactly meeting the security requirement.
Why D is wrong: Data Viewer is tempting as an access control, but a dataset-level role grants full row and column visibility and cannot mask a single column, so card_number would remain exposed.
Why E is wrong: Clustering by card_number sounds like a performance lever, but clustering on a sensitive identifier does not align with the 90-day aggregation filters and provides no masking, so it neither accelerates the right queries nor secures the column.