Google Cloud Digital Leader: Identity and Shared Responsibility

Trace principal-role-resource authorization and inherited grants; distinguish encryption at rest from permission and compliance decisions.

Objective: identify the actor and the action

Apply the preceding lesson’s dependency analysis to a precise access request. Name the principal, the action it needs to perform, and the resource affected. IAM is Google Cloud’s authorization system: it controls who can do what on which resource. Identifying a principal is different from deciding what it may do. Avoid diagnosing every failure as a password problem when the actual question is whether the identified actor has the necessary permission. Begin with the required operation rather than a broad request for administration rights.

Roles and inherited access

A role contains permissions. Granting a role to a principal on a resource through an allow policy gives a structured way to authorize work. Google Cloud resources are organized in a hierarchy including organizations, folders, projects, and service resources. Allow policies attached to a container also apply to resources beneath it. Therefore, a resource’s own policy is only part of the access picture. Inspect relevant ancestor policies when determining effective allowed access. Removing a local binding does not necessarily remove permission inherited from a project or folder.

Encryption protects a different boundary

Google’s default-encryption documentation describes encryption of customer content at rest. The captured document explicitly states its May 2024 technical scope, so do not treat it as a guarantee about every future configuration. At-rest encryption concerns stored data; it does not itself establish who is authorized to request a readable copy, how every network path is protected, or whether an organization meets a legal obligation. The provider’s infrastructure controls and the customer’s data-access decisions work together. They cannot be collapsed into a single “encrypted means secure” conclusion.

Worked example

Fictional case: a research assistant should read one approved dataset but should not change it or administer the project. First identify the assistant as the principal and reading the approved data as the required action. Second investigate an appropriately scoped role and resource binding rather than granting general administration. Third inspect inherited project and folder policies: an older broad grant could undermine the intended restriction. Fourth test permitted and forbidden operations with suitable evidence. Default encryption at rest does not remove a broad role or make an overly permissive policy harmless.

Challenge the repair

The team removes the assistant’s dataset-level grant yet reports that access still works. Before concluding that IAM failed, inspect the ancestor allow policies and other applicable access rules. A grant at a broader scope may still authorize the request. Conversely, changing encryption settings without investigating authorization does not directly answer why this principal can read the data. Keep the observed behavior and the proposed control aligned. Any final least-access judgment depends on the actual roles, scope, inherited policies, and service behavior, not a role name read in isolation.

Transfer check

A scheduled report can query every project dataset, but its job only needs an approved sales table. Which investigation comes first? Check: identify the job’s principal and effective permissions, including inherited allow policies, then evaluate narrowing access to what the job requires. Do not assume encryption at rest restricts that principal’s existing access. Retrieve the authorization and encryption boundaries with the cards. Next, examine how threat findings and regulatory requirements add evidence and obligations beyond these individual controls.

Try it, then explain it.

Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.

Practice 4 questions

Sources & authorship

Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.