Free Cloudera CDP Data Analyst (CDP-4001) Sample Questions

Correct answer: A — A cross tabulation table

• A. A cross tabulation table presents data in a grid of rows and columns with exact values, which is the visual type best suited to scanning precise numeric figures across many metrics and SKUs.
• B. A packed bubble chart encodes magnitude through bubble size, which is useful for spotting relative scale but poor for reading exact numeric values.
• C. A correlation heatmap encodes relationships through color intensity, which highlights patterns rather than presenting precise readable figures.
• D. A grouped bar chart is effective for comparing categories visually, but with dozens of metrics and SKUs it becomes cluttered and less precise than a tabular display.

Correct answer: A — Drill-down reveals a deeper level of a dimension hierarchy inside the same visual, while drill-through navigates to a different dashboard entirely

• A. Drill-down expands a dimension hierarchy to a more granular level within the same visual, while drill-through is the separate action of navigating to an entirely different target dashboard with parameters passed along.
• B. This reverses the two behaviors: drill-down is the in-visual hierarchy expansion, and drill-through is the cross-dashboard navigation with parameter passing, not the other way around.
• C. Neither drill-down nor drill-through requires an app; both interactions are available directly on standalone dashboards without needing an application wrapper.
• D. Drill-down is not limited to cross tabulation visuals, and drill-through is not limited to chart-based visuals; both interactions apply more broadly across supported visual types.

Correct answers: A, B, C — Parameters that arrived via the URL to the source visual; Parameters corresponding to the specific element the viewer clicked; Application scope parameters, when navigating within the same app

• A. Correct, because parameters that reached the source visual via URL are one of the supported types that transfer during drill-through navigation.
• B. Correct, because the parameter tied to the clicked element is passed along so the destination dashboard can build its visuals accordingly.
• C. Correct, because application scope parameters carry over when the navigation happens within the same app.
• D. Incorrect, because parameters explicitly defined directly on the source visual are one of the two documented exceptions that do not transfer.
• E. Incorrect, because parameters that fall outside the current application's scope are the other documented exception and are not passed along.

Correct answers: A, B, C — A visual built from the dashboard's associated dataset; A filter widget scoped to some or all of the visuals; A markup or text box used for titles and annotations

• A. Correct, because adding visuals built from the dashboard's dataset onto the canvas is the core purpose of the Dashboard Designer.
• B. Correct, because filter widgets are placed on the dashboard canvas and then associated with some or all of the visuals present.
• C. Correct, because markup or text elements can be added directly to the canvas alongside visuals for titles and annotations.
• D. Incorrect, because data connections are configured once at the platform level and are not created from within an individual dashboard's canvas.
• E. Incorrect, because row-level security policies are managed through Ranger, not added as elements on a dashboard canvas.

Correct answer: B — Impala enforces stricter typing than Hive and rejects implicit narrowing conversions like DOUBLE to FLOAT or BIGINT to INT

• A. This is incorrect; Impala is the engine that enforces stricter typing, not the one that mirrors Hive's more permissive narrowing behavior.
• B. Impala applies stricter type rules than Hive and does not perform implicit narrowing conversions such as DOUBLE to FLOAT or BIGINT to INT, requiring an explicit CAST where Hive would coerce automatically.
• C. This reverses the actual relationship; Hive is the more permissive engine with implicit narrowing, while Impala is the stricter one.
• D. Both engines do support some implicit conversions, such as widening an INT to a BIGINT; the distinction tested on the exam is about narrowing conversions specifically.

Correct answers: A, B, C — DECIMAL; DATE; BOOLEAN

• A. DECIMAL is one of the target types where an unconvertible source value causes Impala to return an error instead of NULL.
• B. DATE is one of the target types where an unconvertible source value causes Impala to return an error instead of NULL.
• C. BOOLEAN is one of the target types where an unconvertible source value causes Impala to return an error instead of NULL.
• D. DOUBLE is not in the error-raising group; an unconvertible cast to DOUBLE typically returns NULL rather than an error.
• E. STRING is not in the error-raising group; casting most values to STRING succeeds or returns NULL rather than raising an error.

Correct answers: A, B, C — Run `SHOW DATABASES LIKE '*order*'` to find candidate databases by name.; Run `SHOW TABLES IN <candidate_db> LIKE '*order*'` to list matching tables inside a candidate database.; Run `DESCRIBE FORMATTED <candidate_db>.<table>` to confirm the table's columns, type, and storage location before querying.

• A. Correct: narrowing down candidate databases by a name pattern is a reasonable first step when the exact database is unknown.
• B. Correct: once a candidate database is identified, filtering its tables by a pattern helps pinpoint the right table.
• C. Correct: inspecting the table's structure and storage location confirms it is the right object and safe to query before running real queries against it.
• D. Incorrect and destructive: dropping a table to test its existence risks permanently deleting data if it is a managed table, and is not a safe verification method.
• E. Incorrect: a full cluster-wide invalidation is an expensive, unnecessary step for simply locating one table and offers no benefit over a targeted search.
• F. Incorrect: querying a guessed table name without verification risks pulling data from the wrong object or failing outright.

Correct answer: A — NOT NULL

• A. Correct. Kudu primary key columns can never contain NULL values, so they are implicitly NOT NULL as part of the primary key semantics enforced by the storage engine.
• B. Incorrect. DEFAULT is an optional attribute for supplying a value when none is provided on insert; it is not implicitly required on key columns.
• C. Incorrect. COMPRESSION controls how column data is encoded on disk; it is an optional per-column setting, not something implied by being part of the primary key.
• D. Incorrect. BLOCK_SIZE configures the storage block size for a column and is optional; it has no implicit relationship with primary key membership.

Correct answers: A, B — Keep PRIMARY KEY and FOREIGN KEY clauses, adding DISABLE NOVALIDATE since they will only be informational; Remove CHECK constraints entirely, since Impala has no syntax to express row validation expressions

• A. Correct. PRIMARY KEY and FOREIGN KEY clauses can be kept as informational metadata on Parquet tables, but they must include DISABLE NOVALIDATE since Impala performs no validation.
• B. Correct. CHECK constraints have no equivalent in Impala's DDL grammar, so the only consistent action is removing them rather than trying to translate them.
• C. Incorrect. CHECK constraints are also unsupported in Impala, so substituting one unsupported constraint for another does not achieve validated uniqueness; neither is checked.
• D. Incorrect. Even on Kudu tables, NOT NULL only applies meaningfully as part of enforced column definitions and does not represent a blanket relocation strategy for all NOT NULL rules from the source schema.
• E. Incorrect. Specifying RELY only changes how the optimizer treats the relationship for planning purposes; it never causes Impala to block orphaned inserts, since the constraint is still unenforced.

Correct answer: A — Only the rows where the join key has a match in both tables, discarding rows from either side that have no counterpart.

• A. Correct. An `INNER JOIN` returns only rows where the join key exists on both sides, so unmatched rows from either table are excluded from the result.
• B. Incorrect. This describes a `LEFT OUTER JOIN`, which preserves every left-table row and pads unmatched right-table columns with nulls.
• C. Incorrect. This describes a `CROSS JOIN`, which produces the full Cartesian product of both tables without evaluating a join key at all.
• D. Incorrect. Returning only left-table columns for matched rows describes a `LEFT SEMI JOIN`, not a standard inner join.

Correct answer: A — `LEFT OUTER JOIN` from `customers` to `orders`.

• A. Correct. A `LEFT OUTER JOIN` keeps every row from the left table `customers` regardless of a match, while still returning `orders` columns when available.
• B. Incorrect. An `INNER JOIN` would drop customers with no orders entirely, which fails the requirement to include every customer.
• C. Incorrect. A `LEFT SEMI JOIN` would only return `customers` columns, omitting the order totals the dashboard needs to display.
• D. Incorrect. A `RIGHT ANTI JOIN` returns unmatched rows from the right table, not all rows from the left table, so it does not fit this scenario.

Correct answer: A — A process node representing the CTAS query connecting `orders` as an ancestor to `orders_summary`

• A. Correct. Atlas hooks capture the CTAS query as a process entity, and the lineage graph links `orders` as the input ancestor through that process to the newly created `orders_summary` table.
• B. Incorrect. CTAS is exactly the kind of transformation Atlas tracks through its Hive hook, so the lineage graph does record the connection back to the source table rather than treating the new table as isolated.
• C. Incorrect. Ranger policies are enforced separately from Atlas lineage; a classification tag, not a policy, is what can propagate through lineage, and even that requires the classification to be marked propagatable.
• D. Incorrect. Business glossary terms must be assigned manually or via governance workflows; they are not automatically generated from a CTAS lineage relationship.

Correct answer: A — The classification propagated automatically through lineage from an upstream source column that already carried the `PII` tag

• A. Correct. Since Atlas lineage can propagate classifications from a source column to columns created later from the same data, the downstream column inheriting `PII` without manual tagging is expected behavior.
• B. Incorrect. Ranger enforces access policies but does not assign classifications based on how many roles access a table; classification assignment is an Atlas governance function.
• C. Incorrect. Impala has no built-in mechanism to insert classification tags into new columns; classifications are an Atlas metadata construct, not a SQL engine feature.
• D. Incorrect. Classifications are not applied through random sampling of naming patterns; they are assigned manually or propagated deterministically through tracked lineage relationships.

Correct answer: A — A specific service resource, such as a database, table, or column, along with the users, groups, or roles permitted to act on it

• A. Correct. A resource-based policy names an explicit resource hierarchy (for example database > table > column) and attaches allow/deny permissions for specific users, groups, or roles.
• B. Incorrect. Binding a mask type to a tag name regardless of the underlying resource describes a tag-based policy, not a resource-based one.
• C. Incorrect. Lineage paths connecting source and derived entities are tracked by Atlas, not defined inside a Ranger resource-based policy.
• D. Incorrect. Business glossary terms and their inheritance are an Atlas governance feature; Ranger resource-based policies do not reference glossary terms.

Correct answer: A — Resource-based policies target explicitly named resources, while tag-based policies target any resource carrying a given classification

• A. Correct. Resource-based policies enumerate specific resources like a named database, table, or column, whereas tag-based policies apply wherever a referenced classification tag is present, regardless of the resource's identity.
• B. Incorrect. Resource-based policies are not limited to Kafka topics; they can be defined for any supported service resource, including HDFS, Hive, and HBase.
• C. Incorrect. Both resource-based and tag-based policies are evaluated by Ranger's policy engine; Atlas only supplies classification metadata, it does not perform policy evaluation.
• D. Incorrect. Both policy types support masking, row filtering, and allow/deny rules; the distinction is in how the policy targets resources, not which enforcement features are available.

Correct answer: A — The steward governs and describes data assets, while the engineer builds and maintains the pipelines that move the data

• A. This is correct because governance and metadata description are the steward's focus, while pipeline construction and data movement are the engineer's focus.
• B. This reverses the typical responsibilities; building ingestion jobs is engineering work, and access approval is closer to a governance or security role, not swapped this way.
• C. JVM tuning is a platform operations task, and glossary editing is a steward task, so this pairing misattributes both responsibilities to the wrong role.
• D. Firewall configuration is a network or security-admin task, and policy review scheduling is closer to a Ranger admin or steward oversight duty, not an engineering task.

Correct answer: A — The table is internal, so Impala manages the data files and deletes them when the table is dropped

• A. Correct. Without EXTERNAL, Impala creates an internal (managed) table by default, meaning Impala owns the data files and removes them when the table is dropped.
• B. Incorrect. External behavior only applies when the EXTERNAL keyword is explicitly used; the unqualified CREATE TABLE statement defaults to internal, managed ownership.
• C. Incorrect. The STORED AS clause selects the file format such as Parquet or text, but it has no bearing on whether the table is treated as internal or external.
• D. Incorrect. Ownership is determined at creation time by the presence or absence of EXTERNAL, not by a later ALTER TABLE statement changing table properties.

Correct answer: A — `'format-version'='2'`

• A. Correct. Setting `'format-version'='2'` in TBLPROPERTIES is the documented way to create a v2 Iceberg table in either Hive or Impala, enabling row-level delete support.
• B. Incorrect. `iceberg.version` is not the recognized property key; the actual TBLPROPERTIES key used to select the Iceberg table format version is `format-version`.
• C. Incorrect. `table.type` set to an ICEBERG_V2 string is not part of the documented Iceberg table creation syntax for selecting the format version.
• D. Incorrect. This property name resembles delete-mode configuration but is not the actual key used to select between Iceberg format versions at table creation.

Correct answer: A — The query's GROUP BY clause list

• A. Any selected column that is not itself wrapped in an aggregate function must be included in GROUP BY so Impala knows how to form the groups.
• B. ORDER BY controls result ordering and does not satisfy the requirement for grouping non-aggregated columns.
• C. A subquery is not required simply to include a non-aggregated column alongside aggregates.
• D. Wrapping a column in CASE does not remove the need to include it in GROUP BY if it is not aggregated.

Correct answers: A, D, F — CORR; HISTOGRAM_NUMERIC; PERCENTILE

• A. CORR computes a correlation coefficient in HiveQL and has no Impala equivalent.
• B. AVG is a standard aggregate function that Impala fully supports.
• C. SUM is a standard aggregate function that Impala fully supports.
• D. HISTOGRAM_NUMERIC builds a numeric histogram in HiveQL and has no Impala equivalent.
• E. COUNT is a standard aggregate function that Impala fully supports.
• F. PERCENTILE computes exact percentiles in HiveQL and has no Impala equivalent.

Correct answer: A — Impala prunes the scan to only the `order_year=2025` partition directory, skipping the data files for the other nine years entirely

• A. This is correct: because `order_year` is the partition key, Impala can determine from metadata alone which partition directory satisfies the predicate and skip reading the rest, which is partition pruning.
• B. Reading every partition and filtering afterward in memory would defeat the purpose of partitioning and is not how Impala evaluates a literal equality predicate on a partition key.
• C. Impala does not reorder evaluation so that non-partition string filters run before partition-key filters; partition pruning on `order_year` happens at the metadata level regardless of filter ordering in the query text.
• D. Impala does not automatically cache an entire table in memory on first use; the performance gain here comes from skipping partition directories, not from a memory cache.

Correct answer: A — `CREATE TABLE orders (customer_id INT, amount DOUBLE) CLUSTERED BY (customer_id) INTO 8 BUCKETS`

• A. `CLUSTERED BY (column) INTO n BUCKETS` is the correct Hive DDL syntax for declaring a bucketed table with a specific number of bucket files. This statement bucketing on `customer_id` into 8 files is valid.
• B. `PARTITIONED BY` declares a partition column and does not accept an `INTO n FILES` clause; partitioning creates one directory per distinct value, not a fixed file count. This syntax is not valid Hive DDL.
• C. `BUCKET BY ... LIMIT` is not valid Hive syntax for creating bucketed tables. The correct keyword pairing is `CLUSTERED BY ... INTO n BUCKETS`.
• D. `DISTRIBUTE BY` is a clause used in `SELECT` queries to control reducer distribution, not a table creation clause for defining bucket files. This statement would not create a bucketed table.

Correct answer: A — Bucket on `customer_id` because it has high cardinality and is the column used to join against `customers`

• A. A good bucketing column has high cardinality and is frequently used in joins, since matching buckets between the two tables enables efficient bucket-aligned joins. `customer_id` satisfies both criteria here.
• B. Bucketing on a low-cardinality column like `region` with only 6 distinct values causes hashing to distribute rows unevenly across buckets, since the hash space is effectively limited to 6 outcomes regardless of the requested bucket count. This produces skewed, poorly balanced bucket files.
• C. Hive `CLUSTERED BY` bucketing hashes on the specified column set as a whole and does not combine columns to intentionally maximize file count; adding a low-cardinality column to a high-cardinality one adds no join benefit here and complicates the layout.
• D. A synthetic row number is effectively unique per row, so hashing on it would scatter data with no meaningful grouping and defeats the purpose of clustering related rows together for joins or sampling.

Correct answer: B — Snappy, because it is the default codec that combines fast compression and decompression with a reasonable reduction in file size.

• A. GZip does shrink Parquet data more than Snappy, but that extra compression comes with higher CPU cost during both write and scan, which works against the team's priority of faster scans.
• B. Snappy is the default Parquet codec because its fast compression and decompression give a good balance between scan speed and storage savings, which matches a team that wants both without picking an unusual codec.
• C. Snappy, not Zstd, is the codec Impala applies by default when no compression codec is explicitly configured for Parquet output.
• D. Uncompressed scans can be marginally faster for a single-column aggregate, but the option overstates this as always minimizing total latency and ignores the storage cost the team also cares about.

Correct answer: A — To collect row counts and column statistics that the query planner uses to choose join order and resource allocation.

• A. This is correct: table-level row counts and per-column statistics such as NDV, null counts, and average size give the cost-based optimizer the information it needs to estimate join costs and pick an efficient execution plan.
• B. Impala does not enforce primary key or foreign key constraints, and statistics collection has nothing to do with constraint enforcement, so this is incorrect.
• C. Compacting small files is a file-management concern handled separately (e.g., via INSERT OVERWRITE or reloading data), not something statistics collection performs.
• D. Statistics collection reads existing partitions to gather metrics; it does not create new partitions or infer partition boundaries from data.

Correct answer: A — The first run scans every partition in the table, while later runs only process partitions that lack incremental statistics.

• A. This is correct: the initial run of incremental stats has no prior statistics to build on, so it scans the whole table, while later runs process only newly added or modified partitions that are still missing incremental stats.
• B. Sampling with a fixed percentage is part of the separate, opt-in extrapolation and sampling feature, not the default behavior of the first incremental stats run.
• C. Both table-level and column-level statistics are gathered together on each run; the split described here does not reflect how incremental stats work.
• D. Rescanning every partition on every run is what makes plain `COMPUTE STATS` costly on large tables; the incremental variant exists specifically to avoid that on later runs.

Correct answer: A — DESCRIBE FORMATTED table_name

• A. Correct. DESCRIBE FORMATTED returns detailed metadata including the table's HDFS location, storage/file format, and whether it is EXTERNAL or managed.
• B. Incorrect. SHOW FILES lists the data files belonging to a table or partition but is not the standard statement used to report the table's format and internal/external classification.
• C. Incorrect. EXPLAIN produces the execution plan for a query, not metadata about a table's storage location or type.
• D. Incorrect. ANALYZE TABLE is not a valid Impala statement for retrieving table metadata; statistics are gathered with COMPUTE STATS instead.

Correct answer: A — Starting the impalad daemon with the `--insert_inherit_permissions` option enabled

• A. Correct. The `--insert_inherit_permissions` startup flag for impalad makes newly created partition subdirectories inherit the permissions of their parent directory instead of receiving the default impala-user permissions.
• B. Incorrect. There is no `PARTITION_INHERIT` table property in Impala; permission inheritance for new subdirectories is controlled at the daemon startup level, not per-table DDL.
• C. Incorrect. Changing a table's LOCATION repoints where the table reads from and does not affect the permission behavior applied to subdirectories created during inserts.
• D. Incorrect. Granting broad superuser access changes what the impala user can do but does not configure automatic inheritance of parent-directory permissions for new subdirectories.

Correct answer: A — INSERT OVERWRITE reporting_table SELECT ... FROM raw_events

• A. INSERT OVERWRITE replaces the table's existing data files with the freshly computed result set each run, which matches the nightly full-refresh requirement while keeping the same table identity for the dashboard to query.
• B. INSERT INTO appends new rows on top of the previous night's data instead of replacing it, so the table would accumulate duplicate aggregates rather than reflecting only the latest results.
• C. CREATE TABLE AS SELECT would attempt to create a table that already exists, which errors out on a table with the same name rather than refreshing it in place.
• D. Writing to the underlying warehouse directory directly bypasses the metastore-tracked table lifecycle and is not the supported way to refresh a catalog table's contents.

Correct answer: A — EXTERNAL keyword together with a LOCATION clause pointing to the existing path

• A. This is correct because combining `EXTERNAL` with `LOCATION` registers the table over the existing files without Impala taking ownership, so the upstream job can keep writing there safely.
• B. This is incorrect because omitting `EXTERNAL` while pointing `LOCATION` at an existing shared path still creates an internal table, meaning a later `DROP TABLE` would delete the upstream job's files.
• C. This is incorrect because omitting `LOCATION` on an external table leaves it pointing at Impala's default warehouse directory instead of the actual dataset path, so it would not read the existing files.
• D. This is incorrect because Kudu tables use Kudu's own storage engine rather than referencing existing HDFS Parquet files, so `STORED AS KUDU` is not applicable here.

Correct answer: A — ALTER TABLE sales ADD PARTITION (sale_year=2025)

• A. `ALTER TABLE ... ADD PARTITION` is the correct DDL for registering a new partition, with an optional value, directory, or file format for an already partitioned table.
• B. There is no `INSERT PARTITION` DDL statement in Impala; INSERT statements load rows into partitions but do not register new partition definitions using this syntax.
• C. `CREATE PARTITION` is not valid Impala syntax; partitions are added to an existing table with an ALTER TABLE statement, not a standalone CREATE statement.
• D. `UPDATE TABLE` is not valid Impala DDL syntax for modifying table structure such as adding partitions.

Correct answer: A — Run REFRESH on the table so Impala reloads its metadata for the affected partitions

• A. When files are added outside of Impala, such as through Hive, running REFRESH (optionally scoped to a specific partition) tells Impala to reload the list of data files for that table or partition without a full metadata reload.
• B. A full catalog service restart is unnecessary and disruptive; REFRESH is the lightweight, purpose-built statement for picking up externally added data files.
• C. COMPUTE STATS updates table and column statistics used for query planning, but it is not the mechanism for detecting new data files added outside of Impala.
• D. Dropping and recreating the table is unnecessarily destructive and risks losing table metadata or permissions; REFRESH accomplishes the same goal without recreating the table.

Correct answers: A, B, C — XSMALL; SMALL; MEDIUM

• A. This is one of the standard t-shirt sizes offered for Virtual Warehouse compute, typically recommended for evaluation and light workloads.
• B. This is one of the standard t-shirt sizes offered for Virtual Warehouse compute, sitting above the smallest tier for slightly larger workloads.
• C. This is one of the standard t-shirt sizes offered for Virtual Warehouse compute, providing additional executor capacity for moderate concurrency.
• D. This is not one of the standard CDW t-shirt size names used for Virtual Warehouse compute sizing.
• E. This is not one of the standard CDW t-shirt size names used for Virtual Warehouse compute sizing.
• F. This is not one of the standard CDW t-shirt size names used for Virtual Warehouse compute sizing.

Correct answer: A — In the Database Catalog associated with that user's Hue instance

• A. Queries and query history saved in the Hue database are stored in the Database Catalog, keeping them tied to the metadata layer rather than to a specific compute session.
• B. Query history is not written to an unrelated object storage bucket; it is stored within the Database Catalog's Hue database.
• C. Storing history only in a browser cache would make it disappear across devices and sessions, which is not how Hue persists this data.
• D. Compute node logs are ephemeral and tied to warehouse uptime, whereas query history persists in the Database Catalog independent of warehouse suspension.

Correct answer: A — Create an additional Database Catalog in the environment for the development tables

• A. Creating an additional Database Catalog in the same environment isolates the development team's tables and permissions from production without the overhead of a new environment.
• B. Renaming the existing catalog does not create separation; production and development metadata would still live in the same catalog.
• C. Reactivating the environment does not reset or replace the existing default catalog and would not achieve isolation.
• D. Moving accounts is a disproportionate and unrelated action when adding a second catalog inside the existing environment solves the isolation need.