Cloudera CDP-3002 common mistakes
Cloudera CDP-3002 · Understand the traps and how to avoid them.
Assuming that enabling an Auto-TLS or Kerberos setting via Cloudera Manager automatically propagates to all services without a restart, and answering that a cluster-wide restart is never required.
Candidates study the wizard flow for enabling security but skim the deployment step; CDP requires redeploying client configurations and restarting dependent roles, and some services (HDFS, YARN, Hive, Oozie) must be restarted in dependency order. The exam frequently tests knowledge of which roles need restart versus a full cluster restart.
What to do instead
Learn the distinction between 'Deploy Client Configuration' (updates client configs only) and role restart versus service restart. Memorize that security changes touching principals, keytabs, or TLS keystores require restarting affected roles, and that Cloudera Manager shows a stale-configuration flag until restart. Practice the order: ZooKeeper, HDFS, YARN, then dependent services.
Treating the Cloudera Manager Server host as a place to also run DataNodes or NodeManagers, and answering that co-locating the management server with worker roles is a supported best practice.
In small test clusters candidates see everything on one host and generalize. The exam tests production topologies where the CM Server, database, and management services are separated from worker roles for resource isolation and availability.
What to do instead
Memorize that the CM Server and its backing database should be dedicated hosts, and that management services (Cloudera Management Service roles) are placed separately from data-plane workers. Know that High Availability for the CM Server uses an active/standby pair with a shared database, not co-location with workers.
Confusing Hive ACID transactional tables with plain ORC tables, and answering that any ORC table supports UPDATE and DELETE statements.
Candidates learn that ORC is the columnar format for Hive and assume it implies ACID. In CDP, ACID requires the table be created with transactional properties and the correct table type (full ACID managed tables, or insert-only), plus compaction configured.
What to do instead
Study the table property TBLPROPERTIES('transactional'='true'), the requirement for managed tables (or external with proper settings), the ORC file format requirement, and the difference between minor and major compaction. Know that bucketing is no longer mandatory in newer Hive versions but was historically required. Practice reading compaction status via SHOW COMPACTIONS.
Assuming Spark on YARN in CDP uses the same default resource model as standalone Spark, and misanswering questions about dynamic allocation and executor sizing.
Candidates focus on Spark application code and skip the cluster-manager integration. The exam tests how spark.executor.memory, spark.executor.cores, and yarn.nodemanager.resource.memory-mb interact, and how dynamic allocation shrinks and grows executors.
What to do instead
Learn the YARN container sizing formula: executor memory plus memory overhead (spark.yarn.executor.memoryOverhead or the default fraction) must fit within a YARN container. Understand that dynamic allocation requires shuffle service enabled and external shuffle service configured. Practice calculating max executors from available YARN memory and cores.
Answering that Ranger policies alone secure a table when the underlying HDFS path is still world-readable, ignoring that HDFS ACLs and Ranger HDFS policies must align with Hive/Sentry-style table grants.
Candidates treat Ranger as a single control plane and forget that a user with direct HDFS access bypasses Hive authorization. The exam tests defense in depth: table-level policy in Ranger plus path-level HDFS policy plus Kerberos identity.
What to do instead
Study the layers: authentication (Kerberos), HDFS authorization (Ranger HDFS policies or POSIX/ACLs), Hive authorization (Ranger Hive policies), and column masking/row filtering. Know that Ranger Hive policies do not automatically restrict direct HDFS reads unless HDFS policies also cover the warehouse path. Practice mapping a user's effective access across all three layers.
Assuming that enabling Kerberos is a one-time step and that adding a new host later requires no keytab or principal provisioning, leading to wrong answers about host commissioning under Kerberos.
Candidates memorize the initial Kerberos setup wizard but not the ongoing lifecycle. In CDP, adding hosts to a Kerberized cluster requires generating host principals and keytabs, and the CM Server must have permissions to create them via kadmin.
What to do instead
Learn the host-add flow: CM generates a host principal, requests a keytab from the KDC, distributes it, and configures services. Know the required kadmin privileges for the CM principal and that a missing or expired keytab causes service start failures. Practice reading keytab-related errors in role logs.
Answering that a failed service start should be fixed by restarting the whole cluster, rather than reading the specific role log and checking the health test that failed.
Candidates under time pressure pick the broadest action. The exam rewards targeted diagnosis: identify the failing role, read its log, check the health test, and remediate the specific cause (port conflict, permission, config drift).
What to do instead
Adopt a diagnostic sequence: check the CM health test message, open the role's stderr/stdout and log directory, verify configuration staleness, check disk space and permissions, then restart only the affected role. Memorize common causes: stale config, port in use, missing directory ownership, expired Kerberos ticket.
Confusing the roles of the Cloudera Manager Agent and the Cloudera Manager Server when troubleshooting heartbeat loss, and answering that the Server pushes commands directly to roles.
Candidates blur the control plane. The Agent runs on each host, heartbeats to the Server, and executes commands locally; if the Agent is down, the Server marks the host as bad even though roles may still run.
What to do instead
Learn the flow: Server stores state in its database, Agent polls/heartbeats, Agent runs role commands and reports status. Know that a host with a stopped Agent shows as 'bad health' but running roles continue until restarted. Practice checking agent logs and the agent's config for the Server URL and port.
Assuming that a YARN application failure is always an application bug, ignoring queue capacity, preemption, and the fair or capacity scheduler configuration that may be killing containers.
Candidates focus on application logs and miss scheduler-level causes. The exam tests reading the ResourceManager and NodeManager logs, understanding queue ACLs, and recognizing preemption messages.
What to do instead
Learn to check the RM UI for queue state, the application's diagnostics for 'container preempted' or 'queue capacity exceeded', and the scheduler configuration (fair vs capacity, weights, max resources). Know that preemption is a scheduler behavior, not an application error, and that queue ACLs control submission.
Answering that HDFS replication factor and block size are fixed cluster-wide defaults that cannot be overridden per directory or per file, missing the storage policy and per-path override mechanisms.
Candidates memorize the default dfs.replication value but not the per-path overrides. The exam tests storage policies (HOT, WARM, COLD, ALL_SSD, ONE_SSD) and the hdfs storagepolicies commands, plus per-file replication via setrep.
What to do instead
Learn that replication can be set per file with hdfs dfs -setrep, that storage policies are assigned per directory with hdfs storagepolicies -setStoragePolicy, and that block size is per-file at creation. Know the policy names and that Mover runs to move blocks to satisfy a policy. Practice mapping a policy to its replication and storage-type requirements.