Service account keys management in GCP - Time & Space Complexity
When managing service account keys, it's important to understand how the number of keys affects the time it takes to list, create, or delete them.
We want to know how the work grows as we handle more keys.
Analyze the time complexity of the following operation sequence.
// List all keys for a service account
keys = iam.projects.serviceAccounts.keys.list({
name: 'projects/-/serviceAccounts/service-account-email'
})
// Delete each key one by one
for (const key of keys.keys) {
iam.projects.serviceAccounts.keys.delete({
name: key.name
})
}
// Create a new key
newKey = iam.projects.serviceAccounts.keys.create({
name: 'projects/-/serviceAccounts/service-account-email'
})
This sequence lists all keys, deletes them one by one, then creates a new key for a service account.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Deleting each service account key individually.
- How many times: Once per existing key, so the number grows with the number of keys.
As the number of keys increases, the number of delete calls grows directly with it.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | List (1) + Delete (10) + Create (1) = 12 |
| 100 | List (1) + Delete (100) + Create (1) = 102 |
| 1000 | List (1) + Delete (1000) + Create (1) = 1002 |
Pattern observation: The total operations increase roughly in direct proportion to the number of keys.
Time Complexity: O(n)
This means the time to manage keys grows linearly with the number of keys you have.
[X] Wrong: "Deleting all keys happens in one single API call regardless of how many keys exist."
[OK] Correct: Each key must be deleted individually, so the number of delete calls grows with the number of keys.
Understanding how operations scale with resource count shows you can plan and manage cloud resources efficiently, a key skill in real projects.
"What if we batch delete keys in groups instead of one by one? How would the time complexity change?"