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.

StudyCerts

Centralize Application Credentials Secret Manager Iam | 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! | StudyCerts

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

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Centralize Application Credentials Secret Manager Iam

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

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

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 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, 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 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.

Professional Cloud Architect

Centralize Application Credentials Secret Manager Iam

Related questions