4 of the 4 questions we have for this objective, shown with the answer and the reasoning.
Creating a migration plan (i.e., documents and architectural diagrams)
Delmont Insurance is planning a migration of 140 applications to Google Cloud over 18 months. Several applications share databases and call each other, the on-premises network uses most of the 10.0.0.0/8 range, and a previous project failed when a migrated application performed poorly under month-end load. The program director asks the architect for the planning steps that reduce these risks.
Which three actions should you include in the migration plan? Each correct answer presents part of the solution.
- AMap application and data dependencies and group tightly coupled applications and their shared databases into the same migration waveMoving dependent applications together avoids splitting chatty systems across the hybrid link, which causes latency and failures during the transition.
- BPlan VPC subnet ranges that do not overlap with the on-premises address space before building the landing zoneHybrid routing requires unique address ranges, and changing subnets after workloads are deployed is disruptive, so IP planning belongs at the start.
- CLoad test each migrated application at month-end volumes in Google Cloud before its production cutoverTesting at realistic peak load before cutover catches the performance problem that sank the previous project while rollback is still easy.
- DMigrate all 140 applications in one cutover weekend to avoid running a hybrid environmentA single big-bang cutover multiplies risk, gives no chance to learn from early waves, and makes rollback very hard for an estate of this size.
- EMigrate shared databases last, after every application that uses them has movedLeaving shared databases on premises while their applications run in the cloud sends every query across the hybrid link for months, which harms performance.
Why: A migration plan reduces risk by moving work in waves, ordered by dependencies, on a network designed for hybrid operation, with testing before each cutover. Dependency mapping keeps tightly coupled components together; address planning prevents overlap with on-premises ranges, which is very hard to fix later; and performance testing at real peak loads validates each wave. Big-bang cutovers and leaving shared data behind are classic failure patterns because they either concentrate risk or create long periods of cross-network chatter.
Creating a migration plan (i.e., documents and architectural diagrams)
Kinross Engineering owns perpetual Windows Server Datacenter licenses that it bought in 2018 without Software Assurance. It plans to move 60 Windows Server VMs to Compute Engine and wants to reuse these licenses instead of paying for Windows Server again through Google Cloud, while staying compliant with the license terms, which require the licenses to run on hardware dedicated to the company.
How should you deploy the VMs?
- AUse Google-provided Windows Server premium images on standard shared VMsPremium images include the Windows Server license in the hourly price, so the company would pay for licenses it already owns.
- BImport BYOL images and run them on standard shared VMsWindows Server licenses have no License Mobility rights, so these licenses cannot run on shared, multi-tenant hosts, and this design is not compliant.
- CImport the VMs with bring-your-own-license images and run them on sole-tenant nodesLicenses with dedicated hardware requirements must run on dedicated physical servers, and sole-tenant nodes provide them; Compute Engine supports importing your own Windows Server media and running it on sole-tenant nodes.
- DRun the VMs on Spot VMs with premium images to offset the license costSpot pricing lowers compute cost but still charges for the premium Windows license, and preemption is unsuitable for these servers.
Why: Licensing can change both the architecture and the financial case of a migration. Some Microsoft application licenses, such as SQL Server with Software Assurance, can move to shared cloud infrastructure through License Mobility, while Windows Server licenses brought to the cloud require dedicated hardware, which Compute Engine provides through sole-tenant nodes; Microsoft's terms also restrict which license purchase dates and versions qualify, so the license agreement must be checked first. The architect must compare the cost of sole-tenant capacity with the cost of pay-as-you-go premium images; the right answer depends on consolidation and license counts. In this scenario, reuse and compliance are both stated requirements, which points to BYOL on sole-tenant nodes.
Creating a migration plan (i.e., documents and architectural diagrams)
Ashby Wholesale is building new analytics and pricing services on Google Cloud, but its on-premises Oracle database remains the system of record for orders for at least two more years. The pricing service needs order changes in BigQuery within a few minutes. The database team will not allow new triggers, application changes, or heavy query load on the Oracle server, and the company wants a managed, serverless integration. The data center connects to Google Cloud over Cloud Interconnect.
Which integration approach should you recommend?
- AUse Datastream to read change data from the Oracle logs over the Interconnect connection and replicate it to BigQueryDatastream is a serverless change data capture service that reads Oracle redo logs, so it adds no triggers or application changes and only light load, and it replicates changes to BigQuery with low latency.
- BSchedule a nightly export of the order tables to CSV files and load them into BigQueryNightly exports are hours behind and the full-table export puts heavy load on the server, so they fail both the freshness and load constraints.
- CAdd database triggers that write changed rows to a staging table, and poll it from Cloud RunTriggers are explicitly not allowed, and polling a staging table adds load to the Oracle server.
- DMigrate the Oracle database to Cloud SQL now and point both systems at itThe scenario states that Oracle stays the system of record for two more years, so a database migration is out of scope for this integration.
Why: New cloud services often have to coexist with existing systems that cannot change yet. Log-based change data capture is the least intrusive way to get current data out of a production database because it reads the transaction logs rather than querying tables or adding triggers. Datastream provides this as a managed service with BigQuery as a direct destination and can use private connectivity over Interconnect. Batch exports and trigger-based designs are the traditional alternatives, but they break the freshness and no-change constraints here.
Creating a migration plan (i.e., documents and architectural diagrams)
Rookwood Media plans to move about 900 VMware virtual machines from two data centers to Google Cloud. Before the business case is approved, the CFO wants an inventory of the servers with their actual CPU, memory, and storage use, suggested Google Cloud machine sizes, and an estimate of the cost of running them on Google Cloud compared with the current environment.
Which tool should the architect use first?
- AMigrate to Virtual Machines, starting test clones of all 900 VMsMigrate to Virtual Machines performs the migration itself; it is used after assessment and does not produce the inventory and cost comparison the CFO needs first.
- BMigration Center, collecting inventory and performance data with the discovery client and generating cost estimates and TCO reportsMigration Center discovers on-premises assets, collects utilization data, suggests right-sized Google Cloud targets, and produces pricing and total cost of ownership reports for the business case.
- CDatabase Migration Service, assessing each serverDatabase Migration Service migrates databases to Cloud SQL, AlloyDB, and similar targets; it does not inventory or price VM fleets.
- DThe Google Cloud Pricing Calculator, with machine sizes copied from the vSphere configurationThe calculator prices what you enter, but copying allocated sizes ignores actual use, and building 900 entries by hand is slow and error-prone.
Why: A migration starts with assessment: know what you have, how much of it is really used, and what it will cost in the target. Migration Center is Google Cloud's hub for this phase, combining discovery, utilization collection, right-sizing, and cost and TCO reports, and it links to the migration tools for later phases. Migration tools such as Migrate to Virtual Machines and Database Migration Service are the traps, because they belong to the execution phase.