A core Google-recommended practice is to deploy infrastructure changes progressively rather than all at once. Teams first apply changes to a small subset of resources, such as a few virtual machines in one zone, and monitor the effects before rolling out further. If issues arise, they can quickly revert to the previous stable state using automated rollback capabilities. This approach, often facilitated by Cloud Deploy, allows teams to diagnose problems in a controlled environment before a full rollout, treating infrastructure changes as high-risk operations that require careful validation.
Cloud Build and Deployment Manager work together to automate infrastructure changes. Cloud Build imports source code from repositories like GitHub, builds artifacts such as Docker containers, and stores them in Artifact Registry. Deployment Manager lets teams define infrastructure as code using configuration files, which describe the desired state of resources. Together, these services create automated CI/CD pipelines that apply changes reliably and consistently, reducing manual intervention and human error throughout the deployment process.
Teams should implement specific deployment blueprints to ensure reliability. Canary deployments gradually expose a new version to a small percentage of traffic, validating stability before a full switch. Rollback strategies enable pipelines to quickly revert to a known-good state if problems occur, which is critical for maintaining service availability. Environment promotion moves changes through a defined sequence from development to staging to production using managed services like Cloud Deploy, ensuring each stage validates the infrastructure before it reaches production.
Changes to global resources like VPC networks and global load balancers require extra caution because these resources can become single points of failure. Teams should classify changes to global resources as high-risk and require additional review and approval. Monitoring the availability of Google Cloud infrastructure itself uses tools like the Google Cloud Service Health Dashboard and Personalized Service Health, helping teams distinguish platform outages from application-level failures and informing their rollback decisions.
Deploying a secure framework requires GitOps tools to continuously manage and monitor infrastructure states. Config Sync automates the synchronization of configurations and policies across cluster fleets from a central source of truth, ensuring all registered clusters match the central repository state. Policy Controller enforces fully programmable policies using constraint templates, blocking non-compliant modifications before they can be applied. This declarative framework prevents configuration drift by continuously reconciling cluster resources with the desired state defined in Git repositories.
Following Google's Security Foundations Blueprint ensures that high-value assets and credentials remain secure across different environments. Secret Manager centralizes access control within dedicated, environment-specific projects like prj-c-secrets to strictly isolate sensitive data. Administrators must design pipelines toward Zero-Touch Production, which means making all production changes using automation or audited proxies. This approach minimizes human error, aligns with DevOps practices, and ensures every modification undergoes rigorous policy checks before reaching production.
Even in automated environments, organizations must prepare for pipeline failures by creating Breakglass Accounts that provide highly privileged, temporary access to IAM roles during emergencies. Platform teams can leverage Just-In-Time Access to allow engineers to self-escalate their permissions under strict, pre-approved guidelines. Configuring custom security alerts ensures that any deployment bypassing standard pipelines is immediately audited, providing visibility into exceptional access events while maintaining overall security posture.
Securing project bootstrapping requires isolating workloads and applying strict logical boundaries to project structures. Workload Identity Federation securely connects external identity providers with Google services when onboarding security telemetry platforms. Following the principle of Least Privilege, platform teams must strictly limit permissions to prevent unused and excessive role assignments across the organization. Establishing perimeters with VPC Service Controls blocks unauthorized access from outside the environment and actively mitigates data exfiltration risks by defining trust boundaries around sensitive resources.
Google recommends using declarative infrastructure to deploy foundations consistently and controllably. This approach enforces policy controls about acceptable resource configurations through automated pipelines. The deployment uses a GitOps flow where Terraform defines infrastructure as code, a Git repository provides version control and approval workflows, and Cloud Build handles CI/CD automation, maintaining audit trails for all infrastructure changes.
The deployment model separates responsibilities across three distinct pipeline layers. The foundation pipeline deploys shared resources used across the platform and is managed by a central team. The infrastructure pipeline handles projects and infrastructure like VM instances or databases for specific business units. The application pipeline deploys workload artifacts such as containers or images. This separation ensures different teams can manage their respective layers independently while maintaining organizational consistency.
Terraform operates by creating a state file that maps configuration resources to actual cloud infrastructure. When running terraform apply, the tool compares the existing infrastructure against the configuration file and determines what modifications are needed. This state management is critical for tracking changes over time and understanding the current infrastructure state. For team environments, storing state remotely in Cloud Storage provides benefits including state locking, team delegation, and improved security through centralized state management.
The provisioning workflow follows a systematic process where teams first describe desired infrastructure in Terraform configuration files, then run terraform plan to generate an execution plan, and finally execute terraform apply to provision resources. Each resource block describes infrastructure objects such as virtual networks, compute instances, or storage buckets. This declarative approach means users don't need to write code describing how to provision infrastructure—Terraform handles the implementation automatically based on the desired end state.
When provisioning IAM associations with Terraform, several resource types are available including google_*_iam_policy, google_*_iam_binding, and google_*_iam_member. The policy and binding resources create authoritative IAM associations where Terraform serves as the sole source of truth for permissions. However, this approach can overwrite roles automatically managed by Google Cloud, potentially disrupting service functionality. To prevent this, teams should use google_*_iam_member resources directly or Google's IAM module for more granular control over permissions.
Additional security best practices include baking virtual machine images using tools like Packer rather than using Terraform provisioners, which should be a last resort. When provisioners are unavoidable, they should include cleanup logic with when = destroy to manage old state properly. Organizations should implement the principle of least privilege when granting access, use IAM Recommender to identify over-privileged roles, and regularly review or automatically apply recommendations into deployment pipelines.
The Cloud Foundation Toolkit integrates Google-recommended best practices into reusable Terraform modules that teams can deploy consistently across their organization. These modules follow standard structure conventions including main.tf for resources, variables.tf for inputs, outputs.tf for results, and README.md for documentation. Proper module organization groups related resources together—for example, combining DNS managed zones and record sets in a dns.tf file rather than giving each resource its own file.
Naming conventions use underscores to delimit multiple words, matching the naming convention for resource types and predefined values. Variables representing numeric values like disk sizes should include units in their names such as ram_size_gb to make expected input units clear. Output values should reference resource attributes directly rather than passing through input variables to ensure implicit dependencies are created in the dependency graph. This structured approach enables teams to build maintainable, scalable infrastructure deployments that align with Google Cloud best practices.
Professional Cloud DevOps Engineer
Gauge your current knowledge
Gauge your current knowledge
StudyCerts
StudyCerts