RCE common mistakes
RCE · Understand the traps and how to avoid them.
Treating recovery point objective and recovery time objective as interchangeable, then picking an SLA number that satisfies neither the data-loss tolerance nor the downtime tolerance the scenario describes.
Both are abbreviated as objectives and appear together in resilience discussions, so candidates memorize definitions but never practise deriving each from a stated business impact; under time pressure they grab whichever number appears in the scenario.
What to do instead
Before answering, write two separate lines: maximum acceptable data loss (drives RPO and snapshot/replication frequency) and maximum acceptable outage (drives RTO and failover automation). Then check which option satisfies both constraints rather than the tighter of the two.
Assuming a replication or backup configuration protects against ransomware because data is copied, without checking whether the copies are immutable, isolated, and restorable within the target RTO.
Vendors and internal runbooks emphasize copy counts and replication lag, which trains candidates to equate 'replicated' with 'protected'; the exam scenario usually hides a deletion or encryption path that reaches the replicas.
What to do instead
For any protection-design question, verify four properties explicitly: immutability or object lock, credential isolation from the production identity plane, an offline or air-gapped copy, and a tested restore time inside the RTO. Reject options that only add replicas.
Designing identity resilience around a single identity provider with MFA enabled, ignoring the dependency chain of directory, federation, DNS, and certificate services that must survive an outage of the primary provider.
MFA is the most rehearsed control, so candidates treat 'MFA everywhere' as a complete answer and skip the availability question of what happens when the identity provider itself is down or compromised.
What to do instead
Map the identity dependency chain and name a break-glass path for each link: a secondary authentication authority or local emergency accounts, cached credential validation, independent DNS and certificate issuance, and a documented, monitored, time-boxed use of the emergency path.
Answering an identity-resilience scenario by adding more detection rules, when the scenario describes an attacker who already holds valid credentials and therefore generates no authentication anomaly to detect.
Detection-centric thinking dominates security training, so candidates reach for alerting even when the premise is that the credential is legitimate; the correct answer usually concerns credential scope, session control, and recovery of the identity plane.
What to do instead
When the scenario states or implies valid-credential use, shift to containment and recovery controls: least-privilege scoping, short-lived tokens, token and session revocation, privileged access workstations, and a plan to rebuild trust in the directory rather than to detect the login.
Presenting a cyber recovery plan as complete without specifying the clean-room or isolated recovery environment, the integrity validation of restored data, and the decision authority for declaring a disaster.
Recovery plans are often memorized as ordered steps (detect, contain, restore, resume) and the governance and validation layers are omitted because they are not sequential technical actions.
What to do instead
For every recovery-plan question, confirm the option covers: an isolated recovery environment with separate credentials, malware and integrity scanning of restored artifacts before promotion, defined and pre-authorized decision roles, and explicit go/no-go criteria for returning to production.
Choosing to restore from the most recent backup by default in a cyber recovery scenario, without evaluating whether the most recent backup is itself compromised or was taken after the adversary established persistence.
Routine disaster recovery drills reward the newest restore point, and candidates carry that habit into ransomware scenarios where recency is a liability rather than an asset.
What to do instead
Establish a known-good restore point by correlating backup timestamps with the earliest evidence of compromise, then restore from before that point and verify integrity. State explicitly that the newest backup is a hypothesis, not a default.
Treating SaaS and cloud protection as automatically covered by the provider's shared-responsibility model, and omitting configuration backup, data export, and identity-level recovery for SaaS workloads.
The phrase 'the cloud provider handles availability' is widely repeated, so candidates assume SaaS data is backed up by the vendor and never ask who restores a deleted mailbox, a misconfigured retention policy, or an over-permissive OAuth grant.
What to do instead
For each SaaS or cloud workload, separate infrastructure availability (provider) from data protection, configuration state, and identity and permission recovery (customer). Verify the option includes independent backup of SaaS data and configuration, plus a path to revoke and restore integrations and OAuth grants.
Ignoring the resilience of the resilience tooling itself, such as a backup server, recovery orchestrator, or management console that shares credentials, network, or the same cloud account as production.
Candidates focus on protecting the workload and treat the protection infrastructure as trusted by definition, so they miss the scenario detail that the attacker reached the backup console through the same domain account.
What to do instead
Always test whether the proposed design gives the recovery plane its own identity, network path, and administrative boundary. If the option keeps backup administration inside the production identity domain or account, it fails the isolation test regardless of encryption.
Treating the agentic platform as a passive dashboard and answering administration questions without addressing agent permissions, autonomy boundaries, and human approval gates for recovery actions.
Candidates transfer habits from conventional monitoring tools where the operator performs every action, so they overlook that an autonomous agent can initiate containment or restore steps and therefore needs its own scoped authority and audit trail.
What to do instead
For platform administration questions, evaluate the option on four points: the agent's least-privilege role, the actions it may take autonomously versus those requiring approval, the logging and attribution of agent-initiated actions, and a tested kill switch or manual override.
Validating resilience only through tabletop discussion or a documented plan review, without a restore test that measures actual recovery time and data loss against the stated objectives.
Tabletop exercises are cheap and common, so candidates accept 'conducted a tabletop' as proof of recoverability and do not notice that the scenario asks for evidence the objectives are achievable.
What to do instead
Prefer options that include a real restore or failover test into an isolated environment, measurement of elapsed time and lost data against RPO and RTO, and a remediation loop that feeds the measured gaps back into the plan. Treat tabletops as a complement, never as the evidence.