Professional Cloud Developer
Professional Cloud Developer
Intermediate
Gauge your current knowledge
Intermediate
Gauge your current knowledge
Designing secure applications
...
Professional Cloud Developer
Gauge your current knowledge
Gauge your current knowledge
Google Cloud Storage provides tools to protect critical business records by controlling how files are updated, saved, and deleted. When managing specific files, developers can apply an object retention policy to set a RetainUntilTime, which is a specific date and time until which the object must be kept. These policies can run in modes like Unlocked, which allows administrators to increase the retention period or delete the policy if needed.
When users update or overwrite files, object versioning preserves historical data states by keeping older versions of each file. If a file is accidentally deleted or overwritten, developers can use these archived versions to restore the data to its previous state. To block deletion during audits or litigation, you can place a legal hold on an object, which acts as a temporary freeze overriding any existing lifecycle rules or retention policies until the hold is manually removed.
Choosing the correct Cloud Storage class is essential for balancing operational performance against storage costs. Google Cloud offers four main classes: Standard for frequently accessed data, Nearline for monthly access, Coldline for quarterly access, and Archive for yearly access. While colder storage classes offer significantly lower monthly storage rates, they introduce higher read latency, retrieval fees, and minimum storage durations.
When planning to transition data to colder tiers, developers must evaluate the minimum storage durations, which range from 30 days for Nearline up to 365 days for Archive. If an object is deleted or moved before its class's minimum duration is met, Cloud Storage charges an early deletion fee. Access frequency also determines cost-efficiency, as frequent reads from Archive or Coldline tiers can quickly incur high retrieval charges that outweigh any storage savings.
Object Lifecycle Management allows developers to automate data organization and cost-control policies within Google Cloud Storage. You configure these automation policies by pairing specific conditions with actions, such as moving a file to a colder tier or deleting it permanently. Because these rules execute automatically, they eliminate the need for manual cleanup scripts.
The lifecycle engine evaluates objects using metadata conditions to determine when an action should trigger. Developers can define conditions using criteria such as Age (the number of days since an object was created), IsLive (whether the object is the most active version or an archived historical version), and MatchesStorageClass (objects currently residing in a specific storage tier). When a condition is met, Cloud Storage executes the assigned action, which is typically to transition the object to a colder storage class or to delete it.
Applying retention policies to a storage bucket enforces a Write Once, Read Many (WORM) standard, which is critical for meeting strict legal and regulatory requirements. A WORM policy prevents users, including administrators, from deleting or modifying objects until a specified retention period has elapsed.
To make these compliance rules permanent, developers can apply a Bucket Lock to the retention policy. Once a Bucket Lock is active, the policy cannot be deleted, shortened, or disabled under any circumstances. The only way to remove a locked bucket is to delete the entire bucket, which is only allowed after every single object inside has completed its mandatory retention duration. While administrators can increase the retention duration of a locked policy, they can never decrease it, creating an irreversible commitment to data preservation.
Identity-Aware Proxy (IAP) provides context-aware access to applications and virtual machines without needing a traditional VPN. It works by verifying a user's identity and the specific conditions of their request, such as the security status of their device or their geographic location. With IAP TCP-forwarding, developers can securely reach administrative services like SSH while keeping those resources hidden from the public internet.
IAP implements a Zero-Trust Architecture by shifting security from the network perimeter to individual users and devices. Instead of relying on traditional firewalls, IAP uses centralized access control to verify a user's identity and the context of their request. This ensures that only authorized users can reach protected web applications and virtual machines, regardless of their network location.
Context-aware access uses the Access Context Manager to analyze security signals before granting entry. These signals include the user's identity, geographic location, and device posture—the security health and management status of the hardware. When combined with Chrome Enterprise Premium, administrators can enforce strict rules that block access from unmanaged or untrusted devices.
The Web Security Scanner is a specialized tool that identifies security risks in public-facing web applications. It supports environments like App Engine, Compute Engine, and Google Kubernetes Engine (GKE). The scanner focuses on critical issues such as Cross-Site Scripting (XSS) and insecure libraries, and it also looks for misconfigurations that attackers could exploit.
Users can perform scans on-demand or set them up on a scheduled basis through the Google Cloud console. For more advanced workflows, Security Scanner APIs allow teams to automate security testing within their application build pipelines. Scan results are integrated into the Security Command Center, providing a centralized view of an organization's security posture.
Applying the principle of least privilege is an essential strategy for hardening cloud services. This practice grants users and service accounts only the IAM roles they strictly need at the smallest possible scope. Organizations should restrict the use of long-lived service account keys and instead use short-lived, temporary credentials.
VPC Service Controls provide a resource-centric defense by creating a security perimeter around sensitive data and services. This perimeter prevents data from being moved to unauthorized locations even if a user has valid login credentials. Within a container environment, Cloud Service Mesh uses mutual TLS (mTLS) to encrypt and authenticate all communication between services. Additional hardening mechanisms include Binary Authorization, which ensures only trusted container images are deployed, and Kubernetes Network Policies, which limit traffic between application components.
Security Command Center (SCC) serves as the central hub for monitoring and managing security findings across all Google Cloud resources. It brings together several built-in services to identify different types of risks: Security Health Analytics finds common resource misconfigurations, Web Security Scanner detects vulnerabilities in web applications, and Event Threat Detection monitors logs for signs of active attacks or malware.
To help teams focus on the most critical issues, SCC calculates attack exposure scores based on how easily a vulnerability can be reached and how important the affected resource is. You can also define high-value resource sets to ensure your most sensitive data receives the highest priority during a security event. Managing the progress of fixes is done through security marks, which allow you to label assets and track remediation progress, while mute rules help reduce noise by filtering out findings that don't require action.
Automation in cloud security helps teams manage complex environments while maintaining high safety standards. By building automated CI/CD pipelines, developers can remove manual errors and create standardized feedback loops for security. These pipelines detect and fix security bugs early in the software lifecycle, ensuring that security requirements are met consistently before any code reaches production.
Binary Authorization acts as a critical policy enforcement gate that prevents untrusted code from being deployed. It uses attestations, which are digital signatures, to confirm that a container image has passed all required security checks before it can run on platforms like Google Kubernetes Engine or Cloud Run. This service verifies that a specific build system created the image, validates that images comply with vulnerability policies, and ensures images pass all criteria for promotion to production.
Artifact Analysis automatically scans container images stored in Artifact Registry for security flaws when they are uploaded. It identifies vulnerabilities in OS packages and programming languages such as Java and Go. The service provides continuous monitoring, meaning if a new threat is discovered after an image is stored, the system updates the image metadata to alert the development team immediately.
The Security Command Center also includes Container Threat Detection, which monitors for suspicious activity like malware or malicious scripts while a container is running. When a vulnerability is identified, developers must implement remediation strategies such as updating base images to a newer secure version, applying security patches within the CI/CD pipeline, or using distroless images to minimize the components in a container and reduce the attack surface.
Secret Management is the process of safely storing and handling sensitive data like passwords, API keys, and certificates. In the cloud, it is essential to protect these credentials from being exposed in application code or configuration files. Using a centralized system allows applications to retrieve the data they need securely without storing the secrets themselves.
Secret Manager is a secure storage system for sensitive configuration data. It uses Version Control, which lets you track different versions of a secret and roll back to a previous version if needed. You can also define Granular Access Policies using IAM to control exactly which users or services can view or modify a secret. Automated Rotation is a key security practice where secrets are automatically updated on a schedule, minimizing the risk if a credential is stolen because its useful lifespan is shortened.
Workload Identity Federation eliminates the need for long-lived service account keys, which are hard to manage and pose a security risk if leaked. It establishes a trust relationship between Google Cloud and an external identity provider (like AWS, Azure, or GitHub). Applications outside Google Cloud can then use short-lived credentials from their provider to securely access Google Cloud resources.
The process works through a secure token exchange. An application first gets an identity token (like an OIDC token) from its external provider. It sends this token to Google's Security Token Service, which verifies it and issues a short-lived federated token. This token allows the application to impersonate a Google Cloud service account, providing keyless, temporary access. You manage these external identities using workload identity pools and providers, where a pool is a container for external identities and a provider defines the connection to a specific external identity source.
While Google encrypts data by default, Cloud Key Management Service (KMS) allows you to use Customer-Managed Encryption Keys (CMEK). This gives you control over the key's lifecycle, its geographic location, and its rotation schedule. Using CMEK is often required to meet specific compliance standards and provides a stronger cryptographic boundary for your sensitive data.
Envelope Encryption is a pattern used to efficiently protect large datasets. A powerful Key Encryption Key (KEK), which you manage in Cloud KMS, is used to encrypt a simpler "data encryption key." The data itself is then encrypted with that data key. This means even if the data key is exposed, it remains useless without the master KEK stored securely in KMS. For many services, the Key Ring and CMEK must be located in the same Google Cloud region as the resource they protect.
Google Cloud manages three main types of identities: corporate identities for employees, customer identities for app users, and service identities for applications. Identity and Access Management (IAM) is the framework that controls which individuals can access which resources, and centralized identity management lets organizations enforce security policies like multi-factor authentication across all user types.
When applications need to communicate, they use different types of tokens to prove who they are. OAuth 2.0 access tokens are used for authorization, letting an application access specific API resources. In contrast, OpenID Connect (OIDC) ID tokens are used for authentication to verify the identity of the user. Identity Platform provides customer identity and access management (CIAM) for managing end-users, supporting multi-tenancy, social sign-on, multi-factor authentication, and custom claims for fine-grained access control.
Application Default Credentials (ADC) is a strategy Google client libraries use to automatically find credentials for authenticating with Google Cloud services. This process allows developers to write code that works across different environments without changing the authentication logic. ADC searches for credentials in a specific order, starting with the GOOGLE_APPLICATION_CREDENTIALS environment variable and ending with the internal metadata server.
For local development, you can set up ADC using your own user account by running the gcloud auth application-default login command. Using your own credentials for local testing is more secure than creating and downloading service account keys. When running applications in production on Google Cloud, the preferred method is to use an attached service account, where ADC automatically communicates with the metadata server to retrieve credentials for the resource.
The Cloud SQL Auth Proxy and AlloyDB Auth Proxy establish secure, encrypted connections to managed databases. These proxies create a secure TCP tunnel that handles authentication through IAM, removing the need for manual SSL configuration. These proxies provide strong encryption by automatically handling TLS certificates, integrate with IAM to control who can connect using existing Google Cloud permissions, and simplify networking by eliminating the need to manage complex firewall rules.
IAM Database Authentication lets applications connect using Google Cloud identities instead of traditional static passwords, providing unified access control across all cloud resources. Using short-lived access tokens significantly reduces the risk of credential theft compared to long-term database credentials. Private Service Connect allows traffic to stay within the Google Cloud network, avoiding risks associated with the public internet.
Service accounts are special identities used by applications and workloads, not by people. To keep them secure, you should prioritize using short-lived credentials instead of permanent secrets. The preferred method for this is Workload Identity Federation, which lets workloads running on platforms like Google Kubernetes Engine (GKE) or external clouds like AWS use temporary tokens. This approach removes the need for static service account keys, which are a major security risk because they do not expire and can be easily leaked.
You should create single-purpose service accounts for each unique application, following the principle of least privilege. This means each account gets only the permissions it needs to perform its specific job, which limits the damage if an account is compromised. Regularly auditing your environment is necessary to find and remove unused service accounts.
Applying the principle of least privilege means granting only the minimum permissions a service account needs to function. You do this by using Identity and Access Management (IAM) roles, which are bundles of permissions. You should choose between predefined roles (created and managed by Google) and custom roles (which you create from specific permissions) for precise control. Avoid using broad basic roles like Editor or Owner, as they often grant far more access than an application needs.
To keep permissions tight over time, you can use the IAM Recommender, which uses machine learning to find permissions that a service account is not using and suggests removing them. Regularly reviewing these recommendations prevents permission creep as your application evolves.
The Google Cloud resource hierarchy organizes your resources in a tree: Organization at the top, then Folders, then Projects, and finally individual resources. IAM policies set at a higher level, like a folder, are automatically inherited by all the child resources below it. This structure makes it easy to manage security broadly, but you must be careful to avoid granting over-privileged access across many projects.
To prevent over-privileged access, you should implement granular role bindings at the most specific resource level possible. Instead of granting a powerful role at the organization level, grant a more limited role directly to the specific project or resource where it is needed. This practice follows the principle of least privilege and ensures that a compromised service account can only affect a limited part of your environment.
A Zero-Trust Security Model means no service is trusted by default, even if it's already inside your network. In Google Kubernetes Engine (GKE), you enforce this using Kubernetes Network Policies. These policies act like a firewall specifically for your application Pods. By default, all Pods in a cluster can talk to each other, which is a security risk. To be secure, you must write rules that only allow the specific traffic your services need to work.
These policies control traffic based on labels you assign to your Pods. You create Ingress rules to define who can send traffic to a Pod and Egress rules to define where a Pod can send traffic to. For the best performance and visibility, use GKE Dataplane V2, which handles the network policy rules very efficiently and includes Network Policy Logging to see exactly which connection attempts are being allowed or blocked.
When you build applications, you often want your services to talk to each other without using the public internet. This Private Connectivity keeps your data secure and within Google's network. For serverless services like Cloud Run or Cloud Functions, you use a tool called Serverless VPC Access, which creates a connector that lets these serverless workloads securely reach resources inside your Virtual Private Cloud (VPC).
To connect to Google's managed services (like Cloud SQL or a private API) privately, you use Private Service Connect. Instead of using a public URL, you connect to the service using a private IP address from your own VPC network. For the highest level of data protection, you can combine these tools with VPC Service Controls, which creates a service perimeter—a security fence around your resources that prevents data from being accidentally copied or moved outside this perimeter.
Cloud Service Mesh (CSM) is a system designed to secure communication between all your microservices. It applies Zero-Trust principles by automatically encrypting traffic and checking identities. A key feature is mutual TLS (mTLS), which ensures that every service proves its identity to another before they communicate. This means both the sender and receiver have a certificate, preventing anyone from eavesdropping on or impersonating your services.
CSM manages all the complex security details for you. It uses a managed Certificate Authority to automatically create, distribute, and rotate security certificates for every workload. Beyond just encrypting traffic, CSM lets you set detailed authorization policies that control which services are allowed to talk to each other, based on their identity.
Service accounts are special identities used by applications and workloads instead of people. To build secure applications, developers must follow the principle of least privilege, which means giving an identity only the exact permissions it needs to do its job. By limiting access, you reduce the risk of a security breach spreading through your system, which minimizes the "attack surface" of your cloud-native applications.
When you enable certain services, Google Cloud often creates default service accounts that may automatically receive broad permissions like the Editor role. These primitive roles are often too powerful and create security risks if the account is ever compromised. It is a best practice to disable automatic role grants for these accounts and instead evaluate the specific needs of each application.
User-managed service accounts are the preferred choice for running secure services because they are created for a single purpose. You should create a unique service account for each application to keep their permissions separate. Key benefits of this strategy include isolation (problems in one app do not affect others), auditing (you can easily see which app performed a specific action), and control (you can revoke access for one service without stopping others).
To build secure cloud-native applications, developers must follow the principle of least privilege. This means giving a service only the minimum permissions it needs to perform its specific tasks. Instead of granting access to an entire project, you should apply IAM policies at the most granular level possible. Restricting access to specific resources like a single Cloud Storage bucket helps protect sensitive data from unauthorized users.
Applying resource-level scoping is a key strategy to prevent lateral movement within a cloud environment. If a bad actor compromises one part of your system, resource-level restrictions ensure they cannot easily jump to other sensitive areas. By using this method, you create a smaller attack surface for your application.
Workload Identity is a secure way to manage how applications running on Google Cloud access other services. Instead of using permanent passwords, you use a Service Account, which acts as an identity for a piece of code rather than a person. When running code on resources like Compute Engine, the preferred authentication method is to attach a service account directly to that resource, allowing the application to automatically use the service account's credentials to prove its identity to Google APIs.
To further improve security, developers should use Workload Identity Federation for applications running outside of Google Cloud or in GKE. This process provides ephemeral credentials, which are temporary and expire quickly, instead of using long-lived service account keys that could be stolen. By using these temporary tokens, you significantly minimize the attack surface of your cloud-native applications.
Binary Authorization is a security service in Google Cloud that checks container images at deploy time before they run in environments like Google Kubernetes Engine (GKE) or Cloud Run. The core of the system is a policy — a set of rules that decides whether a particular image is allowed to deploy. By setting up these policies, teams can protect their software supply chain and stop untrusted or unauthorized images from reaching production.
Every policy uses an Evaluation Mode to decide how to handle a deployment request. There are three modes: Allow all images (any container can deploy without restriction), Disallow all images (every deployment is blocked by default), and Require attestations (a digital signature from a trusted Attestor is needed before the image is cleared). The Enforcement Mode determines what happens when an image fails the policy rules. In Block and Audit Log mode, the system refuses to deploy the image and records the event in the logs. In Dry Run: Audit Log Only mode, the image is allowed to deploy even if it violates the policy.
Binary Authorization works closely with Artifact Analysis, a service that stores metadata about container images, such as build details and vulnerability scan results. Together, they form a gatekeeper that checks images for security flaws before they are deployed. You can create a policy that requires an image to be scanned and verified before it can run in production.
A policy in this context defines rules that often require attestors — trusted authorities that verify that a specific process was completed. Key components include Attestations (digital signatures that confirm an image is ready for the next stage), Attestors (Google Cloud resources that verify those signatures at deploy time), and Rules (specific requirements that an image must meet to pass). For emergencies, the Breakglass feature lets administrators temporarily bypass the policy and deploy a critical fix, and every use of breakglass is recorded in the audit logs for later review.
At the heart of Binary Authorization is the attestor, a verification authority that confirms an image has passed specific security requirements. Attestors can represent manual approvals from security teams or automated checks from a build system. They act as gatekeepers for your production environment.
To ensure the integrity of approvals, Binary Authorization uses cryptographic verification with digital signatures. A signer uses a private key to create an attestation — a digital signature linked to a specific container image digest. The corresponding public key is stored in the attestor so the system can verify the signature at deploy time. Using Cloud Key Management Service (KMS) is the recommended way to manage these keys because it provides a secure, centralized platform for handling sensitive cryptographic material.