Amazon QuickSight Interview Questions: SPICE, Row-Level Security, and Correct Metrics

Amazon QuickSight interview questions become more useful when you connect three checks: is the data current, is this reader allowed to see it, and does the metric answer the intended business question? A dashboard can render quickly and still fail any of those checks. Start with one tenant-filtered sales dashboard, then explain how you would prove each result independently.

AWS now documents these BI capabilities as Quick Sight within Amazon Quick; its 2025 announcement introduced the Quick Suite naming. We retain QuickSight in this title because it identifies the interview topic, while using the current documentation for behavior. Official naming context.

Evidence boundary: the service facts below come from AWS. The tenant, conversion counts, and diagnostic checks are original exercises. No verified candidate report establishes that an employer asks this exact QuickSight sequence.

What does SPICE change about the data path?

SPICE is Quick Sight's in-memory calculation engine. Importing a dataset stores a prepared copy for analysis; direct query asks the connected source instead. AWS describes SPICE as a way to reuse imported data and reduce repeated source-query work. It does not make later source changes appear automatically. Official SPICE concepts.

For the exercise, a warehouse contains orders for tenants Acme and Birch. An import finishes at 08:00. At 08:20, a warehouse correction changes an Acme refund. A reader opens the dashboard at 08:30. The correct first question is which dataset revision the visual uses. A fast result from the 08:00 snapshot can be stale even though the warehouse query returns the corrected value.

Our recommendation is to draw the complete freshness path: upstream ingestion, warehouse transformation, Quick Sight ingestion, then reader query. Record the last successful import and the source watermark—the latest upstream data included in it. An import timestamp alone cannot prove that an upstream job had finished before the import began.

Also name the business tolerance. A daily executive report and an operational refund monitor can accept different delays. Choose SPICE or direct query against that requirement, source performance, reader concurrency, and the required access model. Avoid promising that one mode is universally faster or cheaper without a workload measurement.

Why can a successful refresh still leave the wrong number?

AWS supports incremental refresh for SQL-based sources using a configured look-back window. Data inside that window is queried and replaces the corresponding SPICE data. AWS also warns that database schema changes may require editing and saving the dataset before ingestion can succeed. Official refresh behavior.

Suppose this original dataset refreshes the last seven days using order_date. Today's correction belongs to an order from forty days ago. If the corrected row remains outside that window, an incremental refresh can complete without replacing it. Increasing dashboard query speed does nothing to repair that missing revision.

First inspect the ingestion type, status, selected timestamp column, and actual source rows included. Then decide whether to perform a full refresh, expand the window, or redesign upstream correction handling. The choice depends on correction frequency and refresh cost. Changing the window is a data policy, so validate old corrections and deletions rather than assuming recent inserts cover the problem.

Keep the failure modes separate. A failed ingestion can leave an older successful copy available. A successful ingestion can import an incomplete upstream table. A complete import can still feed a visual with the wrong date filter. These observations require different fixes and should appear separately in your answer.

For a convincing freshness check, retain two tiny queries: one returning the source's expected row count and latest business timestamp, and another returning the specific corrected order. Compare those with the imported dataset's observed result at the same scope. These are our diagnostic recommendations, not a built-in end-to-end freshness guarantee.

What does row-level security actually authorize?

Row-level security, or RLS, restricts dataset rows according to a permissions dataset. In AWS's user-based model, the rules identify users or groups and allowed field values. AWS documents this feature for Enterprise Edition and distinguishes dataset owners, who can see all data, from readers restricted by the rules. Official user-based RLS.

A dashboard filter is a presentation choice. It is not evidence that an unauthorized reader cannot obtain another tenant's rows. For this exercise, the restricted field is a string tenant_id; Acme's reader must receive only Acme records. Test that identity directly instead of validating solely through the owner's preview.

The following is an original test matrix for the documented user-based rule semantics. It does not describe tag-based anonymous embedding, which requires its own configuration and documentation.

Identity and rule	Expected access in this exercise	What the test catches
Reader with tenant_id = Acme	Acme rows	Basic positive permission
Reader absent from all applicable rules	No rows	Unintended default access
Reader with an applicable blank tenant rule	All tenant values	Accidental wildcard
Dataset owner	All rows	Owner preview masking reader restrictions

AWS explicitly documents that a user or group rule with other fields empty grants all values, while an identity without an applicable rule sees no data. Treat blank permission values as deliberate policy, not harmless missing information. Test group membership as well as direct user assignments; checking only one row in the rule file can miss an additional grant.

Our suggested negative test asks an Acme reader to request Birch's view through a saved dashboard state or changed filter. The result must remain restricted by authorization. Then repeat with a reader who has no grant. Record the actual identity, rule revision, dataset, and returned rows, without exposing another tenant's sensitive data in the test evidence.

How do you diagnose an RLS mismatch without guessing?

Start by confirming the user or group identifier used by the configured rule dataset. Next inspect the restricted field name, type, and actual values in both datasets. A display label such as “Acme Corporation” and an internal identifier such as acme-01 are different values; the intended business relationship does not make them interchangeable.

Check whether the correct permissions dataset is attached and whether a recent rule change reached the version being used. Keep this investigation distinct from refreshing the sales dataset. You are validating two different inputs: business rows and permission rules. Record a test identity whose expected rows are known before comparing dashboard screenshots.

Do not attempt to repair a denial by adding a blanket grant. Explain what the denied operation should permit and change only the mismatched rule. Conversely, do not interpret an owner's ability to see everything as proof that RLS is broken. The documented owner behavior is precisely why reader-specific tests matter.

If the business needs a cross-tenant benchmark beside tenant-local results, define that publication separately with an approved aggregation and access policy. A calculated field is not an authorization decision. Our design recommendation is to avoid smuggling protected rows into a denominator merely because a stakeholder wants a global comparison.

Which metric is correct: average of rates or ratio of sums?

Use an original conversion example. Campaign A has one conversion from two eligible visits; campaign B has ninety from one hundred. Their individual rates are 50% and 90%. Averaging those rates gives 70%. Combining the underlying counts gives 91 / 102, approximately 89.2%.

Neither arithmetic operation is inherently defective. They answer different questions. An equally weighted average describes the average campaign rate; the ratio of sums describes conversion across the eligible visits. Define the unit receiving weight before writing the formula. A global conversion KPI usually needs an explicit numerator and denominator at the same eligibility scope.

For an additive dataset whose fields already represent compatible counts, the intended conceptual calculation is:

sum({conversions}) / sum({eligible_visits})

Handle a zero denominator according to the agreed reporting policy; an undefined rate should not silently become zero conversion performance. Also confirm whether visits are deduplicated and whether conversions can exceed one per visit. A formula can compile while the measure definitions remain incompatible.

Add campaign_id to the visual, then remove it. The campaign rows should reconcile with their underlying counts, and the total should match the independently computed definition. A change in visual dimensions can reveal accidental weighting that a single aggregate card concealed. Repeat after filtering to campaign A: a selected-visit conversion rate should become 50%, while an intentionally fixed benchmark denominator needs its own expected value and label.

When do level-aware calculations help?

AWS's level-aware calculations let authors specify an aggregation or window level independently of the visual's dimensions. LAC-A specifies grouping for aggregation; LAC-W controls a window calculation's partition and evaluation level. Official LAC guide.

The sumOver documentation distinguishes PRE_FILTER, PRE_AGG, and the default POST_AGG_FILTER. It also changes whether its measure argument should already be aggregated depending on that level. These settings are part of the calculation contract, not labels to memorize. Official sumOver reference.

In your answer, say which rows and groups must contribute before choosing a level. Does a product filter change both numerator and denominator? Should the denominator represent selected products or all authorized products? Does adding a region dimension change the partition? Predict the result on two rows before moving to the full dashboard.

Our recommendation is to write the expected number outside Quick Sight, then test the field under each relevant filter and dimension change. Do not insert PRE_FILTER as a generic fix for every inconsistent total. A calculation that ignores a presentation filter may be correct for one comparison and wrong for another.

What if the join has already multiplied the measure?

Consider an original order worth 100 with two item rows. Joining an order-header amount onto both items produces two rows containing 100. Summing that column gives 200. A distinct count of the order identifier returns one, but it does not repair duplicated revenue.

State the grain of every source before joining: one row per order, item, payment, refund, or tenant-day. Explain the join cardinality and which measures remain additive afterward. Our preferred repair for this exercise is to aggregate each fact to the intended compatible grain before joining, or use a model that preserves the separate facts.

Keep refunds and currency definitions explicit. Gross booked sales, net recognized revenue, and cash received are different metrics. Combining USD and EUR amounts without a defined conversion policy is not a meaningful total. These are business-contract recommendations; they do not imply that Quick Sight automatically chooses an accounting policy for you.

Practice Amazon QuickSight interview questions with evidence

The Tableau question supports comparison of live and imported data; its reported prompt does not establish QuickSight-specific interview behavior.

Question	QuickSight follow-up to rehearse
Design an End-to-End Customer Delivery Experience Dashboard	Define the grain and freshness contract for each KPI.
Design a One-Page Warehouse Inbound Dashboard	Separate operational delay from stale imported data.
Clean and Aggregate Transactions for Finance Dashboard	Reconcile counts, refunds, and denominators.
Compare Tableau live vs extract and filters	Compare source querying with SPICE snapshots.
Write SQL for 7-day geo-localized revenue dashboard	Validate time boundaries before importing aggregates.

For a final rehearsal, answer the Acme case in order: identify the imported revision, reproduce the reader's authorized rows, then reconcile the metric with a small oracle. Only afterward discuss performance. Choose another Business Intelligence Engineer practice question and explain what observation would disprove your diagnosis.

Sources and Further Reading

• AWS: QuickSight's evolution and Quick Sight naming
• AWS: SPICE concepts
• AWS: Refreshing imported data
• AWS: User-based row-level security
• AWS: Level-aware calculations
• AWS: sumOver function
• AWS: Dataset calculated fields

Research checked October 4, 2026. Examples are original arithmetic and diagnostic exercises; no AWS account, tenant authorization test, or dashboard benchmark was executed for this article.