A DevOps team is developing a continuous integration and continuous delivery (CI/CD) pipeline using Cloud Build to automate project environment bootstrapping and resource configuration. The workflow must execute custom Python automation scripts that interact with Google Cloud APIs and configure external third-party services. The pipeline implementation must satisfy the following criteria: Securely provide sensitive third-party API credentials to the Python automation scripts during pipeline execution without leaking tokens in build logs, artifacts, or repository source code. Grant the Cloud Build execution identity minimum required permissions to read credentials dynamically. Execute the Python provisioning script and follow with an automated validation test step to verify infrastructure health. How should the team design the Cloud Build configuration and Python automation workflow?

Store the credentials in Secret Manager, grant the Cloud Build service account the Secret Manager Secret Accessor role, reference the secret in the availableSecrets configuration block of cloudbuild.yaml to expose it securely via an environment variable, and access it in the Python script at execution time.: ### What the Solution Is **Secret Manager** is Google Cloud's fully managed service designed to store, manage, and access sensitive metadata and operational credentials. Integrating Secret Manager natively with **Cloud Build** allows build steps to inject secrets into memory as environment variables or retrieve them dynamically via API clients. ### How It Meets the Requirements - **Secure credential handling:** Secret Manager maintains centralized, versioned secrets with fine-grained encryption. Referencing secrets using Cloud Build's native `availableSecrets` block ensures tokens are mounted directly into containerized build step environments rather than stored in cleartext source files or configuration manifests. - **Preventing log leaks:** When credentials are bound as secret environment variables in Cloud Build, their runtime values are kept isolated to the execution process and are not emitted into the build execution logs or stored in build artifacts. - **Least privilege access:** Granting the Cloud Build service account the specific **Secret Manager Secret Accessor** (`roles/secretmanager.secretAccessor`) role limits permissions to reading only the necessary secret payload without granting broader administrative rights. - **Automation and validation:** The Python script reads the credential securely from memory using standard environment inspection (e.g., `os.environ['SECRET_KEY']`) or the Secret Manager client library to provision infrastructure, after which a secondary test step validates the environment. ### Key Advantages - **Native CI/CD Integration:** Integrates cleanly into `cloudbuild.yaml` without needing custom decryption tooling. - **Audit Logging:** Every secret version access triggers Cloud Audit Logs for compliance tracking. - **Lifecycle Management:** Facilitates easy credential rotation without requiring updates to pipeline definitions or application code. - **Fine-Grained IAM:** Permissions can be scoped down to individual secrets rather than an entire project. ### Why This Is Optimal This approach aligns with Google Cloud security best practices by separating configuration from credentials, leveraging native service-level IAM controls, and preventing secret exposure across CI/CD log streams.

Cloud Build Secret Manager Script Integration 2 | Professional Cloud DevOps Engineer

Cloud Build Secret Manager Script Integration 2

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.

A DevOps team is developing a continuous integration and continuous delivery (CI/CD) pipeline using Cloud Build to automate project environment bootstrapping and resource configuration. The workflow must execute custom Python automation scripts that interact with Google Cloud APIs and configure external third-party services.

The pipeline implementation must satisfy the following criteria:

Securely provide sensitive third-party API credentials to the Python automation scripts during pipeline execution without leaking tokens in build logs, artifacts, or repository source code.
Grant the Cloud Build execution identity minimum required permissions to read credentials dynamically.
Execute the Python provisioning script and follow with an automated validation test step to verify infrastructure health.

How should the team design the Cloud Build configuration and Python automation workflow?

Store the credentials in Secret Manager, grant the Cloud Build service account the Secret Manager Secret Accessor role, reference the secret in the availableSecrets configuration block of cloudbuild.yaml to expose it securely via an environment variable, and access it in the Python script at execution time.

Define custom user substitution variables (e.g., _API_KEY) in the Cloud Build trigger definition, pass the plaintext credentials as build arguments to the Python step, and verify infrastructure health using inline shell assertions.

Upload a credentials JSON file to a private Cloud Storage bucket, grant the Cloud Build service account Storage Object Viewer permissions, and download the credentials file into the build workspace prior to executing Python scripts.

Encrypt the credentials with a Cloud KMS symmetric key, commit the encrypted ciphertext string into the Git repository, and grant the Cloud Build service account Cloud KMS CryptoKey Encrypter/Decrypter permissions to decrypt the payload on workspace disk.

Professional Cloud DevOps Engineer

Cloud Build Secret Manager Script Integration 2

Related questions