Simulado Google Cloud Professional Cloud Architect

A regional outage requires data and recovery capability in a second region. A cross-region read replica continuously streams changes, keeping replication lag well under the 5-minute RPO, and promoting it is fast enough to meet a 30-minute RTO; point-in-time recovery adds protection against logical corruption. The regional (HA) configuration only provides a standby in another zone of the same region, so it does nothing for a full us-central1 outage and fails the regional-failure requirement entirely. Hourly backups violate the 5-minute RPO outright because up to an hour of data could be lost, and restoring a full database into a new instance is unlikely to fit a 30-minute RTO. The 5-minute export/import scheme appears to chase the RPO but full logical exports do not run cleanly every 5 minutes on a transactional database, importing a full dump is slow, and the approach is operationally fragile compared to native replication, so it reliably meets neither objective.

The compute.vmExternalIpAccess organization policy constraint is a list constraint specifically designed to govern which VM instances may have external IPs; applied at the folder and set to deny all, it is inherited by every project beneath the folder and is enforced even against project owners, with no per-project firewall work. This is the correct preventive guardrail. A deny-all-egress firewall rule in each project would break legitimate outbound traffic, must be configured per project (the requirement explicitly forbids that), and does not actually prevent a VM from being created with an external IP. Removing the Compute Network Admin role does not stop external IP assignment because creating a VM with an external IP only requires the compute instance create permission, not network admin, and project owners would retain the ability anyway. A Cloud Function that deletes offending VMs is reactive — the VM briefly exists with a public IP before deletion, leaving an exposure window — and is brittle compared to a policy that prevents creation outright.

Replatforming (sometimes called lift-and-optimize) is the strategy that makes targeted changes to gain cloud benefits without a full rewrite: containerizing the stateless web tier onto GKE delivers auto-scaling and managed infrastructure, while moving the relational database to Cloud SQL reduces operational overhead, all while keeping the core application logic largely intact, which matches the stated goal of accepting moderate change. A pure rehost onto one large Compute Engine VM preserves the monolith but delivers none of the requested auto-scaling or managed-database benefits. Refactoring the whole application into serverless functions and a NoSQL store is a full re-architecture that the business explicitly wants to avoid and would also force a risky data-model change. Retiring and rebuilding from scratch is the most expensive and risky path and is unwarranted when moderate replatforming already meets the objectives.