4 of the 10 questions we have for this objective, shown with the answer and the reasoning.
Analyzing and defining business processes
Hollybrook Media, a Google Cloud partner, has just finished migrating a broadcaster's video archive and transcoding platform to Google Cloud. The broadcaster's executives approved the project to cut transcoding time by 50 percent and reduce storage cost by 30 percent. The partner wants the customer to renew and expand the engagement next year.
What should the partner do after go-live?
- ATrack the agreed transcoding time and storage cost metrics, review them with the customer's executives on a regular schedule, and act on gapsCustomer success means showing that the outcomes the customer paid for were achieved. Regular reviews against the agreed metrics prove value and surface problems early.
- BClose the project and wait for the customer to raise support ticketsA reactive approach gives no evidence that the business goals were met and leaves problems unnoticed until they become complaints.
- CReport the number of virtual machines and buckets that were migratedMigration volume measures project activity, not the business outcomes the executives used to approve the work.
- DOffer the customer a discount on the next project to secure the renewalA discount may help a sale, but it does not show the customer that the platform delivers the promised value.
Why: Customer success management keeps the focus on the outcomes the customer bought, not on the work that was delivered. The success measures should be agreed before the project and then tracked and reviewed with the customer after go-live, with an action plan when results fall short. Activity metrics such as resources migrated are easy to report but do not show value. A proactive review cadence is the basis for adoption, renewal and expansion.
Analyzing and defining business processes
Larchmont Insurance will start migrating 200 applications to Google Cloud in four months. Its 25 infrastructure engineers have strong VMware and networking skills but almost no Google Cloud experience, and the budget does not allow hiring a large new team. The CTO wants the existing team ready to run the migration waves.
What should you recommend?
- AHire contractors for the full migration and keep the existing team on on-premises supportContractors can help, but this leaves the permanent team unable to run the platform after the migration and does not fit the hiring budget.
- BPostpone the migration until every engineer has earned the Professional Cloud Architect certificationRequiring one advanced certification for everyone delays the business plan and ignores that different roles need different skills.
- CSend all engineers to the same one-day introductory course and start the migrationA single introductory course is too shallow and does not target the specific gaps of each role, so engineers would not be ready to run migration waves.
- DAssess the current skills of each engineer against the roles the migration needs, then build role-based learning plans using Google Cloud training and hands-on labs, with a pilot migration as practiceA skills assessment shows the actual gaps per role, role-based learning targets them efficiently, and a pilot migration turns training into real experience before the main waves.
Why: Skills readiness starts with an assessment of what the team knows against what the target operating model requires. From there, role-based learning paths through Google Cloud training and hands-on labs close the gaps efficiently, and an early pilot workload gives practice with low risk. Certifications are useful milestones but should match the role. The Google Cloud Adoption Framework lists upskilling as a core part of the learn theme.
Analyzing and defining business processes
Pinewood Labs spends a steady amount every month on compute, but the mix keeps changing: workloads move between Compute Engine machine series, between us-central1 and us-east4, and from VMs to GKE and Cloud Run as teams modernize. Finance wants a lower rate on this baseline spend for the next three years without locking it to specific machine types or regions.
What should you recommend?
- AResource-based committed use discounts for a fixed number of N2 vCPUs in us-central1Resource-based commitments apply only to the committed machine series and region, so savings are lost as workloads move.
- BCompute flexible committed use discounts based on a committed hourly spendFlexible, spend-based commitments apply across machine series, regions and eligible services such as GKE and Cloud Run, which fits a stable total spend with a changing mix.
- CConvert all workloads to Spot VMsSpot VMs can be preempted and are not available for every service in the mix, so they do not suit production baseline spend.
- DBuy on-premises servers for the baseline and use Google Cloud only for peaksBuying hardware moves spend back to capital expense and adds data center operations, which is the opposite of the modernization the company is doing.
Why: Committed use discounts come in two forms. Resource-based commitments give the deepest saving for a fixed machine series in one region. Spend-based compute flexible commitments trade a slightly smaller discount for portability across machine series, regions and products such as GKE and Cloud Run. When the total spend is predictable but the shape of the workload is changing, flexible commitments protect the saving. The CapEx option is a trap for a company moving to an OpEx model.
Analyzing and defining business processes
Cedar Point Utilities is writing its first business continuity plan for a move to Google Cloud. The IT team proposes the same recovery objective of 15 minutes for all 60 applications, including the payroll batch, the customer outage map and an internal wiki. The CFO says the cost estimate for this approach is far too high.
What should you do first?
- AAccept the 15-minute objective and replicate every application to a second region in a hot standbyApplying the tightest objective to everything drives the high cost the CFO rejected, and many applications do not need it.
- BRun a business impact analysis with the business owners to rank processes by the impact of an outage and set a recovery time and recovery point objective for eachA business impact analysis ties each application to the business process it supports, so recovery objectives, and therefore cost, match the real impact of downtime.
- CRely on the Google Cloud service level agreements as the business continuity planSLAs describe the provider's availability commitments and credits. They do not cover the customer's processes, people, data recovery or communication during an incident.
- DAsk each application team to choose its own recovery objectiveTechnical teams alone cannot judge business impact, and objectives chosen in isolation are often inconsistent with the processes they support.
Why: Business continuity planning starts with a business impact analysis, which identifies critical processes, the cost of their disruption over time, and their dependencies. The result sets a recovery time objective and recovery point objective per process, which in turn selects the disaster recovery pattern and its cost. A single objective for everything either overspends or underprotects. Provider SLAs are an input to the plan, not the plan itself.