This problem is poorly formulated. However, as presented, I’ve reasoned that (C) configure geo-redundancy (GR) is the BEST choice.

Its geo-redundancy according to the cloud essentials book: Geo-redundant storage keeps copies of data in different regions, which is resilient against a regional disaster.

Question Says: "Little or No Downtime" in case of Disaster. Can we consider "Availability Zones" instead of "Geo Redundancy" as the downtime is less in AZ?

For natural disasters Geo Redundancy is the only answer that is correct. AWS or Azure keep their Availability zones in close proximity to each other. They never publish how far the distance between AZ's but 2ms latency between them network wise. From everything I've read they are in the same metro area.

1. Sufficient for DR purposes – Both employ replication that INFORMALLY provides a basis for DR, however, this raises a huge best-practice caution: operational replication is NOT a substitute for backups! By current best-practice DR planning, we would restore from a valid, verified backup. 2. Effective for “natural disaster” events – GR’s wider geographic replication is superior to AZ’s replication among geographically “close” data centers. Indeed, where a single natural disaster incapacitates an entire AZ, a GR configured service may not even experience downtime! 3. Effective in achieving low RTO (i.e., “little to no downtime”) – AZ’s performance advantage over GR is lower latency for synchronous (vs. asynchronous) replication. However, this is an operational advantage. Per #1, we would restore from the most recent validated and verified backup(s). As such, operational latency does not factor into DR performance.

We may eliminate (B) Configure high availability and (D) Configure auto-scaling (A-S) right away, as both concern operational state rather than DR. Now, let’s consider remaining options: (A) configure AZs and (C) configure GR.

Option B is correct.