Security design principles in GCP - Time & Space Complexity

Time Complexity: Security design principles

O(n * m)

Understanding Time Complexity

When designing security in cloud systems, it is important to understand how the effort and checks grow as the system grows.

We want to know how the number of security checks or operations changes as we add more resources or users.

Scenario Under Consideration

Analyze the time complexity of applying security policies to multiple cloud resources.

// Pseudocode for applying IAM roles to resources
for each resource in resource_list:
  for each user in user_list:
    grant IAM role to user on resource

This sequence assigns security roles to each user for every resource in the cloud project.

Identify Repeating Operations

Identify the API calls, resource provisioning, data transfers that repeat.

• Primary operation: Granting IAM role to a user on a resource (API call)
• How many times: Once for every user-resource pair

How Execution Grows With Input

As the number of users and resources grows, the total number of role assignments grows by multiplying these two numbers.

Input Size (n users, m resources)	Approx. API Calls/Operations
10 users, 10 resources	100
100 users, 100 resources	10,000
1000 users, 1000 resources	1,000,000

Pattern observation: The number of operations grows quickly as both users and resources increase.

Final Time Complexity

Time Complexity: O(n * m)

This means the work grows proportionally to the number of users times the number of resources.

Common Mistake

[X] Wrong: "Adding more users or resources only adds a small, fixed amount of security work."

[OK] Correct: Each user needs permissions on each resource, so the total work multiplies, not just adds.

Interview Connect

Understanding how security operations scale helps you design systems that stay manageable as they grow.

Self-Check

"What if we grouped users and assigned roles to groups instead of individual users? How would the time complexity change?"

Practice

1. Which security design principle means giving users only the access they need and nothing more?

easy

A. Secure by default

B. Defense in depth

C. Continuous monitoring

D. Least privilege

Solution

1. Step 1: Understand the principle of least privilege

   Least privilege means users get only the minimum access needed to do their job.

2. Step 2: Compare with other principles

   Defense in depth means multiple layers of security, secure by default means safe settings initially, monitoring means watching for issues.

3. Final Answer:

   Least privilege -> Option D

4. Quick Check:

   Minimum access = Least privilege [OK]

Hint: Minimum access means least privilege [OK]

Common Mistakes:

• Confusing defense in depth with least privilege
• Thinking secure by default means limited access
• Mixing monitoring with access control

2. Which of the following is the correct way to assign a role to a user in GCP IAM using the gcloud CLI?

easy

A. gcloud iam roles assign [e-mail] roles/viewer

B. gcloud iam add-role [e-mail] viewer

C. gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer

D. gcloud iam set-role [e-mail] roles/viewer

Solution

1. Step 1: Recall correct gcloud command syntax for IAM role assignment

   The correct command uses 'projects add-iam-policy-binding' with --member and --role flags.

2. Step 2: Check each option

   gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer matches the correct syntax; others use invalid commands or flags.

3. Final Answer:

   gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer -> Option C

4. Quick Check:

   IAM role assignment uses add-iam-policy-binding [OK]

Hint: Use add-iam-policy-binding with --member and --role [OK]

Common Mistakes:

• Using incorrect gcloud commands like 'iam roles assign'
• Omitting --member or --role flags
• Confusing roles with users in command syntax

3. Consider this GCP IAM policy snippet:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user:[e-mail]"]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": ["user:[e-mail]"]
    }
  ]
}

What access does Alice have on the storage bucket?

medium

A. Full control including deleting objects

B. Read-only access to objects

C. No access at all

D. Can create and delete buckets

Solution

1. Step 1: Identify Alice's assigned role

   Alice has the role 'roles/storage.objectViewer' which grants read-only access to objects.

2. Step 2: Understand role permissions

   ObjectViewer allows viewing objects but not modifying or deleting them.

3. Final Answer:

   Read-only access to objects -> Option B

4. Quick Check:

   ObjectViewer = read-only access [OK]

Hint: Viewer roles mean read-only access [OK]

Common Mistakes:

• Confusing objectAdmin with objectViewer
• Assuming viewer can delete objects
• Mixing bucket-level and object-level permissions

4. You wrote this IAM policy JSON but get an error when applying it:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user:[e-mail]"]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": ["[e-mail]"]
    }
  ]
}

What is the error and how to fix it?

medium

A. Missing 'user:' prefix before bob's email in members; add 'user:'

B. Role 'roles/storage.objectAdmin' does not exist; use 'roles/storage.admin'

C. JSON syntax error; remove trailing commas

D. Members list must be empty for objectAdmin role

Solution

1. Step 1: Check members format in IAM policy

   Each member must have a prefix like 'user:', 'serviceAccount:', etc.

2. Step 2: Identify the missing prefix for [e-mail]

   Bob's member entry lacks 'user:' prefix, causing the error.

3. Final Answer:

   Missing 'user:' prefix before bob's email in members; add 'user:' -> Option A

4. Quick Check:

   Member identifiers need prefixes like 'user:' [OK]

Hint: Always prefix members with user: or serviceAccount: [OK]

Common Mistakes:

• Omitting user: prefix in members list
• Assuming roles names are incorrect without checking
• Misreading JSON syntax errors

5. You want to design a GCP project with strong security. Which combination of principles and practices best protects your resources?

hard

A. Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing

B. Use secure by default settings only, no need for monitoring or role restrictions

C. Grant all users owner role for flexibility, disable monitoring to reduce noise, and use default network settings

D. Assign broad roles to users, enable audit logging, and rely on firewall rules only

Solution

1. Step 1: Identify key security principles for GCP

   Least privilege limits access, defense in depth adds multiple security layers, and continuous auditing monitors activity.

2. Step 2: Evaluate options for best security practice

   Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing combines these principles correctly; others either grant excessive access or skip monitoring.

3. Final Answer:

   Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing -> Option A

4. Quick Check:

   Least privilege + defense in depth + monitoring = strong security [OK]

Hint: Combine least privilege, defense in depth, and monitoring [OK]

Common Mistakes:

• Granting overly broad roles
• Ignoring monitoring and auditing
• Relying only on default settings