Cloud Digital Leader Practice Question: Drag and drop the steps to migrate an on-premises…

Answer analysis

Option-by-option breakdown

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

• ✓

  Set up the destination Cloud SQL instance, then connect to the source database, then create and start the migration job, then promote the Cloud SQL instance to make it primary.

  Why this is correct

  This is the correct order because you first need to create the target Cloud SQL instance where the data will migrate to, then establish connectivity to the source database, then create and run the migration job, and finally promote the instance to make it the active database.

• ✗

  Connect to the source database, then set up the destination Cloud SQL instance, then create and start the migration job, then promote the Cloud SQL instance.

  Why it's wrong here

  This sequence is invalid because it begins by connecting to the source before any Cloud SQL destination exists. In Database Migration Service, a migration job must reference a live destination instance to validate connectivity and create the data path; without that target, the source connection cannot be associated with a migration and no data can be staged. The destination Cloud SQL instance must be provisioned first so it can serve as the endpoint for the job, and only then should you configure the source connection and launch the migration.

• ✗

  Set up the destination Cloud SQL instance, then create and start the migration job, then connect to the source database, then promote the Cloud SQL instance.

  Why it's wrong here

  Starting the migration job before connecting to the source is not possible because the job's initial load and continuous replication require source database endpoint, credentials, and binlog settings to be known at creation time. The Database Migration Service validates the source connection as part of job creation and fails validation if no connectivity is configured. Therefore, creating the destination instance, then using a connection profile to the source, must precede creating and starting the migration job.

• ✗

  Set up the destination Cloud SQL instance, then connect to the source database, then promote the Cloud SQL instance, then create and start the migration job.

  Why it's wrong here

  Promoting the Cloud SQL instance to primary before creating/starting the migration job inverts the cutover process. Promotion is the final cutover that stops continuous replication and redirects writes to Cloud SQL; it must only be run after the migration job has been created, started, and completed an initial sync plus a continuous catch-up. Promoting early makes a live primary with stale or empty data, and any subsequent migration would risk conflicting with writes made directly to Cloud SQL.

Go deeper

Related to this question