DOP-C02 Incident and Event Response Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Modify the DB instance to a larger instance class.

  Why it's wrong here

  Changing the DB instance class adjusts only the CPU, memory, and network throughput of the RDS instance; the allocated storage size is a separate, independently managed attribute. While a larger instance class can improve I/O performance for workloads constrained by compute, it does not add any free space to the underlying Amazon EBS volume or storage volume. This action also typically requires a reboot, which would cause a brief interruption, making it unsuitable for resolving a low-storage condition.

• ✓

  Modify the DB instance to increase the allocated storage.

  Why this is correct

  Modifying the DB instance to increase allocated storage is the correct approach because Amazon RDS for PostgreSQL supports dynamic storage scale-up without any downtime, provided the instance is in the 'Available' state and not in a pending reboot. You can increase storage either via the AWS Console, CLI, or API, and RDS immediately begins the modification while keeping the instance online. The new storage capacity is reflected after the modification is processed, and you can also enable storage autoscaling to prevent future low-storage alerts.

• ✗

  Create a snapshot of the DB instance and restore it with larger storage.

  Why it's wrong here

  Creating a snapshot and restoring it with a larger storage size is a valid but heavy-handed approach: it provisions a brand-new RDS instance from the snapshot, requiring the application connection strings to be updated and raising the risk of losing any transactions committed after the snapshot was taken, since a snapshot is not a live point-in-time copy. The original instance remains unchanged until you manually switch traffic, so this method introduces significant downtime and operational effort. It also doesn't leverage RDS's ability to modify storage in-place, making it an overengineered solution for simple capacity expansion.

• ✗

  Launch a new read replica with larger storage and promote it.

  Why it's wrong here

  Launching a new read replica with larger storage and promoting it is a multi-step disaster recovery/migration technique, not a storage scaling operation. While you can create a read replica with a different allocated storage size for PostgreSQL, the replica must continuously sync from the primary, and on promotion you must redirect application traffic, potentially losing any data not yet replicated and incurring downtime during the promotion and DNS cutover. The read replica would also need to be in the same architecture and maintain the same storage type, but the original instance's storage pressure is not relieved until the cutover is complete, making it excessive and riskier than a simple storage modification.

Go deeper

Related to this question