CLF-C02 Security and Compliance 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.

• ✓

  Enable automatic backups on the source DB instance, then create the read replica in the target region, then wait for the replica to be created and synchronized, then optionally promote the replica to a standalone DB instance.

  Why this is correct

  This order is correct because automatic backups must be enabled on the source before creating a cross-region read replica. After initiating the replica creation, you must wait for it to complete and synchronize. Promotion is an optional final step to make the replica a standalone database.

• ✗

  Create the read replica in the target region, then enable automatic backups on the source DB instance, then wait for the replica to be created and synchronized, then optionally promote the replica to a standalone DB instance.

  Why it's wrong here

  A cross-region read replica cannot be initiated unless the source DB instance has automatic backups enabled, because Amazon RDS uses the source's backup retention period and transaction logs to bootstrap and stream changes to the replica in the target region. Attempting to create the replica first will fail with an error indicating that backup retention must be set above zero. Enabling backups after the fact is not a valid remedy because the replica creation call needs those backups to exist at the moment the replica is instantiated.

• ✗

  Enable automatic backups on the source DB instance, then wait for the replica to be created and synchronized, then create the read replica in the target region, then optionally promote the replica to a standalone DB instance.

  Why it's wrong here

  After enabling automatic backups on the source, the next required action is to issue the CreateDBInstanceReadReplica request by specifying the source DB instance and the destination AWS Region; until that creation request exists, there is no replica to wait for. The wait-for-sync step is a monitoring phase that only applies once the replica's lifecycle status has progressed to 'replicating' and replica lag has reached zero. Inserting the wait before the create operation causes the process to stall or poll a resource that has never been provisioned, so this sequence cannot complete.

• ✗

  Create the read replica in the target region, then wait for the replica to be created and synchronized, then enable automatic backups on the source DB instance, then optionally promote the replica to a standalone DB instance.

  Why it's wrong here

  This ordering starts with replica creation and ends with enabling automatic backups on the source, invert the hard prerequisite: automatic backups must be enabled on the source before the CreateDBInstanceReadReplica call in the target region can succeed. It then waits for synchronization before backups are enabled, which is impossible because the replica's initial data load and ongoing replication are driven by the source's backup and transaction-log pipeline from the very first moment. Setting backups only after the wait does not retroactively authorize the replication channel, making the entire sequence invalid.

Go deeper

Related to this question