Sample questions
Wh Redshift Distribution Sort VacuumDifficulty 1
In an Amazon Redshift provisioned cluster, which statement correctly describes the leader node's role?
- aIt stores a full replica of every table so queries never touch compute nodes.
- bIt executes the bulk of the join and aggregation work before sending results to compute nodes.
- cIt parses incoming queries, builds execution plans, and coordinates the compute nodes.✓
- dIt is only present in single-node clusters and disappears once you add compute nodes.
Explanation:The leader node receives queries from clients, parses them, builds the execution plan, and coordinates parallel execution across the compute nodes, then aggregates the results. It doesn't hold a full replica of every table, doesn't do the bulk of join/aggregation work itself, and it exists on multi-node clusters too (separate from compute nodes there).
Wh Redshift Distribution Sort VacuumDifficulty 1
In Redshift, what is a 'slice'?
- aA snapshot of a table taken automatically before every VACUUM.
- bA CPU/memory/disk share on a compute node that processes part of its data.✓
- cA billing unit used only for Redshift Serverless workgroups.
- dA separate compute node reserved exclusively for the leader node's metadata.
Explanation:Each compute node is partitioned into slices, and each slice gets its own share of the node's CPU, memory, and disk to process a portion of the node's data in parallel with the other slices. It has nothing to do with snapshots, Serverless-only billing, or leader-node metadata storage.
Wh Redshift Distribution Sort VacuumDifficulty 2
Why does the number of slices per compute node matter for how data spreads across a Redshift cluster?
- aRedshift distributes a table's rows across every slice in the cluster.✓
- bSlice count only affects backup file size and has no role in query execution.
- cRedshift always uses exactly one slice per cluster regardless of node type.
- dSlices determine which AWS Region a cluster is created in.
Explanation:A table's rows are distributed across every slice in the cluster according to the table's distribution style, so how many slices exist (node count times slices per node) directly shapes how finely that data — and the parallel work on it — is spread. Slice count isn't about backup size, isn't fixed at one per cluster, and has no bearing on region selection.
Wh Redshift Distribution Sort VacuumDifficulty 2
What does DISTSTYLE EVEN do when you create a table?
- aEvery row is copied to every node so every slice holds the full table.
- bRows are grouped onto slices strictly by the values of the primary key.
- cThe leader node hands out rows to slices round-robin, ignoring column values.✓
- dRedshift picks between KEY and ALL automatically as the table grows.
Explanation:With EVEN distribution, the leader node hands out rows to slices round-robin, independent of any column's values. Copying every row to every node describes ALL; grouping by a key column describes KEY; automatically switching between styles as a table grows describes AUTO, not EVEN.
Wh Redshift Distribution Sort VacuumDifficulty 2
What does DISTSTYLE KEY do?
- aRows are distributed to slices based on one designated column's values.✓
- bRows are distributed round-robin across slices regardless of column values.
- cThe full table is copied to every compute node in the cluster.
- dRedshift chooses the distribution column automatically at query time, per query.
Explanation:KEY distribution places rows on slices according to the hashed value of one chosen column, so rows sharing the same value in that column end up on the same slice. Round-robin placement describes EVEN, full replication describes ALL, and the distribution column is fixed at table design time, not chosen per query.
Wh Redshift Distribution Sort VacuumDifficulty 3
What is the direct cost of choosing DISTSTYLE ALL for a table?
- aQuery results become eventually consistent instead of strongly consistent.
- bThe table can no longer be joined with DISTSTYLE KEY tables.
- cRedshift disables compression encoding for that table.
- dStorage multiplies by the node count, and loads/updates take longer.✓
Explanation:ALL distribution puts a full copy of the table on every node, so storage grows roughly in proportion to node count, and loading, updating, or inserting into the table takes longer because every node's copy must be kept in sync. It doesn't touch consistency semantics, joinability with KEY-distributed tables, or compression support.