Cohesity DataProtect common mistakes
Cohesity DataProtect · Understand the traps and how to avoid them.
Treating a Protection Policy's RPO as a single schedule value, so the candidate picks a policy with a 4-hour RPO for a workload that actually needs 15-minute snapshots, or assumes the RPO equals the backup start time rather than the maximum tolerable data loss window.
The exam presents policies as a bundle of schedule, retention, and replication settings; candidates memorize the policy name and a single number instead of decomposing how the snapshot schedule, snapshot retention, and replication schedule interact to define RPO and RPO compliance.
What to do instead
Before answering, write out three lines from the scenario: required RPO, required retention, and whether replication to a remote cluster is required. Then map each to the specific policy field (snapshot schedule frequency, snapshot retention, replication schedule and retention) and eliminate any policy where a single field fails. Practice reading a policy as a set of independent constraints rather than one label.
Confusing snapshots with backups and treating a snapshot as a copy that survives loss of the source, so the candidate says a VM is protected because a local snapshot exists, or picks snapshot-based recovery for a scenario where the source array or host was destroyed.
Cohesity's data path is snapshot-based: the platform takes a point-in-time snapshot, then moves the data into the distributed file system. Candidates collapse these into one step and lose track of when data becomes independent of the source and when it does not.
What to do instead
Build a two-column table: 'still dependent on source' versus 'independent copy on the cluster'. Place the snapshot creation, the data transfer to the cluster, and any replication to a remote cluster in the correct column. For any disaster scenario, first ask whether the source is intact; if not, only the on-cluster or replicated copy counts.
Selecting a full-cluster or node-level recovery when the scenario only requires restoring a single VM, file, or application object, or the reverse: choosing a granular restore for a scenario where the entire source cluster was lost and a full source registration and recovery is needed.
The recovery workflow differs by scope (file-level, object-level, VM-level, source-level, cluster-level), and the UI paths look similar. Candidates anchor on the word 'restore' and pick the first matching option without checking the scope stated in the scenario.
What to do instead
For every recovery question, underline the scope word (file, folder, VM, application, entire source, entire cluster) and the target (original location versus alternate location). Then choose the recovery type that exactly matches that scope. Reject any option that restores more than required, since over-restoring is usually the distractor.
Assuming a protection group or policy automatically covers newly added VMs, databases, or shares, so the candidate answers that a new VM is protected once it is added to vCenter, without confirming it matches the protection group's selection criteria or has been explicitly included.
Protection groups can use dynamic selection (for example by tag, folder, or cluster) or static selection. Candidates remember 'register the source and create a policy' and skip the step where the object actually becomes a member of a protection group.
What to do instead
Memorize the chain: register source, create or attach policy, define protection group membership, verify the object appears as protected. For scenarios about a newly created object, check whether the selection is dynamic and whether the new object carries the required tag or resides in the covered container. If not, the fix is to add it to the group or adjust the selection rule.
Mixing up the roles of a Cohesity cluster, a registered source, and a remote cluster used for replication, so the candidate proposes replication to the same cluster, or says a policy's replication target can be the source being protected.
The exam tests the topology: a source is registered to a cluster, and replication targets are other clusters (or external targets). Candidates treat 'replication' as a synonym for 'retention' and place the copy in the wrong location.
What to do instead
Draw the topology on scratch paper: source to local cluster, local cluster to remote cluster. Confirm that any replication target in an answer is a distinct registered cluster or external target, not the source and not the same cluster. Eliminate answers that place the replica in a location that would be lost in the same failure domain as the original.
Answering ransomware-resilience questions with generic advice such as 'keep backups' or 'use antivirus', instead of naming platform capabilities like immutability, data-lock or retention locking, anomaly detection, and the ability to recover to a clean point in time.
Candidates treat ransomware as a security-awareness topic rather than a data-protection architecture topic. They do not connect the exam's resilience domain to specific configuration choices that make backups undeletable or make anomalous behavior visible.
What to do instead
Memorize a short list of concrete controls and what each defeats: immutable or locked snapshots (defeat deletion or encryption of backup copies), anomaly detection (surfaces unusual change rates or entropy), air-gapped or isolated copies (defeat lateral movement), and clean-room or isolated recovery (restores without reintroducing the payload). For each scenario, name the control and the specific attack step it blocks.
Confusing compliance features with backup features, for example assuming that because data is backed up it is automatically compliant, or that a retention policy alone satisfies a legal-hold or audit requirement without any additional configuration.
Retention, legal hold, audit logging, and access control are separate controls. Candidates see the word 'retention' in a scenario and stop reading, missing the part of the question that asks about evidence, hold, or access review.
What to do instead
Separate the question into 'what data exists' versus 'what proof exists'. Backup and retention answer the first; audit trails, role-based access, legal hold, and reports answer the second. When a scenario mentions auditors, regulations, or investigations, look for the answer that addresses evidence and immutability, not just copy count.
Ignoring role-based access control and multi-tenancy when answering data-security questions, so the candidate grants broad admin rights to solve an access problem, or assumes all users of a cluster can see all protected data.
The platform supports organizations, tenants, and granular roles. Candidates who learned only the admin workflow default to 'give them admin' and do not consider least privilege or tenant isolation as the intended answer.
What to do instead
For any access question, first identify who needs what and at which scope (cluster, organization, protection group, view). Then choose the narrowest role that satisfies it. Treat 'grant admin' answers as wrong unless the scenario explicitly requires cluster-wide administration. Also check whether the correct answer is to place the workload in a separate organization or tenant.
Diagnosing a failed backup by jumping to the most dramatic cause (cluster down, disk failure) rather than working through the standard triage order: source connectivity, credentials, policy and schedule, then cluster health and capacity.
Troubleshooting questions present a symptom and several plausible causes. Candidates who lack a triage order pick whichever cause sounds most technical, and distractors are written to sound technical and urgent.
What to do instead
Adopt a fixed triage sequence and apply it to every troubleshooting item: (1) is the source reachable and are credentials valid, (2) is the object in a protection group with an active policy, (3) did the run start and where did it fail in the log, (4) is there cluster capacity or health degradation. State which step the scenario's evidence points to, and eliminate causes that the evidence already rules out.
Reading monitoring and alerting questions as 'what does the dashboard show' instead of 'what action does this alert require', so the candidate selects the metric that is displayed rather than the remediation that resolves the condition.
Candidates study the monitoring UI as a tour of screens and never link each alert or metric to the operational response it triggers. Exam items often give an alert and ask for the next action.
What to do instead
For each key metric or alert (capacity utilization, failed protection runs, replication lag, component health), write one line: threshold that matters, likely cause, and first remediation step. Practice answering 'given this alert, what do you do next' rather than 'where do you see this'. Choose answers that resolve the condition, not answers that merely observe it.