Back to CompTIA DataSys+ (DataSys+)

Business Continuity

Prepare for incidents with backup and recovery strategies, high availability implementations, and risk assessment (12% of exam).

Covers creating disaster recovery plans, replication strategies, and failover processes for backup and recovery. Includes implementing clustering, load balancing, and system redundancy for high availability. Also covers conducting impact analysis, risk mitigation, and continuity testing for risk assessment.
5 minutes 5 Questions

In the context of the CompTIA DataSys+ certification, Business Continuity (BC) is a critical domain focusing on an organization's ability to maintain essential data operations and services during and after a disruptive incident. Unlike Disaster Recovery (DR), which is reactive and focuses specifica…

Concepts covered: Disaster recovery planning, Backup strategies, Full backups, Incremental backups, Differential backups, Replication strategies, Synchronous replication, Asynchronous replication, Failover processes, Recovery Time Objective (RTO), Recovery Point Objective (RPO), Point-in-time recovery, Database restore procedures, Backup verification and testing, Database clustering, Load balancing for databases, System redundancy, Active-passive configurations, Active-active configurations, Automatic failover, Database mirroring, Always On availability groups, Geographic redundancy, Business impact analysis, Risk mitigation strategies, Continuity testing, Disaster recovery drills, Single points of failure identification, Service level agreements (SLAs), Incident response for databases, Business continuity documentation

Test mode:
Start practice test
DataSys+ - Business Continuity Example Questions

Test your knowledge of Business Continuity

Question 1

A transportation company operates a MongoDB sharded cluster with 6 shards storing real-time vehicle telemetry data across 280 million documents. On Friday at 11:18 AM, the operations team discovers that a configuration change deployed at 9:42 AM has been writing incorrect GPS coordinate data to the VEHICLE_LOCATIONS collection, compromising approximately 3.2 million location records across shards 2, 4, and 6. The cluster uses oplog-based backup with mongodump snapshots captured every 4 hours (most recent at 8:00 AM Friday) and complete oplog entries preserved from 6:00 AM through 11:20 AM Friday. Between 9:42 AM and 11:18 AM, dispatchers manually updated 847 vehicle assignments and drivers submitted 412 delivery confirmation records that fleet managers have already validated for payroll processing and must be retained. The cluster operates with write concern majority and read preference primary-preferred. The application maintains referential links between collections VEHICLE_LOCATIONS, DRIVER_ASSIGNMENTS, and DELIVERY_CONFIRMATIONS through vehicle_id fields. Business requirements mandate that all valid dispatcher actions and driver confirmations remain intact while corrupted GPS data is eliminated. Which recovery methodology should the database administrator execute to remediate the coordinate corruption while preserving operational data integrity across the sharded environment?

Correct Answer: Restore the 8:00 AM mongodump snapshot to a temporary staging cluster, replay oplog entries from 8:00 AM to 9:41 AM to the staging environment, then selectively export DRIVER_ASSIGNMENTS and DELIVERY_CONFIRMATIONS documents created between 9:42 AM and 11:18 AM from production, merge these validated documents into the staging cluster, verify referential consistency across vehicle_id links, and perform a rolling shard replacement starting with shards 2, 4, and 6

The correct recovery approach involves restoring the 8:00 AM snapshot to a staging cluster, replaying oplog to 9:41 AM (just before corruption), selectively exporting the valid operational data from production, merging it into staging, and performing a rolling shard replacement starting with the affected shards.

This is the optimal solution because:

  1. Point-in-time Recovery: Restoring to 8:00 AM and replaying oplog to 9:41 AM creates a clean state immediately before the corruption began, eliminating all bad GPS data.

  2. Preservation of Valid Data: By selectively exporting DRIVER_ASSIGNMENTS and DELIVERY_CONFIRMATIONS created between 9:42 AM and 11:18 AM from production, we retain the 847 dispatcher actions and 412 delivery confirmations that must be preserved for payroll.

  3. Rolling Shard Replacement: This approach minimizes downtime by replacing only the affected shards (2, 4, and 6) first, maintaining cluster availability. The rolling replacement allows the cluster to remain operational during remediation.

  4. Referential Integrity: The verification of vehicle_id links ensures data consistency across collections before deployment.

  5. Targeted Remediation: Only affected shards are replaced, reducing the scope of impact and recovery time.

Why the other approaches are problematic:

Complete Cluster Replacement with Shutdown: While this approach follows similar recovery steps, requiring a complete shutdown and atomic cluster replacement is unnecessarily disruptive. The sharded architecture allows for rolling replacements that maintain availability. Shutting down all connections causes unnecessary business disruption when only 3 of 6 shards contain corrupted data.

Selective Deletion with Chunk Migration: This approach is fundamentally flawed because it attempts to delete corrupted records and rely on chunk migration to repopulate GPS data from unaffected shards. However, VEHICLE_LOCATIONS data is not replicated across shards—each shard contains unique location records based on the shard key. Chunk migration moves existing data, it doesn't recreate deleted records. This would result in permanent data loss of 3.2 million location records from the affected time period.

Parallel Cluster with DNS Failover: While technically viable, this approach treats the recovery as a complete disaster recovery scenario requiring infrastructure duplication and DNS-based traffic redirection. This is overly complex for what is essentially a data corruption issue affecting specific shards. The DNS failover approach adds unnecessary complexity, potential for routing issues, and doesn't leverage MongoDB's native shard replacement capabilities. Additionally, maintaining a parallel cluster environment requires double the resources when a targeted shard replacement would suffice.

Question 2

A regional credit union operates a Microsoft SQL Server 2019 database using the FULL recovery model for their loan servicing platform. On Tuesday at 3:47 PM, database monitoring detects severe performance degradation traced to an erroneous UPDATE statement executed at 3:12 PM that modified interest rate calculations across approximately 67,000 active loan records in the LOAN_ACCOUNTS table. The DBA has these backup resources available: a full database backup completed Tuesday at 12:00 AM, differential backups captured at 8:00 AM and 2:00 PM Tuesday, transaction log backups executing every 15 minutes with the most recent at 3:45 PM Tuesday, and a database snapshot created Monday at 11:00 PM for reporting purposes. Between 2:00 PM and 3:47 PM Tuesday, loan officers processed 156 new loan originations, members made 892 payment transactions that have been transmitted to the general ledger system, and the collections department updated 234 delinquent account statuses that triggered automated compliance notifications to state regulators. The loan servicing platform maintains strict audit requirements mandating preservation of all payment activities and regulatory communications. The database contains 127 tables with cascading triggers across loan accounts, payment history, and compliance tracking modules. Management requires the system restored for end-of-day settlement processing beginning at 6:00 PM. Which restoration strategy should the database administrator employ to reverse the erroneous interest rate modifications while maintaining all legitimate loan servicing activities and regulatory audit trail integrity?

Correct Answer: Restore the 12:00 AM full backup and 2:00 PM differential backup to a secondary staging server, then apply transaction logs with STOPAT clause specifying 3:11 PM Tuesday to establish a recovery point preceding the erroneous update, export the corrected LOAN_ACCOUNTS table data, and merge the extracted records into the production database using MERGE statements that preserve payment transactions and account status modifications occurring after 3:12 PM by correlating transaction timestamps with application audit logs

The optimal restoration strategy in this scenario requires a surgical approach that corrects the erroneous data while preserving all legitimate transactions that occurred after the error.

The correct approach involves:
1. Creating an isolated recovery environment on a secondary staging server to avoid disrupting production operations
2. Restoring the 12:00 AM full backup followed by the 2:00 PM differential backup (which is the most recent differential before the error)
3. Applying transaction logs with a STOPAT clause set to 3:11 PM - one minute before the erroneous UPDATE at 3:12 PM
4. Extracting the corrected LOAN_ACCOUNTS table data from this clean recovery point
5. Using MERGE statements to intelligently integrate the corrected interest rate data back into production while preserving all legitimate activities (156 loan originations, 892 payments, 234 status updates) that occurred between 3:12 PM and 3:47 PM

This approach is superior because:
- It maintains complete audit trail integrity by preserving all legitimate transactions
- It avoids the complexity and risk of manual reconciliation
- It keeps production online while performing recovery operations on a separate server
- The MERGE operation can be precisely controlled to update only the corrupted interest rate fields while maintaining payment and status data
- It meets the 6:00 PM deadline by avoiding time-consuming full restoration and manual data entry

Why the other approaches are problematic:

Reverting to Monday's snapshot would require replaying approximately 24 hours of transaction logs and would necessitate extensive manual reconciliation of business-critical transactions. This approach is extremely time-consuming, error-prone, and unlikely to meet the 6:00 PM deadline. The snapshot is also too old to be practical given the volume of intervening transactions.

Restoring differentials sequentially (both 8:00 AM and 2:00 PM) is technically incorrect - you only restore the most recent differential backup, not multiple differentials in sequence. SQL Server differential backups are cumulative from the last full backup. Additionally, using WITH RECOVERY prematurely would prevent applying subsequent transaction logs, and CHECKSUM validation across 127 tables with cascading triggers would be extremely time-consuming.

Executing a tail-log backup is good practice, but the proposed approach has several critical flaws: using REPLACE option on production is unnecessarily risky, applying only the 8:00 AM differential misses critical data from the 2:00 PM differential, CONTINUE_AFTER_ERROR is inappropriate for this scenario and could lead to data corruption, and most importantly, Change Data Capture (CDC) must be explicitly enabled beforehand - it's not automatically available. Relying on CDC without prior configuration makes this approach infeasible. Additionally, restoring directly to production without testing creates unacceptable risk for a financial institution.

The correct strategy balances technical precision, business continuity, regulatory compliance, and time constraints while minimizing risk to production operations.

Question 3

You are the database administrator for a pharmaceutical research company running PostgreSQL 16.1 for their clinical trial data management system. On Monday at 3:28 PM, a data anonymization script containing a flawed regular expression pattern executed an UPDATE statement that corrupted patient identifier linkage codes for 9,400 participant records in the ClinicalParticipants table, replacing proper encrypted identifiers with malformed hash values that break the connection to medical history records. The research coordinator detected the corruption at 4:02 PM when attempting to generate patient enrollment reports for an FDA audit scheduled in 48 hours. Your backup configuration includes: pg_basebackup full database backups performed nightly at 1:30 AM with proper checkpoint coordination, Write-Ahead Log (WAL) continuous archiving enabled with wal_level configured to logical for replication support, WAL segments archived every 16MB to WORM-compliant storage meeting 21 CFR Part 11 requirements with a 7-year retention policy mandated by FDA regulations, and archive_command executing with proper error handling and retry logic. At 3:35 PM, the adverse event reporting system successfully recorded 12 serious adverse events from monitoring sites across four countries, creating safety signal documentation that ICH-GCP guidelines and regulatory authorities require to be preserved in the permanent trial master file for subject protection. At 3:49 PM, the drug accountability system processed investigational product dispensing records for 156 study visits, establishing chain-of-custody documentation that GMP auditors require to verify proper handling of controlled investigational medicinal products. At 3:56 PM, the electronic data capture system received and validated laboratory test results for 203 participants from the central reference laboratory, generating source data verification records that study monitors need for quality assurance procedures. The clinical operations director requires the participant linkage system restored by 5:30 PM to maintain the study timeline and avoid protocol deviations that could jeopardize the $47 million trial investment. Which recovery strategy should you implement to restore the ClinicalParticipants table to its condition at 3:27 PM while preserving all subsequent safety reporting, drug accountability, and laboratory data management operations?

Correct Answer: Restore the most recent pg_basebackup from 1:30 AM, then apply archived WAL segments up to the timestamp of 3:27 PM using recovery_target_time parameter, verify the restoration using pg_waldump to confirm transaction consistency, and finally apply forward recovery by selectively replaying WAL segments containing the adverse event, drug accountability, and laboratory transactions after 3:27 PM using logical decoding to extract and reapply specific committed transactions

The correct recovery strategy involves restoring from the 1:30 AM pg_basebackup, applying archived WAL segments up to 3:27 PM using recovery_target_time, and then using logical decoding to selectively extract and reapply specific transactions that occurred after 3:27 PM.

This approach is optimal because:

  1. Point-in-Time Recovery (PITR): Using recovery_target_time='3:27 PM' restores the database to the exact moment before the corrupted UPDATE statement executed at 3:28 PM, preserving the correct participant linkage codes.

  2. WAL Replay Foundation: PostgreSQL's WAL architecture with wal_level=logical provides the necessary infrastructure for both PITR and logical decoding operations.

  3. Selective Transaction Recovery: Logical decoding allows extraction of specific committed transactions (adverse events at 3:35 PM, drug accountability at 3:49 PM, laboratory results at 3:56 PM) from WAL segments after the 3:27 PM recovery point, enabling surgical reapplication without including the corrupted data.

  4. Data Integrity Preservation: This method maintains the atomicity and consistency of all legitimate transactions while excluding only the problematic UPDATE statement.

  5. Regulatory Compliance: All safety-critical data required by FDA, ICH-GCP, and GMP regulations is preserved without manual reconstruction, maintaining audit trail integrity.

  6. Verification Capability: Using pg_waldump confirms transaction consistency and provides auditable evidence of the recovery process.

The other approaches have critical flaws:

One alternative suggests using recovery_target_lsn with manual re-entry of data from paper documents. This is problematic because manual data re-entry introduces transcription errors, breaks the electronic audit trail required by 21 CFR Part 11, creates data integrity concerns for regulatory audits, and is time-prohibitive given the 5:30 PM deadline with 367 records to reconstruct.

Another option proposes table-level restore with recovery_target_xid and middleware cache reconstruction. This fails because pg_restore from pg_basebackup doesn't support granular table-level restoration (it's for pg_dump archives), recovery_target_xid requires knowing the exact transaction ID which isn't readily available from pg_stat_activity historical data, pg_rewind is for diverged replication scenarios not PITR operations, and relying on application-tier caches assumes functionality that may not exist and wouldn't meet regulatory documentation standards.

The final alternative uses recovery_target_name with CSV imports from application server transaction logs. This approach is flawed because restore points must be created proactively before the incident (none existed at 3:27 PM), parallel WAL processing isn't a standard PostgreSQL recovery feature, assuming a 4-hour application cache exists is speculative and unreliable, and CSV imports from application logs wouldn't maintain the cryptographic integrity and audit trails required for clinical trial data under FDA regulations.

More Business Continuity questions
913 questions (total)
Start 100 question test