If you are a CTO, CIO, CXO, VP Engineering, or Head of Engineering at a mid-market or enterprise company running on Google Cloud Platform — this page is for you.
Not for developers learning GCP. Not for students studying for a certification. For the person who owns the technology decision, manages the engineering team, and is accountable for what the cloud platform costs, how secure it is, and whether it can scale with the business.
I am Amit Malhotra, a Principal GCP Architect based in Toronto. I work with engineering leaders across Canada and the USA on the full range of GCP platform problems — architecture, DevSecOps, cost optimisation, disaster recovery, high availability, security compliance, and the platform foundations that determine whether your team moves fast or fights infrastructure every sprint.
I have worked with engineering teams at Tangerine Bank, Telus Health, Loblaws, RBC, and Ford, as well as B2B SaaS companies from seed stage through enterprise. I work on any size engagement — from a focused two-week architecture review to a multi-month platform build.
This playbook collects every question I get from CTOs, CIOs, and engineering leaders before, during, and after GCP consulting engagements. I add new questions every week. If your question is not here, reach out directly: https://buoyantcloudtech.com/contact-gcp-consulting/
A GCP consultant is a Google Cloud Platform specialist who works with engineering teams to design, build, secure, and optimise GCP infrastructure. The scope varies by engagement — some consultants focus on architecture and advisory, others on hands-on implementation. I do both. In a typical engagement I am designing the platform architecture, reviewing Terraform, hardening IAM, remediating security findings, and working directly with your engineering team — not producing slide decks and handing them off. The work is concrete and the deliverables are real: a landing zone, a hardened GKE platform, a Terraform module library, a security posture remediation, or a cost reduction plan with implementation.
In practice the terms overlap significantly. A GCP architect typically refers to the design and technical leadership role — defining how the platform is structured, owning foundational decisions, setting the technical direction. A GCP consultant is a broader term that includes architecture, implementation, advisory, and cost optimisation. I work as both. The distinction that actually matters for you as an engineering leader is not the title — it is whether your consultant produces documents or produces working infrastructure. I produce both: architectural documentation that your team can reference, and the actual Terraform, pipeline configuration, and platform controls that implement it.
General cloud consulting covers AWS, Azure, and GCP at varying depths. GCP consulting means deep, GCP-specific expertise — understanding how Google’s org hierarchy and resource model differ from AWS, how GKE differs from EKS, how Workload Identity Federation works on GCP specifically, how VPC Service Controls provide data perimeter enforcement that has no direct equivalent on other platforms. I work exclusively on Google Cloud. That specialisation matters when your platform problems are GCP-specific and a generalist consultant is working from documentation rather than experience.
The companies I work with fall into a few patterns. B2B SaaS companies approaching enterprise sales cycles where security and compliance become blockers. Mid-market technology companies whose GCP platform has outgrown the team that built it. Enterprises migrating workloads to GCP from AWS, Azure, or on-premise environments. Regulated companies in FinTech, healthcare, and retail that need a GCP platform that satisfies compliance requirements — SOC 2, PIPEDA, HIPAA, PCI. And startups that are post-Series A and need to get the platform foundation right before scale makes it expensive to fix.
A GCP consultant makes sense when the need is specific and time-bounded — a security remediation, a migration, a landing zone build, an architecture review before a fundraise. A full-time GCP engineer makes sense when you need daily hands-on engineering capacity long-term and the scope of work justifies a permanent headcount. A fractional Principal Architect — which is one of the models I offer — sits between the two. You get consistent senior architectural oversight on a part-time basis, without the cost or lead time of a full-time hire. For many mid-market engineering teams, the fractional model is the right answer for 12-24 months while the team is building internal GCP capability.
The right GCP consultant has deep, demonstrable experience on the specific GCP services your platform uses — not just general cloud experience. Ask for examples of real GCP environments they have designed and delivered. Ask what the last three engagements covered and what the specific outcomes were. Ask how they handle situations where their recommendation conflicts with what the engineering team wants to do. A good consultant has a point of view and can defend it. Also evaluate the engagement model — do you work directly with the consultant or does the work get handed to a junior team? In my engagements, you work directly with me throughout.
The questions that actually reveal capability: What GCP services do you consider your deepest expertise? Can you walk me through a GCP landing zone design decision you made recently and why you made it that way? How do you approach a GCP environment that has grown without architectural discipline — where do you start? What is your position on Terraform module structure for a team of 20 engineers? How do you handle Workload Identity Federation migration when a team has dozens of existing service account keys in production? The answers tell you whether you are talking to someone with real production experience or someone who has passed a certification.
A good GCP consulting proposal is specific about what will be delivered, how long it will take, and what your team needs to provide. It identifies the specific risks and gaps it will address. It does not promise outcomes that depend on factors outside the consultant’s control. Watch for proposals that are heavy on methodology and light on specifics — that usually means the consultant is applying a generic framework rather than designing for your environment. Also look for clarity on who does the work. A proposal from a consulting firm that mentions “our team” without naming the architect who will actually work with you is a red flag.
It depends on the scope and your preference for how the relationship works. A consulting firm typically offers broader resource capacity — multiple engineers, project management, a named account manager. A solo Principal Architect offers depth, consistency, and direct access — the same person who scopes the engagement does the work. For platform architecture and security work, depth and consistency usually matter more than breadth. My model is deliberately solo: no account managers, no junior engineers doing the work while I handle the sales relationship. The trade-off is capacity — if you need ten engineers on-site, I am not the right fit. If you need one very experienced architect working closely with your team, I am.
Certifications tell you someone passed an exam. Experience tells you they have solved real problems under real constraints. The way to distinguish: ask about specific decisions they made in production environments and why. Ask what went wrong in an engagement and how they handled it. Ask about a GCP service limitation they worked around and how. Ask them to critique your current architecture — an experienced architect will identify real issues quickly and explain them clearly. Someone who is primarily certified will give generic answers. Also look at named clients and the specificity of their case studies. Vague client references and outcome descriptions are a signal.
I work with any engagement size — from a two-week focused architecture review to a six-month platform build. For engineering leaders who are evaluating whether GCP consulting will deliver value, I usually recommend starting with an architecture review. It has a defined scope, a clear output — a prioritised findings report — and it gives you and me a working relationship before committing to a larger engagement. If the review identifies significant work and we work well together, expanding the engagement is straightforward. If the review finds less than expected, you have spent a small amount to confirm your platform is in good shape.
The honest answer is that both are often true simultaneously. GCP consulting addresses the platform architecture and technical debt problems that internal process changes cannot fix — an overpermissioned IAM model, an unstructured Terraform codebase, a GKE cluster that was never properly hardened. Better internal processes address how the team works and how decisions are made going forward. My engagements typically cover both — I fix the architectural problems and document the decision-making framework your team should follow to avoid recreating them.
It varies significantly by scope. An architecture review takes two to four weeks. A focused security remediation or IaC migration takes four to eight weeks. A full landing zone build takes six to ten weeks depending on complexity. A GKE platform build is typically eight to twelve weeks. A full platform modernisation programme for an enterprise environment can run three to six months. I scope engagements clearly upfront so you know what to expect before work begins. For fractional engagements, there is no fixed end date — the engagement continues as long as it is delivering value.
GCP consulting rates vary based on seniority, scope, and engagement model. I work on a retainer model for fractional and ongoing engagements, and on a project basis for scoped deliverables. I do not publish specific rates publicly — the right number depends on what the engagement actually covers. I am comfortable working with a range of budgets and I am transparent about what is achievable within a given budget before any engagement starts. Reach out and we will have a direct conversation about scope and cost: https://buoyantcloudtech.com/contact-gcp-consulting/
A fractional GCP architect is a senior architect who works with your team on a part-time, ongoing basis — typically two to three days per week. You get consistent senior architectural oversight without the cost or lead time of a full-time hire. The engagement runs on a monthly retainer, which gives you predictable cost and consistent access. It is the right model for teams that need ongoing architectural guidance as the platform evolves — reviewing platform decisions, unblocking engineers, owning the architecture roadmap — rather than a one-time project with a defined end date.
A GCP architecture review covers the five dimensions that determine whether a platform is production-ready and scalable: security posture, cost efficiency, IaC coverage, scalability architecture, and operational maturity. I review your GCP environment directly — IAM configuration, network topology, Terraform structure, GKE setup, audit logging, cost profile — and produce a prioritised findings report that tells you what is creating risk, what is creating cost, and what needs to change, in the order that matters most. The review typically takes two to four weeks and can be done without disrupting your team’s existing work.
Yes. I work with any engagement size. Some of the most valuable work I do is short and focused — a two-week security review before an enterprise sales process, a one-week GKE cost analysis, a three-day IAM remediation. You do not need a large budget or a long-running engagement to get value from GCP consulting. If your problem is specific and well-defined, a focused short engagement is often the most efficient way to solve it.
The ROI varies by engagement type. For cost optimisation work, I typically find 20-35% reduction opportunities in the first review for teams that have never done a structured cost assessment — the ROI is direct and measurable. For security and compliance work, the ROI is risk reduction — avoiding a breach, passing an enterprise security review, completing a SOC 2 audit. For architecture work, the ROI is velocity — a well-structured platform means your team ships faster and spends less time on infrastructure problems. For fundraise preparation, passing technical due diligence without findings can directly affect valuation and deal terms.
Both, depending on the engagement type. Architecture reviews and well-scoped project engagements are typically fixed price — you know what you will pay before work begins. Fractional and ongoing advisory engagements run on a monthly retainer. For engagements where the scope is less defined at the start, I will be transparent about the uncertainty and structure the engagement in phases so you can evaluate value before committing to the full scope.
GCP security consulting covers the full security architecture of a GCP platform — IAM structure and least-privilege enforcement, Workload Identity Federation, VPC Service Controls for data perimeter enforcement, org policy constraints, Binary Authorization for container image governance, Secret Manager for credentials management, Cloud Audit Logs for visibility, and Security Command Center for continuous misconfiguration detection. I implement the 6-Layer Security Model across every engagement — network, identity, workload, data, pipeline, and observability — as an integrated security architecture rather than a collection of individual controls.
DevSecOps is the practice of embedding security controls into the engineering workflow rather than treating security as a separate gate or audit function. On GCP, it means three things in practice: security controls enforced at the infrastructure layer through org policies and IAM boundaries so engineers cannot accidentally misconfigure them away; security checks in the CI/CD pipeline through Checkov IaC scanning, container image scanning via Artifact Registry, and Binary Authorization enforcement; and audit logging and alerting that gives you visibility without requiring a dedicated security team. I build DevSecOps pipelines that treat security findings the same way they treat failing tests — they block the merge. More at https://buoyantcloudtech.com/cloud-service/devsecops-cloud-security/
Enterprise security reviews are highly predictable — they check the same things every time. IAM structure and whether primitive roles are in use on production projects. Network segmentation and whether workloads are publicly exposed by default. Secrets management — are credentials in Secret Manager or hardcoded in environment variables. Audit logging — are Data Access logs enabled and is there evidence of who accessed what. Encryption key management — are customer-managed keys in place for regulated data. VPC Service Controls for data perimeter enforcement. If your platform has these controls in place and they are consistently applied across all projects, you will pass. If not, I can help you get there before the review starts. Full detail at https://buoyantcloudtech.com/why-enterprise-deals-stall-security-review-gcp/
Yes — the technical controls required for SOC 2 map directly to GCP platform architecture decisions. CC6 (logical access) maps to IAM structure and Workload Identity Federation. CC7 (system operations) maps to Cloud Audit Logs and Security Command Center. CC8 (change management) maps to Terraform-managed infrastructure and pipeline controls. CC9 (risk mitigation) maps to DR architecture and incident response. I have worked with B2B SaaS teams mid-audit using Drata for continuous compliance monitoring where the primary remediation work was GCP platform structure rather than policy writing. The policies existed — the technical controls did not match them. I fix the technical controls.
Firewall rules control network traffic — which services can communicate with which on which ports. VPC Service Controls operate at a different layer — they enforce a data perimeter around GCP services regardless of network path. Even if someone has valid credentials, VPC Service Controls prevent them from exfiltrating data to destinations outside the defined perimeter. This is the control that satisfies data residency requirements and is specifically asked for in enterprise security reviews and regulated industry audits. Firewall rules and VPC Service Controls are complementary — you need both. More at https://buoyantcloudtech.com/gcp-vpc-service-controls-security-consulting/
This is one of the most common situations I encounter. The typical pattern: primitive roles granted during early build phase, service accounts with overly broad permissions, no group-based access model, and a growing list of direct user bindings that nobody fully understands. The remediation approach I use is systematic: first audit all IAM bindings using Cloud Asset Inventory to understand the full picture, then identify and remove primitive roles on production projects, then implement group-based access with predefined or custom roles scoped to minimum required permissions, then migrate CI/CD pipelines to Workload Identity Federation to eliminate service account keys. Done in phases, this remediation does not disrupt running workloads. Full detail at https://buoyantcloudtech.com/gcp-iam-mistakes-security-risks/
Workload Identity Federation allows GCP workloads — CI/CD pipelines, GKE pods, Cloud Run services — to authenticate to GCP APIs using short-lived, automatically rotated credentials rather than long-lived service account keys. This matters because service account keys are one of the most common sources of credential leakage — they get committed to version control, stored in CI/CD environment variables, and copied into places they should never be. WIF eliminates the key entirely. There is no file to leak. For engineering leaders, the business case is straightforward: it eliminates a credential management burden and removes one of the most common critical findings in enterprise security reviews and SOC 2 audits. Migration guide at https://buoyantcloudtech.com/gcp-workload-identity-federation-migration/
GCP Privileged Access Manager provides just-in-time elevated access — an engineer requests a privileged role for a specific task, it is granted for a defined time window, and it expires automatically. Every request and grant is logged in Cloud Audit Logs with full context. This satisfies the SOC 2 requirement for privileged access management without requiring a third-party PAM tool. For engineering leaders, it means your team can have the elevated access they need when they need it, with a full audit trail that satisfies compliance requirements, without maintaining always-on privileged accounts that create unnecessary risk. More at https://buoyantcloudtech.com/gcp-privileged-access-manager-soc2/
A GCP landing zone is the foundational platform layer that everything else runs on — the org hierarchy, folder structure, network topology, IAM boundaries, org policy constraints, and security baseline that are applied consistently across all projects and teams. If your GCP environment has multiple teams, multiple projects, and any compliance or security requirements, you need a landing zone. Without one, each team makes independent decisions about network design, IAM, and security controls, and the result is inconsistency that creates risk and makes audits difficult. I build landing zones as Terraform-managed, reproducible foundations that new projects inherit automatically. Full detail at https://buoyantcloudtech.com/gcp-landing-zone-blueprint/
The SCALE Framework is the architectural lens I apply to every GCP engagement. Five dimensions: Security by Design — security controls embedded in the architecture from day one, not retrofitted. Cloud-Native — using managed GCP services that eliminate operational overhead. Automation/IaC — every resource Terraform-managed, every change version-controlled. Lifecycle Ops — designed for Day 2 from Day 1, with upgrade paths, observability, and cost governance built in. Elastic Scalability — autoscaling at every layer so the platform scales with demand rather than requiring manual intervention. When I review a GCP platform, I assess it against all five dimensions. When I build one, I design it to score well on all five. More at https://buoyantcloudtech.com/scale-framework-gcp-architecture/
The decision comes down to workload characteristics and operational preference. GKE is the right choice for stateful workloads, workloads with complex scheduling requirements, teams that need fine-grained control over the compute layer, and organisations that are already investing in Kubernetes operational capability. Cloud Run is the right choice for stateless containerised workloads where you want to eliminate node pool management entirely, pay only for actual execution, and scale to zero automatically. In most production environments I design, both are present — GKE for the core platform workloads and Cloud Run for stateless APIs, event-driven processors, and GenAI inference endpoints. The wrong choice is defaulting to one platform for everything without evaluating the fit.
GKE hardening is the set of security controls that make a GKE cluster production-ready from a security perspective. It covers: Workload Identity enabled on the cluster so pods authenticate via federation rather than node service accounts; Binary Authorization configured to enforce that only signed, scanned images can be deployed; OPA/Gatekeeper policies that enforce security standards on all workloads — no root containers, resource limits required, approved base images only; network policies between namespaces; distroless or minimal base images; Secret Manager CSI Driver for secrets injection rather than environment variables; and private cluster configuration with no public endpoint on the control plane. Done correctly, GKE hardening means a compromised workload cannot easily escalate privileges or access other workloads in the cluster. Full detail at https://buoyantcloudtech.com/gke-security-hardening-case-study/
RTO (Recovery Time Objective) and RPO (Recovery Point Objective) depend on the architecture decisions you make upfront. With a regional GKE cluster and multi-zone node pools, a Cloud SQL instance with high availability enabled, and global load balancing, a zonal outage is typically transparent to users — RTO is near zero. For a regional GCP outage, RTO depends on whether you have a multi-region architecture — typically 15-60 minutes for a well-designed failover with tested runbooks. RPO depends on backup frequency and replication — for Cloud SQL with point-in-time recovery, RPO can be under one minute. The key phrase is “tested runbooks” — an RTO is only meaningful if the failover has been rehearsed and the runbooks have been validated. I design DR architectures and validate them as part of the engagement. More at https://buoyantcloudtech.com/gcp-disaster-recovery-ha-guide/
High availability is about eliminating single points of failure within a region — regional GKE clusters with multi-zone node pools, Cloud SQL with HA enabled, global load balancing that routes around unhealthy instances. It handles the common failure modes: a zone going down, a node failing, a VM being preempted. Disaster recovery is about recovering from a catastrophic failure — a full regional outage, data corruption, accidental deletion — typically involving a recovery process rather than automatic failover. Both are necessary and they address different failure scenarios. HA keeps your platform running through routine failures. DR gets you back online after uncommon but serious ones. I design both layers as part of every production platform engagement.
Right-sizing GKE node pools is a data-driven process, not a guessing exercise. I use three inputs: actual CPU and memory utilisation from Cloud Monitoring over a representative period (at minimum 30 days), Vertical Pod Autoscaler recommendations in recommendation mode — which suggest right-sized resource requests based on actual usage without automatically changing running workloads — and workload profiles that identify which node pool types match which workloads. The process: review VPA recommendations, adjust resource requests conservatively (do not go below the 95th percentile of observed usage), enable cluster autoscaler with appropriate minimum and maximum bounds, and monitor for one billing cycle before drawing conclusions. The typical outcome for teams that have never done this: 25-40% reduction in node pool cost without any reliability impact.
A service factory is the pattern library that sits between your platform infrastructure and your application teams. It is a curated set of standardised blueprints — for Cloud Run services, GKE workloads, Cloud SQL instances, CI/CD pipelines — that encode your organisation’s decisions about security, networking, observability, and cost into reusable Terraform modules and pipeline templates. When a developer wants to deploy a new service, they consume a pattern rather than making independent configuration decisions. The benefit for engineering leaders: consistency at scale, faster onboarding, and audit readiness — when a reviewer asks how you ensure consistent controls across all services, the answer is the pattern library, not individual engineers making the right choice every time. More at https://buoyantcloudtech.com/cloud-service-patterns-factory-gcp/
A service factory is a component of an internal developer platform — the pattern library that defines what correct looks like for each workload type. A full internal developer platform (IDP) adds the self-service layer on top: a developer portal, automated environment provisioning, golden path tooling that lets engineers deploy infrastructure without writing Terraform themselves. For most mid-market teams, a service factory is the right starting point — it delivers the consistency and security benefits without the investment required for a full IDP. I build both, depending on where the team is and what they need. More at https://buoyantcloudtech.com/cloud-service/platform-engineering-internal-developer-platforms/
Yes — I am based in Toronto but work remotely with engineering teams across Canada and the USA. The majority of my engagements are with teams I have never met in person. I work async-first — architecture documentation, Terraform reviews, Loom walkthroughs, Slack or Teams for day-to-day communication — with regular video calls for architecture discussions and milestone reviews. Geography has not been a constraint in any engagement I have run.
Canadian companies on GCP need to address data residency requirements under PIPEDA at the federal level, with additional provincial requirements in Quebec (Law 25), British Columbia, and Alberta. For healthcare workloads, PHIPA in Ontario and equivalent legislation in other provinces apply. For FinTech, FINTRAC requirements around transaction monitoring and data retention are relevant. GCP provides the technical tools to satisfy these requirements — data residency org policies that restrict resource creation to Canadian regions, VPC Service Controls for data perimeter enforcement, Cloud Audit Logs for access monitoring. I have designed compliant platforms for Tangerine Bank, Telus Health, and Loblaws under these requirements.
US companies on GCP typically need to address one or more of: SOC 2 Type II for B2B SaaS companies selling to enterprise buyers; HIPAA for healthcare and health-adjacent companies handling protected health information; PCI DSS for companies processing payment card data; and FedRAMP-adjacent requirements for companies selling to government or government contractors. GCP is compliant with all of these at the platform level — the work is ensuring your GCP configuration satisfies the technical requirements. I have designed and delivered compliant platforms for US enterprise and mid-market companies across all of these frameworks.
The technical work is largely the same — the SCALE Framework, landing zone design, GKE hardening, IaC structure, and DevSecOps pipeline apply equally. The differences are in compliance context and buyer expectations. Canadian clients typically have stronger data residency requirements and are more likely to be in regulated industries where provincial health privacy legislation applies. US clients are more likely to have SOC 2 as a hard requirement for enterprise sales, and enterprise procurement security reviews in the USA tend to be more structured and document-heavy than their Canadian equivalents. I am fluent in both contexts and tailor the compliance layer of every engagement to the specific regulatory environment the client operates in.
Yes — this is a situation I encounter regularly. A US company expanding into the Canadian market typically needs to address data residency (Canadian customer data staying in Canada), PIPEDA compliance for handling personal information of Canadian residents, and potentially provincial health privacy legislation if the product touches healthcare. On GCP, this typically means establishing a Canadian-region resource boundary via org policy, ensuring Cloud Storage and databases are provisioned in northamerica-northeast1 or northamerica-northeast2, and implementing VPC Service Controls to enforce the data perimeter. I can design the Canadian-compliant GCP configuration as an extension of an existing US GCP environment without requiring a separate platform.
My deepest experience is in FinTech and regulated financial services — Tangerine Bank and RBC represent multi-year engagements in environments with demanding security and compliance requirements. Healthcare is a close second — Telus Health involved regulated health data on GCP under Canadian health privacy legislation. Retail and enterprise SaaS round out the picture — Loblaws for large-scale retail infrastructure and Ford for global enterprise GCP. I also work extensively with B2B SaaS companies from seed through Series B, where the focus is usually on getting the platform foundation right before enterprise sales cycles and fundraises create scrutiny.
I typically have availability to start a new engagement within one to two weeks of initial scoping. The first step is a short discovery conversation — usually 30-45 minutes — where I understand your environment, the problems you are facing, and what you need from the engagement. From that conversation I can give you a clear picture of what the engagement would cover, how long it would take, and what it would cost. There is no lengthy proposal process or procurement cycle. Reach out and we can have that conversation this week: https://buoyantcloudtech.com/contact-gcp-consulting/
Every engagement is different, but the working pattern is consistent. I review your environment and understand the context deeply before making recommendations. I am available async via Slack or Teams for questions and reviews throughout the engagement — not just during scheduled calls. I produce written documentation for every architectural decision so your team has a reference that survives the engagement. I work directly with your engineers, not alongside them in a passive advisory capacity — I review their Terraform, give specific feedback on their pipeline configuration, and explain the reasoning behind every recommendation so the team builds capability, not just dependency. And I am direct — if I think a decision is wrong, I will say so and explain why.
If you are a CTO, CIO, or engineering leader and you want an independent view of where your GCP platform stands — covering security posture, cost efficiency, architecture quality, and operational maturity — I offer a short audit and share findings with a prioritised remediation plan.
I work with engineering teams in Toronto, across Canada, and across the USA. Any size engagement. Direct access to a Principal Architect throughout.
Reach out and we can start with a short conversation: https://buoyantcloudtech.com/contact-gcp-consulting/
More about my background and approach: https://buoyantcloudtech.com/about/
– The SCALE Framework: https://buoyantcloudtech.com/scale-framework-gcp-architecture/
– GCP Landing Zone Blueprint: https://buoyantcloudtech.com/gcp-landing-zone-blueprint/
– GKE Security Hardening: https://buoyantcloudtech.com/gke-security-hardening-case-study/
– VPC Service Controls: https://buoyantcloudtech.com/gcp-vpc-service-controls-security-consulting/
– Workload Identity Federation Migration: https://buoyantcloudtech.com/gcp-workload-identity-federation-migration/
– Why Enterprise Deals Stall at the Security Review: https://buoyantcloudtech.com/why-enterprise-deals-stall-security-review-gcp/
– Technical Due Diligence — What Investors Look for in Your GCP Setup: https://buoyantcloudtech.com/technical-due-diligence-gcp-investors/
– GCP Disaster Recovery and High Availability: https://buoyantcloudtech.com/gcp-disaster-recovery-ha-guide/
– DevSecOps Without a Security Team: https://buoyantcloudtech.com/devsecops-without-a-security-team-gcp/
– GCP Consulting Services Canada: https://buoyantcloudtech.com/gcp-consulting-services-canada/
– GCP Consulting Services USA: https://buoyantcloudtech.com/gcp-consulting-services-usa/
– About Amit Malhotra: https://buoyantcloudtech.com/about/
