Custom roles creation in GCP - Time & Space Complexity
When creating custom roles in GCP, it is important to understand how the time to create roles grows as you add more permissions.
We want to know how the number of permissions affects the time and operations needed to create a custom role.
Analyze the time complexity of creating a custom role with multiple permissions.
gcloud iam roles create myCustomRole \
--project=my-project \
--title="My Custom Role" \
--permissions=storage.buckets.get,storage.objects.list,compute.instances.start
This command creates a custom role with a list of permissions specified.
Look at what happens when adding permissions to the role.
- Primary operation: API call to create or update the custom role with all permissions.
- How many times: One API call per role creation, but the size of the permissions list affects the payload size.
As you add more permissions, the data sent in the API call grows linearly.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 1 API call with 10 permissions |
| 100 | 1 API call with 100 permissions |
| 1000 | 1 API call with 1000 permissions |
Pattern observation: The number of API calls stays the same, but the payload size grows with the number of permissions.
Time Complexity: O(n)
This means the time to create a custom role grows linearly with the number of permissions included.
[X] Wrong: "Creating a custom role with many permissions requires multiple API calls, one per permission."
[OK] Correct: Actually, all permissions are sent in a single API call, so the number of calls does not increase with permissions.
Understanding how API calls scale with input size helps you design efficient cloud operations and explain your reasoning clearly in interviews.
"What if we split permissions into multiple smaller roles instead of one big role? How would the time complexity change?"
Practice
custom role in Google Cloud Platform?Solution
Step 1: Understand role customization
Custom roles allow you to pick specific permissions instead of using broad predefined roles.Step 2: Identify the purpose of custom roles
They help tailor access to exactly what is needed, improving security and management.Final Answer:
To tailor permissions specifically for your project needs -> Option DQuick Check:
Custom roles = tailored permissions [OK]
- Thinking custom roles give all permissions automatically
- Confusing custom roles with deleting roles
- Assuming custom roles create resources
gcloud command syntax to create a custom role named myCustomRole in project my-project with the title "My Role" and permission storage.buckets.list?Solution
Step 1: Identify correct gcloud command structure
The correct command to create a custom role isgcloud iam roles createwith flags for project, title, permissions, and stage.Step 2: Match syntax with options
gcloud iam roles create myCustomRole --project=my-project --title="My Role" --permissions=storage.buckets.list --stage=GA matches the correct syntax including --project, --title, --permissions, and --stage flags.Final Answer:
gcloud iam roles create myCustomRole --project=my-project --title="My Role" --permissions=storage.buckets.list --stage=GA -> Option AQuick Check:
Correct gcloud create syntax = gcloud iam roles create myCustomRole --project=my-project --title="My Role" --permissions=storage.buckets.list --stage=GA [OK]
- Using 'gcloud iam create role' instead of 'roles create'
- Missing the --stage flag
- Incorrect flag order or missing equal signs
gcloud iam roles create dataViewer --project=my-project --title="Data Viewer" --permissions=bigquery.datasets.get,bigquery.tables.list --stage=ALPHA
What will be the effect of this custom role?
Solution
Step 1: Analyze permissions in the command
The permissionsbigquery.datasets.getandbigquery.tables.listallow reading dataset info and listing tables.Step 2: Understand what these permissions enable
These permissions let users view dataset metadata and see tables but not modify or delete them.Final Answer:
Allows users to get dataset metadata and list tables in BigQuery -> Option AQuick Check:
Permissions = read-only BigQuery access [OK]
- Assuming ALPHA stage means full access
- Confusing get/list with create/delete permissions
- Thinking it grants admin rights
gcloud iam roles create testRole --project=my-project --title="Test Role" --permissions=compute.instances.start,compute.instances.stop
But it failed. What is the most likely reason?
Solution
Step 1: Check required flags for role creation
The--stageflag is mandatory when creating custom roles to specify the release stage.Step 2: Identify missing flag in the command
The command lacks the--stageflag, causing failure.Final Answer:
Missing the --stage flag which is required -> Option CQuick Check:
--stage flag required = Missing the --stage flag which is required [OK]
- Ignoring the required --stage flag
- Assuming permissions are invalid
- Mistaking project ID or role ID format
Solution
Step 1: Identify permissions for listing buckets and reading objects
storage.buckets.listallows listing buckets, andstorage.objects.getallows reading objects.Step 2: Exclude delete permissions
Do not include anydeletepermissions to prevent deletion.Final Answer:
storage.buckets.list, storage.objects.get -> Option BQuick Check:
List + read, no delete = storage.buckets.list, storage.objects.get [OK]
- Including delete permissions by mistake
- Confusing create with list permissions
- Assuming read includes delete
Ready to prove it?
Pass the test and this pattern moves unknown
