CompTIA DataSys+ (DS0-001) Practice Test

Explanation

A hot standby site is a fully operational mirror of the production environment, with hardware, software, and current data maintained through real-time or near-real-time replication. Failover can be completed in seconds with minimal or no data loss. It is the most expensive option due to full resource duplication. A warm standby site has partial infrastructure in place — servers are installed and configured but may not have current data. It relies on periodic replication or log shipping, resulting in data lag. Failover requires additional steps such as applying pending logs, starting services, and verifying data integrity, taking minutes to hours. A warm site balances cost and recovery capability for systems with moderate RTO requirements. The distinction between hot and warm sites is about operational readiness and data currency, not about replication protocol technology — a warm site could use log shipping or periodic backup restoration, not necessarily tape. Site location (on-premises vs. cloud) does not define hot versus warm. Specific availability percentages are not the defining characteristic.

Explanation

Liquibase tracks applied changes in the DATABASECHANGELOG table, using changesets identified by unique author and ID combinations, supporting XML, YAML, JSON, and SQL formats. Flyway tracks migrations in the flyway_schema_history table, applying migration scripts in sequential order based on version numbers in the filename (e.g., V1__, V2__). Flyway is SQL-first and convention-driven, while Liquibase offers more format flexibility. Automatic rollback in Flyway requires the Enterprise edition.

Explanation

An RPO of zero means the organization cannot tolerate any data loss whatsoever. This requirement can only be satisfied by synchronous replication, in which every transaction must be committed on both the primary and the hot standby before the application receives an acknowledgment. This guarantees the secondary is always identical to the primary at the moment of failure. Paired with automated failover on a hot standby, the solution also meets the one-hour RTO and eliminates manual synchronization steps. Daily full backups with hourly transaction log backups cannot achieve zero data loss because up to one hour of transactions could be lost between log backup intervals. Restoring this chain also involves substantial manual effort and time. Log shipping with 10-minute intervals fails on two counts: it creates a potential data loss window equal to the shipping interval, which violates the zero data loss requirement, and it requires manual failover activation, which directly violates the requirement for automated activation without manual synchronization. Asynchronous replication to a hot standby with automated failover comes closest but is still insufficient. Asynchronous replication allows the primary to commit transactions and acknowledge them to the application before the secondary has confirmed receipt. Even a lag of a few seconds means transactions committed just before a failure event may not yet exist on the secondary, producing data loss. For a zero data loss requirement, any replication lag is unacceptable regardless of its typical magnitude.

Explanation

Using quantitative risk analysis formulas: Single Loss Expectancy (SLE) = Asset Value x Exposure Factor = $800,000 x 0.25 = $200,000. Annualized Loss Expectancy before countermeasure (ALE_before) = SLE x ARO = $200,000 x 4 = $800,000. After implementing the mitigation service: ALE_after = $200,000 x 1 = $200,000. Countermeasure value = ALE_before - ALE_after - Annual Cost = $800,000 - $200,000 - $50,000 = $550,000. The countermeasure delivers $600,000 in annual risk reduction for $50,000 in cost, producing a net positive value of $550,000. A countermeasure should be implemented whenever its value is positive, meaning the risk reduction exceeds the cost. The $200,000 figure incorrectly omits the countermeasure cost from the calculation. The negative value option is incorrect because the $50,000 annual cost is far less than the $600,000 in risk reduction achieved. The $150,000 figure results from applying an incorrect ARO reduction calculation.

Explanation

An emergency change is the correct classification for changes addressing critical, immediate threats to production systems. Emergency changes bypass the full CAB review cycle through an expedited ECAB (Emergency Change Advisory Board) fast-track process, allowing rapid approval with a smaller group of key stakeholders while still maintaining oversight and documentation. Standard changes are low-risk, routine, pre-approved changes that don't require CAB review — emergency hotfixes do not fall into this category. Normal changes require full CAB review with advance scheduling, which would take too long given the active production impact. Allowing the developer to apply changes without any approval process violates the principle of separation of duties and change management governance — proper oversight is required even in emergencies. Emergency change procedures exist precisely to handle urgent situations quickly while maintaining accountability and documentation requirements.