LEARN. PRACTICE. GROW.Start with the access the service needs
A cloud reorganization can retain applications while changing relationships they depend on. Before the window, record who performs each operation, on which resource, and through which grant. Include application accounts, pipeline accounts, operators and log-routing identities. A project name or inventory entry does not answer these questions. In a fictional funds-processing exercise, separate publishing a message, reading configuration, writing logs and querying metrics. These are four paths whose identities and scopes can differ. For each path, identify the authorization owner and a functional check using trial data. The technical manager turns this analysis into a change sequence, acceptance criteria and assigned owners. Avoid a generic “IAM validated” checkbox: record the operation that must work, its executing identity and its observable result. This precision helps distinguish access failure from application failure during RUN handover.
Move a project without losing permission provenance
During a move between folders in the same organization, directly attached policies follow the project while inheritance depends on its new position. Compare effective grants before and after, including policies on relevant ancestors. An account depending solely on the old folder can lose access; an unwanted direct grant can remain. These effects require different actions. In the exercise, the publisher uses an Operations-folder grant and a supplier has a direct project grant. Moving to Services does not justify assuming that both lose access or both retain it. Propose approved minimum access for the publisher and an explicit supplier review. If you cannot read an ancestor’s policy, request evidence from its owner; an incomplete view does not prove permissions are absent. The review should also consider source and destination organization policies and a recovery alternative if functional validation fails.
Distinguish allow, deny, conditions and test mode
Effective permission cannot be inferred from a role name alone. An applicable deny can prevent an operation despite an allow; an exception to that deny rule does not create a missing allow grant. A time condition also does not narrow parallel grants. If you add a binding limited to 22:00 but retain the same role without a condition, the second grant still matters after that deadline. Review all permission-granting paths before declaring maintenance access ended. For supported organization policies, dry-run observes violations without rejecting operations because of that candidate policy. Do not confuse enforce inside dryRunSpec with the live configuration. At a change committee, distinguish the intended rule, trial findings and configuration that will actually block operations. These differences determine whether a service becomes unavailable or excessive access remains active; they are operational acceptance concerns.
Separate network use, administration and transit
Shared VPC centralizes networking while retaining separate service projects. Attaching a service project to the host is an administrative relationship; the account using a subnet still needs appropriate authorization at that scope. If the request authorizes only a trial subnet, granting compute.networkUser on that subnet is more appropriate than granting it across the host. The latter can cover present and future subnets. Other resource-creation permissions and organization restrictions remain separate checks. Next, draw the packet path. Two peering connections through a central network do not by themselves establish transit between the two peers. A permissive firewall does not construct a missing route. During the network review, request an explicit supported-connectivity decision and validate source, destination and service. Authorizing an account to use networking does not demonstrate that the application can reach its dependency.
Select logs without assuming fields were hidden
A log view helps control which entries can be queried. Do not treat it as a mechanism that automatically transforms the contents of every admitted entry. In a fictional trial, a view selects the recon application and its events include account_number. If analysts must investigate errors without reading that identifier, check field-access controls and identities authorized to access restricted fields. Also consider avoiding unnecessary collection at source. Do not declare anonymization simply because a demonstration query did not display the field. Validate using an identity representative of the analyst and a synthetic event containing the field. Shorter retention reduces the availability period but does not prevent reading during that period. Acceptance evidence should describe visible entries, accessible fields and who can change those controls. Handover then includes visibility boundaries that can actually be checked.
Identify who writes to the observability destination
The identity investigating a failure might not be the identity transporting data. For a sink with writerIdentity defined, inspect that identity and the permissions required by the selected destination. In cross-project routing, giving an operator read access does not resolve a sink write denial. First confirm that new events match the filter, the destination is correct and diagnostics point to authorization. Then request an appropriate grant for the sink’s actual identity from the destination owner, instead of experimentally giving broad permissions to the application account. After the change and its propagation, send an identifiable trial event and confirm arrival and authorized querying. Record what happens if routing fails again. Production handover needs an observable chain from event generation to operator use, with clear responsibility at each boundary and evidence collected under the intended identities.
Maintain coverage when metrics scope changes
A metrics scope determines which series the central project can display and monitor. When removing a project from that scope, do not assume charts and alert policies disappear automatically. Configuration can remain although available series have changed. During reorganization, inventory dashboards and alerts depending on the project being removed and identify their owners. Plan where the authorized team will inspect signals after the change. Validate with an agreed trial series or condition and follow the path to the person receiving the alert, without causing a real production failure. If segregation requires removing visibility from the former team, do not restore it permanently merely to preserve the previous dashboard. The decision must combine authorized access with detection capability. An existing policy that no longer observes its intended population is insufficient evidence of operational coverage.
Guided acceptance and RUN handover exercise
Use the JSON table below as a fictional requirements inventory, not executable Google Cloud policy. Classify each row as lost authorization, retained access, field exposure or a monitoring gap. For each, write the minimum proposed change, its approving owner, and a positive and negative check. The publisher should publish to its approved destination while the supplier should lose querying access that is no longer authorized. The analyst should retain useful events without access to the restricted field. RUN should receive the trial signal in the correct scope. Compare your reasoning with the final case: completing the administrative operation does not satisfy these criteria. Also prepare an English shift-handover message covering impact, collected evidence, gaps and the next owner. The practical rule is to validate identity, resource, operation and data population at each boundary; a configuration object’s existence does not prove the service outcome.
{
"exercise": "fictional-reorganization-review",
"executableCloudPolicy": false,
"rows": [
{"actor": "publisher", "before": "old-folder grant", "after": "no applicable grant", "required": "publish approved topic"},
{"actor": "supplier", "before": "direct project grant", "after": "same direct grant", "required": "remove unapproved access"},
{"actor": "analyst", "before": "recon log view", "after": "same entries and fields", "required": "no account_number access"},
{"actor": "run-team", "before": "central metrics scope", "after": "project removed; alert retained", "required": "authorized detection coverage"}
]
}A project retains a supplier’s direct grant, loses its publisher’s inherited authorization and falls outside central alert coverage.
Common pitfalls
Confusing exception with grant, condition with global revocation, entry filtering with field protection and an existing alert with active coverage.
Related topics: Environment and privilege segregation · Cross-project observability · Change management and responsibility handover
A change is ready for RUN when the right identities perform authorized operations and the team can observe the outcome.
Reference: Move a project · Current linked guide; edition date unconfirmed (2026-09-30 inspection)