An enterprise organization is modernizing a multi-tier web application deployed across Google Cloud compute services. The application currently loads third-party API keys, TLS certificates, and database passwords from local plaintext configuration files bundled inside the container images and source code repository. The security architect has established the following requirements: Sensitive configuration values and credentials must be completely decoupled from application source code and deployment images. The solution must centralize credential storage, support secret versioning for rotation, and provide access auditing. Applications must retrieve the plaintext credentials securely at runtime using the principle of least privilege. Which solution should the architect implement?

Store the credentials and certificates in Secret Manager, manage rotation through secret versions, and grant the application service account the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role.: What Secret Manager Is Secret Manager is a secure, fully-managed Google Cloud service designed specifically for the centralized storage, management, and auditing of sensitive data, such as API keys, passwords, TLS certificates, and database connection strings. How It Meets the Requirements Decoupling Sensitive Configuration: Storing credentials in Secret Manager removes hardcoded values and configuration files from container images and source code repositories. Versioning and Centralization: Secret Manager organizes data as first-class secret resources containing immutable, numbered secret versions. When credentials rotate, administrators add a new version without modifying code paths or redeploying infrastructure. Programmatic Access with Least Privilege: Applications authenticate using their attached service account via Application Default Credentials (ADC) and request secret payloads at runtime. Granting roles/secretmanager.secretAccessor provides the exact permission (secretmanager.versions.access) required to retrieve secret payloads without granting administrative management permissions. Auditing: Every retrieval and administrative action is recorded in Cloud Audit Logs, providing clear visibility into which identities access specific credentials. Key Advantages Automatic Payload Encryption: Secret payloads are encrypted at rest using AES-256 by default, with optional Customer-Managed Encryption Keys (CMEK). Granular IAM Control: Permissions can be applied at the project, folder, organization, or individual secret level. Native Integration: Works seamlessly with Google Cloud compute services (Compute Engine, GKE, Cloud Run) and orchestration workflows. Simple String and Binary Storage: Handles structured strings, base64 data, and binary certificates up to 64 KiB per secret version. Why This Is Optimal This solution directly satisfies all security mandates by separating sensitive metadata from application binaries, providing robust version management, and enforcing least-privilege runtime access with granular IAM roles.

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Intermediate

Prepare and test your skills

Centralized Runtime Secrets with Secret Manager

Section: Data security (key management, encryption, secret management)

...

Explanations

...

View source documentation

Keep the momentum going with these hand-picked practice scenarios

IntermediateProfessional Cloud Architect

An enterprise organizes its Google Cloud resource hierarchy into distinct folders for network infrastructure and business workloads. The Shared VPC host project resides in the Core-Networking folder, while multiple service projects containing Compute Engine virtual machines (VMs) reside in the App-Workloads folder. The central security team applies a hierarchical firewall policy to the Core-Networking folder that denies ingress TCP traffic on port 22. To allow remote access, a development team attaches another hierarchical firewall policy directly to the App-Workloads folder with a high-priority rule allowing ingress TCP traffic on port 22. However, SSH traffic to the VMs connected to the Shared VPC subnets remains blocked. Why is the ingress traffic on TCP port 22 still blocked on these VM instances?

Security controls (e.g., auditing, VPC Service Controls, context aware access, organization policy, and hierarchical firewall policy)

IntermediateProfessional Cloud Architect

Cloud Run vs GKE Refactoring Strategy

Cloud-first design approach

AdvancedProfessional Cloud DevOps Engineer

Your organization uses a GitOps workflow with Config Sync to manage Kubernetes resource manifests and security policies across multiple Google Kubernetes Engine (GKE) clusters. To prevent broken configurations and security policy regressions from reaching production clusters, you need to establish an automated gating and approval process with the following requirements: Manifest syntax and cluster configuration structure must be automatically validated whenever a pull request (PR) is opened against the configuration repository. Automated validation must pass successfully before human reviewers can approve the pull request. Merges into the protected repository branches used by the clusters must require explicit review and sign-off from designated platform and security team members. Which solution should you implement?

Configuring deployment processes (e.g., approval flows)

Want more questions like this?

Get a free certification question every week.

Last updated August 28, 2026

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Intermediate

Prepare and test your skills

Centralized Runtime Secrets with Secret Manager

Section: Data security (key management, encryption, secret management)

An enterprise organization is modernizing a multi-tier web application deployed across Google Cloud compute services. The application currently loads third-party API keys, TLS certificates, and database passwords from local plaintext configuration files bundled inside the container images and source code repository.

The security architect has established the following requirements:

Sensitive configuration values and credentials must be completely decoupled from application source code and deployment images.
The solution must centralize credential storage, support secret versioning for rotation, and provide access auditing.
Applications must retrieve the plaintext credentials securely at runtime using the principle of least privilege.

Which solution should the architect implement?

...

Store the credentials in an encrypted Cloud Storage bucket with Customer-Managed Encryption Keys (CMEK), and grant the application service account the Storage Object Viewer (roles/storage.objectViewer) role.

...

Store the credentials and certificates in Secret Manager, manage rotation through secret versions, and grant the application service account the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role.

...

Store the credentials and certificates in Cloud Key Management Service (Cloud KMS) as asymmetric cryptographic keys, and grant the application service account the Cloud KMS CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) role.

...

Store the credentials and certificates in Secret Manager, and assign the application service account the Secret Manager Admin (roles/secretmanager.admin) role to allow runtime configuration fetching.

...

Explanations

What Secret Manager Is

Secret Manager is a secure, fully-managed Google Cloud service designed specifically for the centralized storage, management, and auditing of sensitive data, such as API keys, passwords, TLS certificates, and database connection strings.

How It Meets the Requirements

Decoupling Sensitive Configuration: Storing credentials in Secret Manager removes hardcoded values and configuration files from container images and source code repositories.
Versioning and Centralization: Secret Manager organizes data as first-class secret resources containing immutable, numbered secret versions. When credentials rotate, administrators add a new version without modifying code paths or redeploying infrastructure.
Programmatic Access with Least Privilege: Applications authenticate using their attached service account via Application Default Credentials (ADC) and request secret payloads at runtime. Granting roles/secretmanager.secretAccessor provides the exact permission (secretmanager.versions.access) required to retrieve secret payloads without granting administrative management permissions.
Auditing: Every retrieval and administrative action is recorded in Cloud Audit Logs, providing clear visibility into which identities access specific credentials.

Key Advantages

Automatic Payload Encryption: Secret payloads are encrypted at rest using AES-256 by default, with optional Customer-Managed Encryption Keys (CMEK).
Granular IAM Control: Permissions can be applied at the project, folder, organization, or individual secret level.
Native Integration: Works seamlessly with Google Cloud compute services (Compute Engine, GKE, Cloud Run) and orchestration workflows.
Simple String and Binary Storage: Handles structured strings, base64 data, and binary certificates up to 64 KiB per secret version.

Why This Is Optimal

This solution directly satisfies all security mandates by separating sensitive metadata from application binaries, providing robust version management, and enforcing least-privilege runtime access with granular IAM roles.

...

View source documentation

Keep the momentum going with these hand-picked practice scenarios

IntermediateProfessional Cloud Architect

Cloud KMS Dedicated Key Project Architecture

Data security (key management, encryption, secret management)

IntermediateProfessional Cloud Architect

Customer-Managed Encryption Keys (CMEK)

Data security (key management, encryption, secret management)

IntermediateProfessional Cloud Architect

CMEK Service Agent CryptoKey Encrypter/Decrypter Role

Security and access management

IntermediateProfessional Cloud Architect

An enterprise organizes its Google Cloud resource hierarchy into distinct folders for network infrastructure and business workloads. The Shared VPC host project resides in the Core-Networking folder, while multiple service projects containing Compute Engine virtual machines (VMs) reside in the App-Workloads folder. The central security team applies a hierarchical firewall policy to the Core-Networking folder that denies ingress TCP traffic on port 22. To allow remote access, a development team attaches another hierarchical firewall policy directly to the App-Workloads folder with a high-priority rule allowing ingress TCP traffic on port 22. However, SSH traffic to the VMs connected to the Shared VPC subnets remains blocked. Why is the ingress traffic on TCP port 22 still blocked on these VM instances?

Security controls (e.g., auditing, VPC Service Controls, context aware access, organization policy, and hierarchical firewall policy)

IntermediateProfessional Cloud Architect

Cloud Run vs GKE Refactoring Strategy

Cloud-first design approach

AdvancedProfessional Cloud DevOps Engineer

Your organization uses a GitOps workflow with Config Sync to manage Kubernetes resource manifests and security policies across multiple Google Kubernetes Engine (GKE) clusters. To prevent broken configurations and security policy regressions from reaching production clusters, you need to establish an automated gating and approval process with the following requirements: Manifest syntax and cluster configuration structure must be automatically validated whenever a pull request (PR) is opened against the configuration repository. Automated validation must pass successfully before human reviewers can approve the pull request. Merges into the protected repository branches used by the clusters must require explicit review and sign-off from designated platform and security team members. Which solution should you implement?

Configuring deployment processes (e.g., approval flows)

Want more questions like this?

Get a free certification question every week.

Last updated August 28, 2026

An enterprise organization is modernizing a multi-tier web application deployed across Google Cloud compute services. The application currently loads third-party API keys, TLS certificates, and database passwords from local plaintext configuration files bundled inside the container images and source code repository.

The security architect has established the following requirements:

Sensitive configuration values and credentials must be completely decoupled from application source code and deployment images.
The solution must centralize credential storage, support secret versioning for rotation, and provide access auditing.
Applications must retrieve the plaintext credentials securely at runtime using the principle of least privilege.

Which solution should the architect implement?

Store the credentials in an encrypted Cloud Storage bucket with Customer-Managed Encryption Keys (CMEK), and grant the application service account the Storage Object Viewer (roles/storage.objectViewer) role.

Store the credentials and certificates in Secret Manager, manage rotation through secret versions, and grant the application service account the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role.

Store the credentials and certificates in Cloud Key Management Service (Cloud KMS) as asymmetric cryptographic keys, and grant the application service account the Cloud KMS CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) role.

Store the credentials and certificates in Secret Manager, and assign the application service account the Secret Manager Admin (roles/secretmanager.admin) role to allow runtime configuration fetching.

Store the credentials in an encrypted Cloud Storage bucket with Customer-Managed Encryption Keys (CMEK), and grant the application service account the Storage Object Viewer (roles/storage.objectViewer) role.

Store the credentials and certificates in Secret Manager, manage rotation through secret versions, and grant the application service account the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role.

What Secret Manager Is

Secret Manager is a secure, fully-managed Google Cloud service designed specifically for the centralized storage, management, and auditing of sensitive data, such as API keys, passwords, TLS certificates, and database connection strings.

How It Meets the Requirements

Decoupling Sensitive Configuration: Storing credentials in Secret Manager removes hardcoded values and configuration files from container images and source code repositories.
Versioning and Centralization: Secret Manager organizes data as first-class secret resources containing immutable, numbered secret versions. When credentials rotate, administrators add a new version without modifying code paths or redeploying infrastructure.
Programmatic Access with Least Privilege: Applications authenticate using their attached service account via Application Default Credentials (ADC) and request secret payloads at runtime. Granting roles/secretmanager.secretAccessor provides the exact permission (secretmanager.versions.access) required to retrieve secret payloads without granting administrative management permissions.
Auditing: Every retrieval and administrative action is recorded in Cloud Audit Logs, providing clear visibility into which identities access specific credentials.

Key Advantages

Automatic Payload Encryption: Secret payloads are encrypted at rest using AES-256 by default, with optional Customer-Managed Encryption Keys (CMEK).
Granular IAM Control: Permissions can be applied at the project, folder, organization, or individual secret level.
Native Integration: Works seamlessly with Google Cloud compute services (Compute Engine, GKE, Cloud Run) and orchestration workflows.
Simple String and Binary Storage: Handles structured strings, base64 data, and binary certificates up to 64 KiB per secret version.

Why This Is Optimal

This solution directly satisfies all security mandates by separating sensitive metadata from application binaries, providing robust version management, and enforcing least-privilege runtime access with granular IAM roles.

Store the credentials and certificates in Cloud Key Management Service (Cloud KMS) as asymmetric cryptographic keys, and grant the application service account the Cloud KMS CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) role.

Store the credentials and certificates in Secret Manager, and assign the application service account the Secret Manager Admin (roles/secretmanager.admin) role to allow runtime configuration fetching.

Professional Cloud Architect

Centralized Runtime Secrets with Secret Manager

Related questions

Cloud KMS Dedicated Key Project Architecture

Customer-Managed Encryption Keys (CMEK)

CMEK Service Agent CryptoKey Encrypter/Decrypter Role

Cloud Run vs GKE Refactoring Strategy

Professional Cloud Architect

Centralized Runtime Secrets with Secret Manager

What Secret Manager Is

How It Meets the Requirements

Key Advantages

Why This Is Optimal

Related questions

Cloud KMS Dedicated Key Project Architecture

Customer-Managed Encryption Keys (CMEK)

CMEK Service Agent CryptoKey Encrypter/Decrypter Role

Cloud Run vs GKE Refactoring Strategy

What Secret Manager Is

How It Meets the Requirements

Key Advantages

Why This Is Optimal