AWS Training
Modules Listen Certification
What SPICE is, and how it is sized Q2 — SPICE Internals and Data at Scale
0:00 0:00

← SPICE Internals and Data at Scale

Q2 Quiz — SPICE at scale

18 questions. Four options each, one correct answer, no partial credit. Answers and explanations below.

1. A SPICE dataset has 100 M rows and one text column averaging 12 UTF-8 bytes. Roughly what does that column contribute to logical size?

2. Which change reduces a dataset's SPICE footprint?

3. An Enterprise dataset fails at 780 million rows. The most likely cause is:

4. You need a 15-minute SPICE refresh cadence. Someone proposes splitting the dataset into four so each can refresh independently. What happens to your CreateIngestion consumption?

5. Which quota is adjustable via a service limit increase?

6. An ingestion returns IngestionStatus: COMPLETED but the dashboard totals are 3% below the source. Which field do you read first?

7. create-ingestion returns HTTP 409 with LimitExceededException. Correct handling is:

8. RequestType: EDIT in the ingestion history indicates:

9. Which pair of error types should be distinguished before you start debugging networking?

10. The source team adds a column to a table overnight. This morning's refresh fails. The fix is:

11. Incremental refresh with a 7-day window on order_date. A March order is corrected in August. When does the dashboard reflect it?

12. Which two error types most often generate unnecessary 3am pages?

13. You want to change a dataset from a daily schedule to an hourly one, via automation. Correct order:

14. Deleting an incremental refresh configuration:

15. SPICE capacity purchased in us-east-1 is available to a dataset in eu-west-1:

16. Auto capacity purchasing is turned off on an account already at its capacity ceiling. What happens to the next refresh that would exceed capacity?

17. A visual against Redshift in direct query mode times out after 2 minutes. On the cluster:

18. Your executive dashboard is stale because last night's refresh failed. Correct initial support case severity:

Answers and explanations

1 — C (3.6 GB). Text cells cost 24 bytes plus UTF-8 length: (24 + 12) × 100 M = 3.6 GB. A is the content alone (12 × 100 M) and ignores the 24-byte overhead — the classic underestimate. B would be the cost if it were a numeric or date column (12 bytes). D is nonsense arithmetic.

2 — C. Logical size is computed at dataset save, after transformations and calculated columns. AWS is explicit that changes made in an analysis have no effect on SPICE size — which rules out A, B and D. Only excluding the field in the dataset itself removes the storage.

3 — B. 780 M is well under 2 billion, so A is out. The row and size quotas are an OR, and AWS notes that with large rows you can reach the gigabyte quota first. C would fail at dataset creation, not at 780 M rows. D produces a LimitExceededException on the API call, not a mid-ingestion failure.

4 — C. The API_CREATE-INGESTION quota is 32 calls per 24 hours per Region, not per dataset. Four datasets each refreshed hourly is 96 calls against a quota of 32. A is the intuition that makes this a trap. D is wrong in any case — the quota is not adjustable.

5 — C. In the Service Quotas table, Quick Automate maximum automations (1,000) is marked adjustable. Rows per dataset isn't even in the quota table; API_CREATE-INGESTION and the visual query timeout are both explicitly marked not adjustable.

6 — B. RowsDropped is "the number of rows that were not ingested" and can be non-zero on a COMPLETED run — the silent-wrongness failure mode. ErrorInfo is typically empty on a completed ingestion, QueueInfo describes blocking, and byte size won't tell you about row loss.

7 — C. LimitExceededException on 409 means a quota, most often the 32-call one, which won't clear for hours. Retrying (A) spins pointlessly. B fixes ResourceExistsException, a different 409. D still calls CreateIngestion and consumes the same quota.

8 — B. RequestType values are INITIAL_INGESTION | EDIT | INCREMENTAL_REFRESH | FULL_REFRESH. EDIT means the dataset was saved, which triggers an ingestion — frequently an unintended full reload. Capacity changes (C) don't appear in ingestion history; superseded runs (D) surface via ErrorInfo.Type.

9 — B. UNRESOLVABLE_HOST is DNS: the name didn't resolve, so go to Route 53 or your private hosted zone. UNROUTABLE_HOST means it did resolve but there's no path — security groups, route tables, VPC connection. The other pairs are real distinctions but don't split your debugging in two like this one does.

10 — C. Verbatim from the user guide: Quick Sight cannot auto-detect a database schema change, and the fix is to edit and save the dataset. A is exactly the wrong instinct; B is unnecessary destruction; D addresses a different failure entirely.

11 — C. Incremental refresh deletes and replaces only the rows inside the look-back window. March falls outside every future 7-day window, so the corrected row is never re-queried. This is why every incremental schedule needs a periodic full refresh.

12 — B. Both indicate that two operations overlapped and this one lost — a superseded ingestion and a refresh suppressed while someone was editing. Neither is a defect. The options in C are real problems that should alert; A includes a genuine AWS-side error worth escalating.

13 — B. Hourly schedules are exclusive: "If you decide to use an hourly refresh, you can't also use additional refresh schedules." So the daily must be deleted first. A fails. C invents a conversion that doesn't exist. D contradicts the documented exclusivity.

14 — B. "Deleting an incremental refresh configuration starts a full refresh. As part of this full refresh, all the configurations prepared for incremental refreshes are removed." On a large dataset that's a multi-hour reload and one of your 32 daily ingestion calls.

15 — C. "SPICE capacity is allocated separately per AWS Region … The other AWS Regions have no SPICE capacity unless you choose to purchase some." There is no cross-Region sharing and no replication setting that changes this.

16 — C. "When auto purchase capacity is turned off, ingestions or refreshes that exceed the account's SPICE capacity automatically fail." There is no queue, no overage billing, and no fallback to direct query.

17 — B. "not all database drivers react to the 2-minute timeout, for example Amazon Redshift. In these cases, the query runs for as long as it takes for the response to return." Only a database-side control — a WLM queue with a statement timeout, or manual cancellation — stops it.

18 — B. A stale dashboard is a non-critical function behaving abnormally: normal, System impaired, 12-hour first response. AWS advises reserving the top severities for issues that can't be worked around or that take production down, and on paid plans you can raise severity later if impact grows. low under-calls a live production problem.

Scoring

Score Reading
16–18 You can run this conversation with AWS Support. Move to Q8.
13–15 Solid. Re-read lessons 2 and 4 — the quota/refresh interactions are where the gaps are.
9–12 Re-read the module and do the lab. The distinctions haven't become reflexes yet.
≤ 8 Start again at lesson 1. This module is cumulative and lesson 1 carries the sizing model.

The five that matter most in practice: 4 (quota is per Region), 6 (RowsDropped), 11 (incremental window), 15 (capacity per Region), 17 (Redshift timeout). Miss any of those and you will meet it in production.