Secret Manager for credentials in GCP - Step-by-Step Execution

Process Flow - Secret Manager for credentials

Create Secret

↓

Add Secret Version

↓

Access Secret

↓

Use Secret in App

↓

Rotate Secret (Optional)

↓

Delete Secret (Optional)

This flow shows how you create a secret, add versions, access it securely, use it in your app, and optionally rotate or delete it.

Execution Sample

GCP

gcloud secrets create my-db-password --replication-policy="automatic"
gcloud secrets versions add my-db-password --data-file=password.txt
gcloud secrets versions access latest --secret=my-db-password

This code creates a secret, adds a password version, and accesses the latest secret version.

Process Table

Step	Action	Input/Command	Result/Output	Notes
1	Create Secret	gcloud secrets create my-db-password --replication-policy="automatic"	Secret 'my-db-password' created	Secret container ready to hold versions
2	Add Secret Version	gcloud secrets versions add my-db-password --data-file=password.txt	Version 1 added to 'my-db-password'	Password stored securely
3	Access Secret	gcloud secrets versions access latest --secret=my-db-password	Outputs secret value (password)	App can retrieve secret when needed
4	Use Secret in App	App reads secret via API or CLI	App authenticates using secret	Secret never stored in code
5	Rotate Secret (Optional)	Add new version with updated password	New version added, old versions retained	Supports secret rotation without downtime
6	Delete Secret (Optional)	gcloud secrets delete my-db-password	Secret deleted permanently	Removes secret and all versions

💡 Process ends after secret is created, used, and optionally rotated or deleted.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5	Final
Secret Container	None	Created	Created with Version 1	Created with Version 1	Created with Versions 1 & 2	Deleted (optional)
Secret Versions	None	None	Version 1	Version 1	Versions 1 and 2	None (if deleted)
Secret Value	None	None	Password from password.txt	Password output on access	Updated password in Version 2	None (if deleted)

Key Moments - 3 Insights

Why do we add secret versions instead of replacing the secret?

Because each version is immutable and allows safe rotation without losing old secrets. See execution_table step 5 where a new version is added.

How does the app get the secret without storing it in code?

The app accesses the secret at runtime via API or CLI, as shown in execution_table step 3 and 4, keeping secrets out of code.

What happens if we delete the secret container?

All secret versions and values are permanently deleted, as shown in execution_table step 6 and variable_tracker final state.

Visual Quiz - 3 Questions

Look at the execution table, what is the result after Step 2?

A Version 1 added to the secret

B Secret container created with no versions

C Secret deleted

D Secret accessed and output shown

💡 Hint

Check the 'Result/Output' column for Step 2 in the execution_table.

At which step does the app use the secret to authenticate?

A Step 1

B Step 3

C Step 4

D Step 6

💡 Hint

Look at the 'Action' and 'Notes' columns in execution_table for app usage.

If you add a new secret version, what changes in the variable tracker?

A Secret container is deleted

B Secret versions increase by one

C Secret value becomes empty

D Secret container is recreated

💡 Hint

See 'Secret Versions' row in variable_tracker after Step 5.

Concept Snapshot

Secret Manager stores credentials securely.
Create a secret container.
Add secret versions to store values.
Access secrets at runtime, not in code.
Rotate secrets by adding new versions.
Delete secrets to remove all versions.

Full Transcript

This lesson shows how to use Google Cloud Secret Manager to store and manage credentials securely. First, you create a secret container. Then you add secret versions that hold the actual passwords or keys. Your app accesses these secrets at runtime via API or CLI, so secrets are never hardcoded. You can rotate secrets by adding new versions without downtime. Finally, you can delete secrets to remove all stored versions. The execution table traces each step from creation to usage and optional rotation or deletion. The variable tracker shows how secret containers and versions change over time. Key moments clarify why versions are immutable and how apps use secrets securely. The quiz tests understanding of these steps and states.

Practice

1. What is the main purpose of Google Cloud Secret Manager?

easy

A. To host websites and web applications

B. To securely store and manage sensitive information like passwords and API keys

C. To analyze large datasets quickly

D. To create virtual machines for computing tasks

Solution

1. Step 1: Understand Secret Manager's role

   Secret Manager is designed to keep sensitive data safe and accessible only to authorized users.

2. Step 2: Compare options with Secret Manager's function

   Options A, C, and D describe other cloud services, not Secret Manager.

3. Final Answer:

   To securely store and manage sensitive information like passwords and API keys -> Option B

4. Quick Check:

   Secret Manager = Secure storage [OK]

Hint: Secret Manager = safe storage for secrets [OK]

Common Mistakes:

• Confusing Secret Manager with compute or storage services
• Thinking it hosts websites or runs code
• Assuming it analyzes data

2. Which command correctly creates a new secret named db-password in Secret Manager?

easy

A. gcloud secrets create db-password --replication-policy="automatic"

B. gcloud secret create db-password --auto-replication

C. gcloud secrets add db-password --replication=auto

D. gcloud create secret db-password --replication-policy=manual

Solution

1. Step 1: Recall correct gcloud syntax for creating secrets

   The correct command uses gcloud secrets create with the secret name and replication policy.

2. Step 2: Check each option's syntax

   gcloud secrets create db-password --replication-policy="automatic" matches the correct syntax exactly. Options A, B, and C have incorrect command structure or flags.

3. Final Answer:

   gcloud secrets create db-password --replication-policy="automatic" -> Option A

4. Quick Check:

   Correct command syntax = gcloud secrets create db-password --replication-policy="automatic" [OK]

Hint: Use 'gcloud secrets create' with replication policy [OK]

Common Mistakes:

• Using 'secret' instead of 'secrets' in command
• Wrong flag names like --auto-replication
• Incorrect command order or missing quotes

3. Given this Python code snippet accessing a secret version:

from google.cloud import secretmanager
client = secretmanager.SecretManagerServiceClient()
name = "projects/my-project/secrets/api-key/versions/latest"
response = client.access_secret_version(name=name)
payload = response.payload.data.decode("UTF-8")
print(payload)

What will this code print if the secret value is supersecret123?

medium

A. supersecret123

B. b'supersecret123'

C. api-key

D. projects/my-project/secrets/api-key/versions/latest

Solution

1. Step 1: Understand the code flow

   The code accesses the latest version of the secret named 'api-key' and decodes the binary data to a UTF-8 string.

2. Step 2: Determine the printed output

   Since payload.data is decoded, the output is the plain string 'supersecret123', not bytes or other values.

3. Final Answer:

   supersecret123 -> Option A

4. Quick Check:

   Decoded secret value = 'supersecret123' [OK]

Hint: Decoded secret data prints as plain string [OK]

Common Mistakes:

• Printing raw bytes without decoding
• Confusing secret name with secret value
• Expecting metadata instead of secret content

4. You try to access a secret but get a permission denied error. What is the most likely cause?

medium

A. The secret value is empty

B. The secret does not exist in the project

C. The secret version is disabled

D. The service account lacks the Secret Manager Secret Accessor role

Solution

1. Step 1: Analyze permission denied error context

   Permission denied usually means the caller lacks rights to access the secret.

2. Step 2: Identify required role for access

   The Secret Manager Secret Accessor role grants permission to read secret versions. Without it, access is denied.

3. Final Answer:

   The service account lacks the Secret Manager Secret Accessor role -> Option D

4. Quick Check:

   Permission denied = missing access role [OK]

Hint: Check service account roles for Secret Accessor permission [OK]

Common Mistakes:

• Assuming secret absence causes permission error
• Ignoring secret version state
• Thinking empty secret causes permission denied

5. You want to rotate a database password stored in Secret Manager without downtime. Which approach is best?

hard

A. Manually update the password in the database and Secret Manager at the same time

B. Delete the old secret and create a new secret with the new password

C. Create a new secret version with the new password and update your app to use the latest version

D. Store the password in a config file instead of Secret Manager

Solution

1. Step 1: Understand secret rotation best practice

   Adding a new secret version allows smooth transition without deleting old data, avoiding downtime.

2. Step 2: Evaluate options for zero downtime

   Create a new secret version with the new password and update your app to use the latest version uses versioning and app update to switch secrets seamlessly. Delete the old secret and create a new secret with the new password deletes data causing downtime. Manually update the password in the database and Secret Manager at the same time risks inconsistency. Store the password in a config file instead of Secret Manager is insecure.

3. Final Answer:

   Create a new secret version with the new password and update your app to use the latest version -> Option C

4. Quick Check:

   Rotate by adding new version, not deleting [OK]

Hint: Rotate secrets by adding versions, not deleting old ones [OK]

Common Mistakes:

• Deleting secrets causing downtime
• Updating database and secret separately risking mismatch
• Storing passwords insecurely outside Secret Manager