Cloudera CDP Administrator - Public Cloud common mistakes
Cloudera CDP Administrator - Public Cloud · Understand the traps and how to avoid them.
Treating CDP Public Cloud as if the Control Plane ran inside the customer's VPC and answering provisioning questions from that assumption, for example claiming the Data Lake and Data Hub clusters share a subnet or that the Control Plane must be reachable from the workload network.
Candidates carry over mental models from CDP Private Cloud Base or from single-VPC cloud designs. CDP Public Cloud splits the Control Plane (managed by Cloudera, outside the customer environment) from the Data Plane (in the customer's cloud account and VPC). Because the UI presents everything as one console, it is easy to assume a single network boundary and then get firewall, peering, and endpoint questions wrong.
What to do instead
Draw the two-plane model explicitly before answering: Control Plane (management console, orchestration, CDP CLI/API endpoints) versus Data Plane (Data Lake, Data Hubs, Data Warehouse, Data Engineering, Operational Database, streaming, all in the customer account). State which components live in the customer VPC, which cross the boundary, and which endpoints must be reachable outbound from the workload subnet. Then answer the specific question against that diagram.
Mixing up who manages what during cluster lifecycle operations - describing Data Hub upgrades, patch application, or node repair as tasks the administrator performs manually on every node, or else claiming the Control Plane performs OS-level patching inside the customer VPC without any customer-side prerequisites.
The lifecycle split is subtle: the Control Plane orchestrates cluster creation, scaling, upgrade, and repair through the CDP CLI/API, but the actual cloud resources, IAM roles, security groups, and network plumbing are customer-owned. Candidates who only read the marketing description of 'fully managed' miss the customer responsibilities, and candidates who only know on-premises workflows overcorrect into manual node administration.
What to do instead
Memorise the split: Control Plane = orchestration, blueprints, cluster definitions, upgrade coordination; customer = cloud account, VPC/subnets, IAM instance profiles and cross-account roles, security groups, storage buckets, and any custom images or bootstrap actions. Practise describing a Data Hub upgrade as an API-driven rolling replacement of nodes orchestrated by the Control Plane, not as SSH-and-yum work.
Answering SDX questions by describing the Data Lake as a simple metastore or by placing the SDX governance services on the Data Hub clusters, rather than recognising the Data Lake as the home of the SDX services (Ranger, Atlas, the metastore, and the identity/authorisation backbone) that every attached Data Hub consumes.
Candidates learn Ranger and Atlas as standalone services from on-premises experience and assume each cluster runs its own copy. In CDP Public Cloud the Data Lake hosts the shared SDX services and Data Hubs are consumers. This produces wrong answers about where policies are stored, where audits land, and what happens to a Data Hub when the Data Lake is unavailable.
What to do instead
Anchor on the architecture: the Data Lake cluster hosts the SDX stack (Ranger for authorisation and audit, Atlas for lineage and metadata, the Hive metastore, and the identity provider integration), and Data Hubs attach to it and inherit its policies. When asked where a policy is defined, where an audit record is written, or why a Data Hub lost authorisation, reason from the Data Lake as the authority.
Confusing CDP workload user management (workload users and workload groups, plus machine users) with cloud identity-provider groups, and assuming an IdP group automatically grants access to a Data Hub or to a database.
CDP Public Cloud has two layers: authentication via the identity provider (SAML/OIDC) into the Control Plane, and authorisation inside the workload via workload users/groups plus Ranger policies. Candidates who only know one layer assume the other is automatic, so they answer that adding a user to an IdP group is sufficient to query a table, or that a workload user can log into the Control Plane without an IdP account.
What to do instead
Separate the two questions every time: (a) can this person authenticate to the Control Plane / environment? - answered by the IdP and CDP workload user mapping; (b) can this person read this table or use this queue? - answered by Ranger policies on the Data Lake, evaluated against the workload user/group. Practise tracing a request end to end: IdP login, workload user resolution, Ranger policy evaluation, audit record.
Treating Ranger policies as sufficient for data access while ignoring the storage-layer authorisation model, and therefore answering that a Ranger table grant alone lets a user read the underlying object-store files, or conversely that bucket policies make Ranger grants irrelevant.
CDP Public Cloud data access passes through two gates: the object store's own authorisation (bucket policies and the IAM role the workload assumes) and Ranger. Candidates who come from HDFS-only environments forget the object store, and candidates who come from pure cloud backgrounds forget Ranger. Both groups give a one-gate answer to a two-gate question.
What to do instead
For any 'can user X read data Y' question, walk both gates: does the workload's cloud identity (instance profile / IAM role) permit access to the bucket and prefix, and does a Ranger policy grant the user's workload group the required column/table/database privilege? State explicitly that both must allow access, and note that Ranger authorises the user while the instance profile authorises the cluster.
Describing Data Warehouse (Impala/Hive) or Data Engineering (Spark) workload scaling as adding nodes to a fixed cluster, instead of using the workload-level autoscaling and stop/start semantics that the CDP Public Cloud services expose.
Candidates map 'scale the cluster' from on-premises or from IaaS habits onto CDP Public Cloud, where Data Warehouse and Data Engineering are exposed as workloads with their own sizing, autoscaling configuration, and start/stop lifecycle rather than as hand-built clusters. The terminology overlap between Data Hub clusters and workload services causes the confusion.
What to do instead
Learn the service boundaries: Data Hub = a cluster of the classic CDP Runtime with a specific service set; Data Warehouse and Data Engineering = managed workload services with their own compute sizing and autoscaling settings. When asked to handle a load spike, prefer raising the workload's autoscaling bounds or adding a virtual warehouse / compute cluster over resizing a Data Hub.
Assuming that deleting a Data Hub or workload also deletes its data in cloud object storage, or that stopping a workload destroys the metastore tables it created.
On-premises instincts say the cluster and its data are co-located. In CDP Public Cloud the data lives in object storage (the Data Lake's storage location, often with separate buckets or prefixes per environment) and the metastore lives in the Data Lake. Cluster deletion is compute deletion. Candidates who assume co-location give dangerously wrong answers about data retention and cost.
What to do instead
State the separation explicitly: compute (Data Hub nodes, workload compute) is ephemeral and billed while running; storage (object store buckets, Data Lake storage, metastore) persists independently. For any deletion or stop question, identify which layer is affected and confirm that table definitions in the metastore and files in the bucket survive unless the storage itself is removed.
Reading a failed Data Hub provisioning event as an application bug and starting with service logs, when the actual failure is in cloud prerequisites such as a missing IAM role, an unreachable endpoint, an exhausted quota, or a subnet with no free IPs.
Candidates are trained to debug Hadoop services and default to the service log. In CDP Public Cloud most first-time provisioning failures are infrastructure: the cross-account role is missing a permission, the security group blocks the Control Plane endpoint, the availability zone lacks capacity, or the account hit a vCPU or EIP limit. The service never starts, so its logs are empty and the candidate hunts in the wrong place.
What to do instead
Adopt a fixed triage order for provisioning failures: (1) Control Plane event/status message and the CDP CLI describe output, (2) cloud prerequisites - IAM role and trust policy, security groups and route tables, DNS, service endpoints, quotas, subnet capacity, (3) image and blueprint compatibility, (4) only then service-level logs. Practise naming the cloud-side check you would run first for each symptom.
Diagnosing performance problems by looking only at the workload's own metrics (Impala query profile, Spark UI) and never checking the shared Data Lake, metastore, or object-store layer that all workloads depend on.
CDP Public Cloud concentrates shared services in the Data Lake, so a slow metastore, saturated Ranger/Atlas service, throttled object-store requests, or a Data Lake node under memory pressure degrades every attached workload at once. Candidates who debug only the workload see healthy query plans and conclude the query is fine, missing the shared dependency entirely.
What to do instead
When multiple independent workloads slow down simultaneously, look at shared components first: Data Lake host metrics (memory, disk, network), metastore latency, Ranger/Atlas health, and object-store request rates and throttling. Use the simultaneous-onset pattern as the discriminator - one slow query points at the query, many slow queries point at the Data Lake.
Planning maintenance and cost without accounting for the environment lifecycle: leaving Data Hubs and workloads running when idle, ignoring the difference between stopping a workload and deleting it, and forgetting that the Data Lake must stay up for attached workloads to function.
Cost and maintenance questions reward knowing what is billed and what depends on what. Candidates treat all clusters as interchangeable, so they propose deleting the Data Lake to save money, or stopping a Data Hub while expecting its workloads to keep serving, or leaving everything running and calling it maintenance. The dependency direction (Data Hubs and workloads depend on the Data Lake) is the missing fact.
What to do instead
Memorise the dependency and billing rules: the Data Lake underpins attached Data Hubs and workloads and cannot be removed while they exist; stopping compute stops compute billing but leaves storage billing; object storage is billed whether or not compute runs. For any cost or maintenance scenario, state what is stopped, what is deleted, what still depends on it, and what continues to be billed.