security-disaster-recovery practice questions

The backup server is powered off.

Why it fails: If the server were off, the error message would indicate that the network path could not be found or the host is unreachable, not an 'Access is denied' error.

The network link is down.

Why it fails: A down network link would result in a connectivity error like 'Network path not found', not an access denial.

The backup file path exceeds the maximum length.

Why it fails: A path too long would trigger a specific error about file name or path length limits, not an access denied message.

Implement SSH key authentication only.

Why it fails: SSH keys strengthen authentication against password guessing but do not meet the multifactor requirement, as the key itself is a single factor.

Use SSH with public key authentication and install fail2ban.

Why it fails: This combination improves resistance to brute-force attacks but still lacks the mandatory second factor of authentication.

Enable RDP with network-level authentication.

Why it fails: RDP is not typically considered secure for server administration without additional protections, and NLA is a single-factor authentication method.

Buy a second external drive, alternate them, and keep one offsite at the owner’s house, rotating weekly.

Why it fails: A weekly rotation means the offsite drive contains data up to seven days old, which exceeds the one-day RPO, leading to unacceptable data loss in a disaster.

Purchase a network-attached storage device and configure it to receive daily backups; place it in a different room in the building.

Why it fails: An on-site NAS remains vulnerable to the same physical disaster (fire), so it does not provide offsite protection and data could still be lost.

Subscribe to a cloud backup service and perform daily incremental backups over the internet.

Why it fails: The firm's limited DSL bandwidth would make cloud backups slow and possibly fail to complete within the backup window; also, cloud services introduce recurring costs and complexity beyond their budget and skillset.

Pay the ransom demand to obtain the decryption key and decrypt both sites.

Why it fails: Paying ransoms encourages further attacks, provides no guarantee the key will work, and violates many regulatory and ethical standards for healthcare organizations.

Restore the most recent tape backup to the primary site and re-enable replication.

Why it fails: Restoring directly to the primary without first wiping the secondary could lead to re-encryption if the ransomware is not fully eradicated, and replication would propagate the encrypted data again.

Fail over to the secondary data center and attempt to decrypt the ransomware using available tools.

Why it fails: Modern ransomware typically uses strong encryption that cannot be broken without the key; publicly available tools rarely succeed, so this approach almost certainly fails to restore data.

The backup destination disk is full

Why it fails: A full destination disk produces a write or insufficient-space error at the point of data transfer, not the failure shown in the log. It is tempting because capacity exhaustion is a frequent cause of failed backups, and would be correct if the log recorded a disk-full or quota-exceeded message rather than the exhibited error.

The network share is offline

Why it fails: An offline network share would produce a connection or host-unreachable error, not the specific failure recorded in the log. It is tempting because unreachable backup destinations are a common cause of nightly job failures, and would be correct if the log showed a timeout or name-resolution error rather than the exhibited message.

The backup software is not installed

Why it fails: If the backup software were not installed, no job would have been scheduled or logged at all, so the exhibited error could not appear. It is tempting because missing agents do break backup jobs, and would be correct if the log showed an unrecognised command or missing executable rather than the exhibited failure.

Increase backup frequency to every hour and store the drive in a desk drawer in a different room on the same floor.

Why it fails: More frequent backups reduce data loss but still store the only backup copy on-site, so a building-level disaster would destroy both production data and backups.

Purchase a fireproof safe for the server room and store the USB backup drive in it after each backup.

Why it fails: While this reduces fire risk, it does not protect against other perils (e.g., flood, theft) and still leaves the backup on-site. The 3-2-1 rule requires at least one off-site copy.

Install a second server on-site and configure real-time mirroring between the two servers.

Why it fails: This provides hardware redundancy but does not protect against site-wide disasters (fire, flood, theft). It also requires significant investment in new hardware and ongoing maintenance, which is not cost-effective for the firm.

Rebuild all database servers from scratch and restore file servers from the most recent off-site tapes, accepting 11 days of data loss for file servers too.

Why it fails: This ignores the off-site tapes that contain database backups from 11 days ago. Rebuilding from scratch causes unnecessary additional downtime and data loss when backups are available.

Attempt to restore the databases from the replicated SAN by breaking replication and scanning for uncorrupted blocks.

Why it fails: The synchronous replication caused the standby SAN to be encrypted simultaneously, so the data is already compromised. Unless a known clean snapshot exists, this data is unusable.

Pay the ransom demand to the attackers in hopes of receiving the decryption key.

Why it fails: Paying ransom does not guarantee recovery, may fund criminal activity, and often violates organizational policy or regulatory requirements. It should not be the first course of action.

Install a serial cable from the UPS to one server and configure that server to broadcast a shutdown command to the others.

Why it fails: A single serial connection only provides status to one server. Broadcasting a shutdown command from that server is not a native UPS feature and would require custom scripting, which is less reliable and not the standard method for multi-server UPS coordination.

Connect each server's power supply directly to the UPS and enable the UPS's built-in shutdown software on the management card.

Why it fails: The management card does not automatically install or execute shutdown software on the servers. Each server still needs a local agent or a network-based shutdown trigger, so simply connecting power and enabling a card feature will not initiate graceful shutdown.

Configure the servers' BIOS to shut down when AC power is lost, and rely on the UPS to provide runtime until the BIOS timer expires.

Why it fails: BIOS power-loss settings typically control behavior after power is restored, not a graceful shutdown at a specific battery level. Relying on a BIOS timer would not coordinate with the UPS battery state and could cause abrupt power loss.

Incremental backup

Why it fails: Incremental backups only capture changes since the last backup of any type, which reduces backup time, but restoring a single file may require the last full backup plus every subsequent incremental backup, increasing restore complexity and time. It does not inherently provide faster single-file restores than other methods.

Full backup

Why it fails: A full backup captures the entire 2 TB dataset every night, which may exceed the 4-hour window depending on throughput, and restoring a single file still requires mounting the full backup set. It does not optimize for single-file restores beyond what any backup type provides, and it consumes maximum storage and time.

Differential backup

Why it fails: Differential backups capture all changes since the last full backup, so they grow larger each day and may eventually exceed the 4-hour window. Restoring a single file requires the last full backup plus the latest differential, which is more complex than a single backup set and does not meet the requirement for independent file restores.

Weekly full backups with daily differential backups

Why it fails: Daily differential backups leave up to 24 hours of data unprotected, far exceeding the 15-minute RPO. Even though the restore process is relatively simple, the strategy cannot meet the required recovery point, so it is unacceptable for this database.

Continuous replication to a secondary server with no local backups

Why it fails: Continuous replication can meet a 15-minute RPO, but eliminating local backups removes protection against logical corruption, accidental deletion, or ransomware that replicates to the secondary. It also complicates point-in-time recovery, so it does not best meet the combined RPO, storage, and restore requirements.

Daily full backups with hourly transaction log backups

Why it fails: Hourly transaction log backups leave up to 60 minutes of data at risk, which still violates the 15-minute RPO. A full backup every day also consumes significant storage and I/O, making this approach both non-compliant and unnecessarily heavy.

Tabletop exercise

Why it fails: A tabletop exercise is a discussion-based walkthrough of the DR plan with key stakeholders. It does not involve actual failover or running workloads at the DR site, so it cannot validate that systems will function when brought online. It is useful for identifying plan gaps and improving communication, but it does not meet the requirement of actual failover testing with production workloads.

Simulation test

Why it fails: A simulation test typically involves walking through the steps of a failover without actually bringing systems online, or performing a limited failover of non-critical components. It does not run production workloads at the DR site, so it cannot fully validate the DR environment. While it is less disruptive than a full failover, it falls short of the requirement to test actual failover with production workloads.

Parallel test

Why it fails: A parallel test involves bringing up the DR site and running systems there while the primary site continues to operate, but it usually does not process actual production transactions or data. It is often used to validate that the DR environment can function without affecting the primary site. However, because it does not run production workloads, it does not fully meet the requirement of testing actual failover with production workloads.

Full backup

Why it fails: A full backup captures the entire database but requires significant time and storage, extending the backup window. While it ensures consistency, it does not minimize window time. For a small business with limited resources, full backups daily may be impractical. The scenario asks for minimizing window time, so a full backup is not the best fit.

Incremental backup

Why it fails: An incremental backup captures only changes since the last backup of any type. It minimizes backup window and storage, but restoring requires the last full backup plus all incrementals. For a database, applying incrementals may not guarantee transactional consistency unless the database is quiesced or uses its own log shipping. This can complicate restoration.

Differential backup

Why it fails: A differential backup captures all changes since the last full backup. It grows over time, potentially increasing backup window as the week progresses. It also requires a full backup as a base. While it reduces restore complexity, it does not inherently minimize the backup window compared to other methods, especially if the database changes frequently.

Bollard

Why it fails: A bollard is a short, sturdy vertical post installed to prevent vehicles from entering a pedestrian or building area. It is a perimeter control used outdoors or at loading docks and does not stop a person from following an authorized employee through an interior door. Because the scenario specifically involves unauthorized entry through a secure door, bollards do not address the tailgating risk and are the wrong control type.

Camera

Why it fails: A camera provides surveillance and can record evidence of tailgating, but it does not physically prevent an unauthorized person from entering behind an employee. It is a detective control, not a preventive one. While cameras are valuable for monitoring and investigations, the requirement is to stop the unauthorized entry in real time, which a camera alone cannot do. Therefore, it does not satisfy the stated need.

Access control vestibule

Why it fails: The term access control vestibule is often used as a synonym for a mantrap, but in this question the intended correct control is the mantrap. If both appeared, the exam expects the specific term that describes the interlocking-door design. Since a mantrap is the precise answer and the vestibule option is a distractor, the mantrap is the best choice. The vestibule option may be considered a less precise or duplicate term here.

iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT; iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT -j DROP; service iptables save

Why it fails: The rule order is acceptable, but 'service iptables save' is not available on all modern Linux distributions and may fail silently, leaving the rules non-persistent. The scenario requires the policy to be applied immediately and persistently; relying on a service script that may not exist does not guarantee persistence. The correct method uses iptables-save to a known configuration file.

iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT; iptables -A INPUT -j REJECT; iptables-save > /etc/iptables/rules.v4

Why it fails: Using REJECT instead of DROP sends an ICMP error or TCP reset back to the sender, which reveals that the host is present and may be undesirable for a hardened public server. While REJECT is sometimes preferred for internal networks, the requirement to block all other inbound traffic is better met with DROP to avoid information disclosure. The rest of the rule set is correct, but the final action is not ideal.

iptables -A INPUT -p tcp --dport 443 -j ACCEPT; iptables -A INPUT -p tcp --dport 22 -j ACCEPT; iptables -A INPUT -s 192.168.10.0/24 -j DROP; iptables -A INPUT -j DROP; iptables-save > /etc/iptables/rules.v4

Why it fails: This configuration accepts SSH from any source because the SSH rule does not specify a source subnet, and it adds a DROP rule for the management subnet, which blocks management traffic entirely. The requirement is to allow SSH only from 192.168.10.0/24, so this policy is incorrect and would prevent legitimate administrative access.

Run sudo ufw deny 22/tcp to block all SSH traffic, then configure a non-standard port for SSH access.

Why it fails: Blocking port 22 with ufw would prevent all SSH access, including legitimate administrative connections, which is not the goal. Changing the SSH port may reduce automated scanning but does not address brute-force attempts on the service itself. This action would disrupt management access and fail to meet the requirement of limiting authentication attempts and disabling root login.

Modify /etc/pam.d/sshd to include pam_tally2.so deny=3 and set root login to disabled in /etc/passwd.

Why it fails: While pam_tally2 can limit failed attempts, it is deprecated in newer Ubuntu versions and does not disable root SSH login. Editing /etc/passwd to disable root login is ineffective because SSH root access is controlled by sshd_config. This approach is overly complex and does not directly satisfy the requirements, potentially causing authentication issues.

Install and configure fail2ban to monitor SSH logs and ban IP addresses after three failed attempts, and set PermitRootLogin to no in /etc/ssh/sshd_config.

Why it fails: Fail2ban is an intrusion prevention tool that bans IPs after repeated failures, but it does not limit authentication attempts per connection (MaxAuthTries) nor does it directly disable root login. While it complements SSH hardening, the requirement specifically asks for limiting authentication attempts and disabling root login, which are better addressed by sshd_config settings. This option adds complexity without fully meeting the stated goals.

Enable root login over SSH to simplify administrative tasks.

Why it fails: Allowing direct root login over SSH is a significant security risk. If an attacker gains root credentials, they have full control of the server. Best practice is to disable root login and use sudo from a regular user account, which provides auditing and limits damage from compromised accounts.

Install a host-based intrusion detection system (HIDS) to monitor file integrity.

Why it fails: A HIDS can detect changes to critical files and alert on suspicious activity, but it is a detective control, not a preventive one. It does not reduce the attack surface or block unauthorized SSH access. While valuable for defense in depth, it does not directly address the SSH exposure described.

Change the SSH default port from 22 to a non-standard port.

Why it fails: Changing the SSH port reduces noise from automated scanners but does not provide real security. Attackers can easily discover the new port with a port scan. It is security through obscurity and does not address the underlying authentication weakness or unauthorized access.

Perform a cryptographic erase by destroying the drive's internal encryption key, then verify the drive reports as unreadable before resale.

Why it fails: Cryptographic erase is valid only when the drive self-encrypts all user data with an internal key, and destroying that key renders the data unrecoverable. However, the scenario does not state the drives are self-encrypting, so assuming this capability is unsafe. Without confirmed hardware encryption, the data may remain readable, making this method unreliable for a mandatory sanitization policy.

Degauss each drive with a strong magnetic field before handing the drives to the reseller.

Why it fails: Degaussing destroys the magnetic servo tracks that a hard drive needs to operate, so the drives become unusable and cannot be resold. It also does not reliably sanitize solid-state drives, which store data in flash cells rather than magnetic media. This satisfies destruction but fails the resale requirement, and mixed media would not be uniformly handled.

Run a single-pass overwrite on each drive using the vendor's disk utility, then ship the drives to the reseller.

Why it fails: A single-pass overwrite is a logical sanitization method that can leave remapped sectors and vendor-reserved areas untouched, so remnants of cardholder data may survive on a drive that stores sensitive data. Because the drives leave the organization's control, this method does not meet a strict no-recoverable-data policy, and the reseller could still recover residual blocks.

Cold site with nightly backups and manual restore

Why it fails: A cold site has infrastructure but no pre-installed software or data. Restoring from nightly backups and manually installing and configuring the application would take far longer than 1 hour. This approach also risks significant data loss because backups are only nightly. It does not meet the low RTO and minimal data loss requirements.

Mobile site with trailers and generators

Why it fails: A mobile site consists of trailers with hardware that can be transported to a location. It requires setup time and is typically used when a permanent alternate site is not available. Bringing it online within 1 hour is unrealistic, and it does not inherently provide data replication, so it cannot meet the minimal data loss requirement.

Hot site with real-time replication and automatic failover

Why it fails: A hot site provides near-zero downtime and data loss, but it is significantly more expensive to maintain. While it would meet the RTO, the scenario does not indicate that the company requires or can justify the cost of a hot site. A warm site is sufficient for a 1-hour RTO with minimal data loss and is more cost-effective.

Database mirroring in high-safety mode with automatic failover

Why it fails: Database mirroring is deprecated in favor of Always On availability groups. While high-safety mode is synchronous and can meet RPO/RTO, it is not the recommended technology for new deployments. The scenario likely expects a current, supported solution, making Always On the better choice.

Always On availability groups with asynchronous commit and automatic failover

Why it fails: Asynchronous commit can result in data loss if a failover occurs before the secondary receives all transactions, potentially exceeding the 15-minute RPO. Also, automatic failover requires synchronous commit mode. Asynchronous mode is typically used for disaster recovery across distant sites, but it does not guarantee the low RPO required here without additional measures.

Daily full backups and hourly transaction log backups

Why it fails: Hourly transaction log backups would result in an RPO of up to 1 hour, which exceeds the 15-minute requirement. Daily full backups are fine for baseline, but the log backup frequency is insufficient. This approach would likely lose up to 60 minutes of data, violating the RPO.

Install a camera above the door that records continuously and store the footage for 24 hours.

Why it fails: A camera can help investigate an incident after the fact, but it does not prevent tailgating in real time and a 24-hour retention window is too short for most audit requirements. This option is a detective control only, and the question asks for prevention of unauthorized entry plus a reliable record of entry attempts.

Deploy a mantrap with two interlocking doors that requires a badge at both doors.

Why it fails: A mantrap is an effective physical control that prevents tailgating by allowing only one person through at a time, and it can log entries. However, it is significantly more expensive and disruptive to install than a badge reader with tailgating detection, and the scenario does not indicate that the budget or space justifies a full mantrap. The badge reader with logging meets the stated requirements more proportionally.

Replace the door lock with a mechanical keyed lock and issue keys only to authorized staff.

Why it fails: A mechanical keyed lock does not detect or prevent tailgating, and it produces no electronic audit trail of who entered and when. Keys can also be copied without accountability. This option may restrict access to some degree but fails the requirement to record entry attempts and to prevent someone from following an authorized person through the door.