DEV Community: luis zuñiga

🚀 Deep Dive: Automating Google Workspace Migrations with Zero-Persistence & AI

luis zuñiga — Thu, 06 Aug 2026 01:45:33 +0000

Description: Stop relying on chaotic PowerShell scripts for your Domain Swaps. Learn how to execute a secure, tenant-to-tenant Google Workspace migration using a Zero-Persistence architecture, MCP integrations, and a multi-agent AI workflow.

Hey fellow builders! 👋

Prepping for a complex Google Workspace tenant-to-tenant migration (a Domain Swap or Cutover) feels exactly like planning a liveaboard technical dive to Malé, Maldives. You are operating in an unforgiving environment with a very narrow maintenance window. If your gear fails, or if you miscalculate your gas management, the impact on business continuity is immediate.

In the past, our engineering teams relied on a chaotic, scattered set of PowerShell scripts to manage these migrations. They required static credentials, lacked structured logging, and demanded way too much manual intervention. It was the equivalent of diving with an unserviced, tangled regulator.

As a GCP Workspace engineer, I want to share one possible professional workflow that redefines this standard. We built a robust Python orchestration engine (ejecutar_migracion_seguro.py) backed by a Zero-Persistence security model and multi-model AI coordination.

Here is the roadmap of what this SRE workflow looks like:

[ Temporary Folder ] ──> ( Credentials JSON ) 
                                │
                                ▼ (Step 1: Load into RAM)
                    [ Python Engine (RAM) ] ──> [ os.remove() ] ──> File Permanently Deleted from Disk!
                                │
                                ▼ (Step 2: Ephemeral Secure Connection)
                    [ Google Admin SDK API ] ──> ( Successful Sync / 0 Traces )

Here is how we execute the perfect deep dive.

🤿 Phase 1: Gas Management (The Zero-Persistence Architecture)
The largest attack vector in cloud deployments is static credentials sitting in jump servers or shared directories. A leaked Service Account JSON with Domain-Wide Delegation grants total control over the Workspace tenant, creating massive financial and compliance risks (like GDPR/HIPAA fines).

To solve this, we implemented a Zero-Persistence philosophy. It works like purging your lines before descent:

The Drop-Folder: The administrator temporarily places the Service Account .json file in a /credentials folder.

Memory Load: The script reads the file and initializes the Google Auth objects.

Physical Destruction: At second 1 of execution—before establishing any external connection—the script permanently deletes the file from the storage drive.

RAM Isolation: The credential state is retained purely in the Python process's RAM. If the terminal closes or the script fails, the credentials vanish entirely from the operating system.

Here you can see exactly how this logic is written in Python to ensure predictable and secure behavior:

import os
from google.oauth2 import service_account

def load_and_destroy_credentials(json_path):
    """
    Loads the Service Account directly into the process RAM
    and physically destroys the file immediately to mitigate leak risks.
    """
    if not os.path.exists(json_path):
        raise FileNotFoundError(f"Credentials file not found at {json_path}")

    # 1. Strict load into RAM
    credentials = service_account.Credentials.from_service_account_file(
        json_path, 
        scopes=['https://www.googleapis.com/auth/admin.directory.user']
    )

    # 2. Immediate physical destruction at second 1
    try:
        os.remove(json_path)
        print("[INFO] Certificate physically destroyed from disk. Operating in RAM isolation.")
    except OSError as e:
        print(f"[CRITICAL] Could not delete physical file: {e}. Aborting for security.")
        raise

    return credentials

💻 Phase 2: The AI Dive Buddies (Gemini 3.1 Pro & 3.5 Flash)
You wouldn't dive deep without a reliable dive computer like a Garmin Mk3i. For this architecture, we orchestrated development using two Artificial Intelligence models working in harmony:

The System Architect (Gemini 3.1 Pro): Handled the initial analysis of the legacy PowerShell scripts, designed the thread flow, and defined the strict Zero-Persistence security rules. It is the ideal model for complex planning and logical flow structuring.

The Execution SRE (Gemini 3.5 Flash): Delivered sub-second latency for rapid code refactoring, hot-debugging, and real-time console log interception during our sandbox tests.

To make this work, we didn't just copy and paste code. We integrated a suite of Model Context Protocol (MCP) servers. The Filesystem MCP allowed the AI to read the old scripts on disk, the Command MCP enabled controlled execution in our test/ sandbox, and the Search MCP queried the Google Admin SDK documentation in real-time to validate HTTP error handling.

⚠️ Phase 3: The "Hard Way" (Decompression Stops)
Even with the best planning, the depths of the Google API have their surprises. Here are the battle scars and lessons learned from the field:

The Eventual Consistency Trap: The Google Workspace Directory API is eventually consistent. If you create a user on a temporary domain and immediately try to rename them to the primary domain during Cutover, you will hit a sync delay of 15 to 60 seconds on Google's backend. You must incorporate dynamic delays (time.sleep) and automatic Exponential Backoff to avoid false failures.

Respect the Rate Limits: The Admin SDK enforces strict quotas (typically 1,500 requests per 100 seconds). Blasting the API will instantly return an HTTP 403 rateLimitExceeded error. We structured our migration into segmented data directories (Type-Migration/), batching 100 users for the Pilot Batch and 500 for Critical Batches, ensuring a safety margin between API calls.

The Human Brake: In an automated AI-assisted environment, a manual safety stop is critical. The script demands the exact input of CONFIRMAR MIGRACION in uppercase to prevent accidental test executions against real production environments.

System-Level Output Capture: Standard Python log handling failed to capture unforeseen traces or low-level interpreter errors. We natively overrode sys.stdout with a dedicated ConsoleLogger to ensure a 1:1 mirror of standard output was securely saved to our blog_dev/ audit directory.

💰 ROI: Surfacing Safely
This approach transforms a high-stress task into an optimal, scalable, and auditable SRE process.

By unifying the workflow and deploying this Python engine, the manual Domain Swap process that used to take up to 12 hours for 500 users now executes API calls in under 45 minutes. That is a 93% optimization in the email downtime window. Furthermore, SREs and Cloud Architects reduce their debugging time by 80%, focusing their efforts on DNS validation and user experience.

When you combine Zero-Persistence with AI-driven operational execution, you don't just migrate data; you architect resilience.

👇 Let's talk seriously: Are you still relying on static Service Accounts and persistent keys in your jump servers, or have you already transitioned to ephemeral zero-trust architectures? What automation do you use to prevent an API error from bringing down your organization's email flow? Destroy my approach or share your strategies in the comments!

GoogleWorkspace #GCP #CloudEngineering #DevOps #SRE #Security #Python #AWSBuilders

⚖️ Technical & Legal Safe Harbor Disclaimer

AUTHORSHIP AND INDEPENDENT CAPACITY: This publication is authored solely by me in my individual and private capacity. The views, methodologies, and technical workflows expressed herein are my own and do not necessarily reflect the official policy, position, or strategic direction of my current or former employers, clients, or any legal entity I am affiliated with.

INTELLECTUAL PROPERTY & CONFIDENTIALITY COMPLIANCE:

Zero Proprietary Disclosure: This content has been developed using publicly available information and personal research. No confidential information or internal proprietary source code belonging to my employer has been disclosed.

Independent Development: The workflows described are based on general industry best practices and were not developed as a "work for hire".

LIMITATION OF LIABILITY (NO WARRANTY): All code snippets and architectural patterns are provided "AS IS" without warranty of any kind.

COMPLIANCE: This contribution is made in good faith under the AWS Builder Terms and the MIT-0 License for any included source code.

🚀 Beyond the HCL: Trench Lessons from Deploying Critical Architectures on GCP with Terraform

luis zuñiga — Wed, 06 May 2026 21:54:39 +0000

The "Bunker" vs. Resilience: Scaling Windows Server Without the Burnout
By: Luis Alonso Zuñiga Carballo
Cloud Architect & Security Strategist

💣 The Challenge: The Problem That Kept Me Up at Night
Imagine this: You are tasked with deploying a critical-tier enterprise infrastructure on Google Cloud Platform (GCP). It’s not just about "spinning up VMs"; it’s about orchestrating an environment that supports Windows Server applications, ensures hybrid connectivity with on-premises offices, and—most importantly—doesn't break when traffic spikes or a node fails.

The true challenge was transforming a "functional bunker" into a High Availability Hybrid Architecture that was 100% reproducible and transparent for the stakeholder.

🏗️ The Strategy: Operational Symmetry in Action
For this deployment, I followed a three-stage validation workflow that ensures what is designed is exactly what is deployed:

Phase 1: Architectural Blueprint (ASCII): Before writing a single line of code, I mapped the entire logic using ASCII diagrams. This provided immediate clarity on traffic flow and subnet isolation without the distraction of complex tooling.

Phase 2: Infrastructure as Code (Terraform): Once the logic was solidified, I translated the ASCII blueprint into Terraform HCL. This allowed for the consistent deployment of 66 resources across multiple regions.

Phase 3: Stakeholder Visibility (PNG): Finally, I generated a high-fidelity PNG diagram based on the actual deployment. This served as the final "source of truth" to share with the client, providing full visibility into the security layers and hybrid connectivity established.

🛡️ Key Architectural Pillars

🌐 Global Networking
We utilized a custom VPC with Global routing mode to simplify BGP propagation across regions (us-east1 and us-east4).
🛡️ Layer 7 Shielding
We implemented Cloud Armor (WAF) and Identity-Aware Proxy (IAP). This eliminated public IPs for administration, allowing RDP access only through encrypted tunnels.
💾 Dual-Region Resilience
For critical backups, the standard was Dual-Region Cloud Storage, ensuring data survivability even in the event of a regional outage.

🛠️ The Hard Way: Lessons Learned from the Field
⚠️ The Quota Ghost: Never assume instance families are ready. Requesting vCPU quota increases in GCP can take at least one week.

🔌 The Routing "Trap": After establishing the IPsec tunnel, dynamic propagation often needs a manual nudge within the VPC Route Tables to ensure the Cloud Router is advertising correctly.

🤖 The Antigravity Factor: Using AI as a "copilot" to accelerate HCL generation is a force multiplier, but it requires human-in-the-loop auditing to maintain the Principle of Least Privilege (IAM).

💰 Business Value: Why Does This Matter?
This triple-stage workflow (ASCII → Terraform → PNG) isn't just about technical tidiness; it’s about Risk Mitigation:

Transparency: The client sees exactly what they are paying for.

Agility: We reduced deployment time from days to minutes through modular IaC.

Compliance: By following applied industry scenarios, we ensure that internal corporate procedures remain protected while delivering world-class security.

🏁 Call to Action
What is your preferred workflow for bridging the gap between a conceptual sketch and a production-ready environment? Let’s discuss in the comments! 👇

googlecloud #terraform #gcpcommunity #devops #cloudsecurity #iac #hybridcloud

⚖️ Technical & Legal Safe Harbor Disclaimer

AUTHORSHIP AND INDEPENDENT CAPACITY: This publication is authored solely by me in my individual and private capacity. The views, methodologies, and technical workflows expressed herein are my own and do not necessarily reflect the official policy or strategic direction of my current or former employers, clients, or any legal entity I am affiliated with.

INTELLECTUAL PROPERTY & CONFIDENTIALITY COMPLIANCE:

Zero Proprietary Disclosure: This content has been developed using publicly available information, official documentation, and personal research. No confidential information belonging to my employer has been disclosed.

Independent Development: The workflows described are based on general industry best practices and were not developed as a "work for hire."

LIMITATION OF LIABILITY: All technical info is provided "AS IS" without warranty. The author shall not be liable for any claim arising from the use of this information.

COMPLIANCE: This contribution is made in good faith and adheres to global technical community standards.

🛠️ From Foundations to Advanced SecOps: The GCP Developer’s Toolkit 🛡️

luis zuñiga — Fri, 24 Apr 2026 01:42:03 +0000

Hey GCP Community,

As developers and cloud engineers, we often start our journey learning how to deploy a VM or configure a bucket. But in today's landscape, "working code" isn't enough. We need "secure-by-design" architectures.

I’ve been documenting my journey and best practices in my latest project: GCP-ToolKit101. While the toolkit starts with the essentials, the goal is to bridge the gap between basic infrastructure and elite security operations using Chronicle, Mandiant, and SCC.

Here is how we evolve from 101 basics to enterprise-grade security:

⚡ Scaling Beyond Logs: Google Chronicle Once you master VPC Flow Logs in the "101" stage, the next level is Chronicle. It’s not just about storing logs; it's about sub-second detection using YARA-L.

Real-world case: Detecting Insider Threats in financial systems by correlating VPN access with unusual BigQuery exports.

🧠 Intelligence-Driven Code: Mandiant Advantage Security isn't just about blocking IPs; it's about knowing who is attacking. Integrating Mandiant APIs into your automated workflows allows you to:

Proactively block spear-phishing domains before they hit your users.

Prioritize vulnerabilities based on what actual APT groups are exploiting right now.

🏯 Total Posture: Security Command Center (SCC) Your infrastructure is only as strong as its weakest configuration. SCC acts as the "Command Tower" for:

Identity Leakage: Detecting when service account keys are accidentally pushed to public repos.

Compliance: Real-time monitoring of PCI-DSS or CIS benchmarks.

🚀 The Roadmap: GCP-ToolKit101
I created GCP-ToolKit101 to be a living resource. It’s the starting point for developers who want to master the Google Cloud ecosystem with a professional edge.

What you’ll find in the repo:

🏗️ Core Infrastructure: Clean, reusable patterns for GCP deployments.

🔒 Security First: Standardized configurations to harden your cloud environment.

📈 Evolution: I am currently integrating advanced SecOps modules, including YARA-L rule templates for Chronicle and automation scripts for SCC.

🛠️ Join the Journey
If you are a developer looking to bridge the gap between "it works" and "it's secure," this toolkit is being built for you. I’m sharing everything I learn while building B2B solutions for the Latam market.

👉 Check out the repo, drop a ⭐, and let’s build more secure cloud environments together:
https://github.com/luiszuniga1990/GCP-ToolKit101.git

GCP #GCPDev #CloudSecurity #DevSecOps #GoogleCloud #Mandiant #Chronicle #CompanyOfOne #TechCommunity

Deep Dive: Accelerating Infrastructure as Code (IaC) on GCP using Terraform and Antigravity

luis zuñiga — Fri, 17 Apr 2026 00:42:09 +0000

Key Stack: Terraform, Google Cloud Platform (GCP), Cloud Armor, Cloud SQL, Antigravity AI

When designing robust and scalable architectures for production environments, efficiency is non-negotiable. Traditionally, SRE and Infrastructure teams spend significant cycles managing network segregation, variable consistency, and manual security audits. However, the paradigm has shifted: Generative AI applied to Platform Engineering has arrived to eliminate operational toil.

In this article, we will technically analyze the paquetesaction project. We will explore how to deploy advanced Terraform modules on Google Cloud by operating alongside Antigravity—an AI-powered assistant tailored for infrastructure workflows based on Google DeepMind technology—which acts as an additional software engineer within your terminal.

The Multi-Project Modularity Challenge For this use case, the requirements demanded four distinct architectures designed to coexist within an enterprise ecosystem. The goal was clear: total isolation and automated scalability.

Base VPC (Core Networking): Implementation of custom networks with Private Google Access enabled for internal consumption of Google APIs without internet egress.

Private Data Workloads: Cloud SQL (MySQL) with restricted access via VPC Peering, eliminating any public IP exposure.

Resilient L7 Frontend: Global HTTP(S) Load Balancer supported by Managed Instance Groups (MIG) and perimeter protection via Cloud Armor.

Management Access (Bastion): e2-micro instances for administration, using strict tag-based routing.

Antigravity: Pair Programming "On Steroids" The true disruption of Antigravity lies not in static code generation, but in its ability to execute an iterative framework within the DevOps lifecycle.

Rather than generating isolated code, the agent operated as a collaborator aware of the repository and the Terraform lifecycle. While orchestrating the environments/dev directory, the agent autonomously structured:

The file architecture (main.tf, variables.tf, outputs.tf).

Initialization logic via CLI commands (terraform init and terraform fmt).

Selection of optimized images (Debian 11) to meet internal compliance policies.

Technical Architecture & Data Flow Below is a breakdown of the critical infrastructure components designed for this project.

A. Managed Database Isolation (Cloud SQL)
Exposing a database to the internet is an unacceptable risk. We utilized Private Services Access to connect our VPC with the Google Tenant Project.


+----------------------------------------------------+
| Your GCP Project (Consumer VPC)                    |
|                                                    |
|  +----------------------------------------------+  |
|  | VPC: "mysql-vpc-dev"                         |  |
|  |                                              |  |
|  |  [Global IP Range Reservation: /16]          |  |
|  |             |                                |  |
|  +-------------|--------------------------------+  |
|                |                                   |
|                v (Automatic VPC Peering)           |
|                                                    |
|  +----------------------------------------------+  |
|  | Google Managed Services (Tenant VPC)          |  |
|  |                                              |  |
|  |  +---------------------------------------+   |  |
|  |  | Cloud SQL Instance (MySQL 8.0)         |   |  |
|  |  | - IPv4_enabled: OFF                   |   |  |
|  |  | - Private IP (from reserved range)    |   |  |
|  |  +---------------------------------------+   |  |
|  +----------------------------------------------+  |
+----------------------------------------------------+

B. Next-Gen WAF Defenses via Cloud Armor
To protect backends, we delegate security to Google's Edge. Cloud Armor acts as a Layer 7 shield, filtering threats before they ever reach our compute instances.


              Inbound Web Traffic
                      |
                      v
       +-------------------------------+
       | Global HTTP Load Balancer     | 
       +--------------+----------------+
                      |
       +--------------v----------------+
       | Cloud Armor Security Policy   |  (L7 Filtering)
       | -> Blocks SQLi, XSS, LFI      |
       +--------------+----------------+
                      |
                      v (Sanitized Traffic)
+---------------------+-----------------------------------+
| Principal VPC                                           |
|   +-------------------------------------------------+   |
|   | Subnet                                          |   |
|   | Firewall: Allow ONLY Google LB IPs              |   |
|   |           (130.211.0.0/22 & 35.191.0.0/16)      |   |
|   |                                                 |   |
|   |   +-----------------------------------------+   |   |
|   |   | Managed Instance Group (MIG)            |   |   |
|   |   |  [ Apache Web Server VM - Debian 11 ]   |   |   |
|   |   +-----------------------------------------+   |   |
|   +-------------------------------------------------+   |
+---------------------------------------------------------+

Checkov: Closing the Governance Loop In a production workflow, compliance is vital. When integrating tools like Checkov, it is common to trigger security alerts. Antigravity helped us apply the Principle of Least Privilege, replacing default accounts with dedicated IAM Service Accounts.

For cases where the design required specific exceptions, the agent injected formal suppression syntax:

Terraform resource "google_compute_instance" "public_instance" { # checkov:skip=CKV_GCP_40: Public IP explicitly required for administrative bastion # checkov:skip=CKV_GCP_32: OS Login bypass authorized for this specific use-case name = "bastion-dev" machine_type = "e2-micro" ... }
Each exception was evaluated during the design phase and documented inline to preserve traceability and facilitate future audits.

The Future of Infrastructure The paquetesaction project demonstrates that the future of the cloud is hybrid: human strategic judgment amplified by AI execution speed. Our next steps involve expanding toward Vertex AI and consolidating security operations with Mandiant.

The infrastructure is code, and AI is its most powerful catalyst!

⚖️ Technical & Legal Safe Harbor Disclaimer
AUTHORSHIP AND INDEPENDENT CAPACITY: This publication is authored solely by me in my individual and private capacity. The views, methodologies, and technical workflows expressed herein are my own and do not necessarily reflect the official policy, position, or strategic direction of my current or former employers, clients, or any legal entity I am affiliated with.

INTELLECTUAL PROPERTY & CONFIDENTIALITY COMPLIANCE:

Independent Development: The workflows described are based on general industry best practices and were not developed as a "work for hire".

LIMITATION OF LIABILITY (NO WARRANTY): All code snippets and architectural patterns are provided "AS IS" without warranty of any kind.

COMPLIANCE: This contribution is made in good faith under the MIT-0 License for any included source code patterns.