← Professional Cloud Architect: architecture and operations
11 / 14 · 120 MIN

Security: policies, identity and evidence

Distinguish grants, restrictions, incomplete diagnosis and control evidence before production handover.

Build a complete access decision

Before adding a role during an incident, identify the effective identity, resource, permission and attempt time. Inspect relevant grants and prohibitions in the hierarchy. A project allow does not override an applicable folder deny. An exception to that deny also does not grant a missing permission. In the recovery-account exercise, draw two columns: what is no longer prohibited and what has actually been granted. If the second column is empty, exception status alone has not provided access. Record conditions and other rules that may apply. The change decision should state which task needs to work and which privileges remain excluded. This prevents solving an authorization failure through a broad grant that leaves the original cause intact and creates additional exposure during support. Retain the evaluation used to justify the change.

Understand eligibility and diagnostic limits

Principal Access Boundary policies limit resources an identity is eligible to access for supported permissions. When several PABs apply, eligibility is their union, not intersection. If one includes Custody and another Analytics, do not conclude the sets cancel out. Eligibility still is not access: allows and denies remain relevant. Build a small matrix containing both PABs, eligible resources and the permission being evaluated. Then consider diagnostic visibility. Policy Troubleshooter can return Unknown when the analyst cannot inspect necessary policies or group information. Unknown is neither a confirmed deny nor an implicit allow. Request analysis with authorized visibility and retain the incomplete result in the ticket rather than turning it into a convenient conclusion. The exercise asks you to justify each conclusion using the policy actually observed, including the limits of that observation.

Distinguish future policies from existing state

A location restriction can prevent supported new creation without identifying or correcting older resources. Inventory remains necessary: record effective location, resource type, constraint support and agreed treatment of deviations. Do not use a label as proof of data residency. Apply the same discipline to keys: configuring expiry for new service account keys does not add a deadline to existing ones. Identify consumers and plan controlled replacement or disabling. Finally, distinguish dryRunSpec from live policy. A record containing dryRunResult DENIED and liveResult ALLOWED indicates the trial rule would have rejected the operation, but it was allowed. In project reporting, use three separate fields: intended configuration, applied configuration and observed result. RUN handover needs all three to avoid declaring protection complete when it exists only in evaluation mode. Assign an owner to every unresolved difference.

Follow network and login evaluation

In hierarchical firewall policy, goto_next delegates evaluation to lower levels. It is not equivalent to allow. When a flow is denied, collect applicable rules and follow evaluation order rather than sorting every priority number as though all rules belonged to one global list. This analysis differs from API IAM authorization. SSH access also has layers: a working IAP tunnel to the port does not guarantee OS Login authorization. In the exercise, the operator already reaches the tunnel; repeating the IAP role does not grant the missing system permission. Identify the exact rejection point and request only the privilege matching the approved task. In handover, record how to prove connectivity, tunnel access and login separately, including who can perform each validation and where evidence is retained. Avoid treating one successful layer as proof of all subsequent layers.

Design audit evidence before the window

Start with the event you need to establish: a permission change, a data read and a provider action are different questions. Admin Activity does not replace Data Access. For supporting services, confirm generation, configuration and operation coverage; Data Access is not enabled by default outside the BigQuery exception. Perform an identifiable rehearsal operation and locate its event. Also confirm who can view it: Logs Viewer alone cannot read Data Access in _Default, whereas Private Logs Viewer includes that access. Absence from an analyst’s screen may reflect limited visibility rather than missing generation. For Google personnel actions on customer data, evaluate Access Transparency under supported services and conditions; do not confuse that record with prior approval. Define which evidence answers each question and who validates coverage. Record gaps explicitly instead of treating all audit categories as interchangeable.

Validate the log path and observed period

A sink selects and routes entries but does not automatically scan history received before its creation. Records still retained in a log bucket can use a separate copy process; never-generated events do not appear by creating a sink. For a destination in another project, check writerIdentity and destination permissions. The configuration creator’s personal access does not establish that the writer can deliver. Use a rehearsal event, confirm filter matching and observe arrival at the archive. Record the first and last times actually covered. Seven-day configured retention does not establish seven days of events. In the acceptance exercise, separately mark available history, collection gaps and unfinished transfers. That distinction lets the owner assess the real gap without confusing valid configuration with an already satisfied evidence requirement. Preserve source records until the required transfer is confirmed.

Separate administration, use and secret rollout

Storing KMS keys in a separate project is an architecture choice, but it does not establish separation of duties if the same identity still manages and uses the key. Review effective permissions, including inheritance, and assign distinct responsibilities matching the intended control. Avoid concluding that more frequent rotation resolves accumulated privilege. For application secrets, an explicit reference to version 5 continues requesting it after version 6 is published. Changes should pass through release processes with consumer validation and rollback conditions. The exercise asks for a two-phase plan: establish that the new version works, then confirm the earlier one is no longer needed before an irreversible action. Do not put secret values in evidence tickets. Record identifiers, versions, results and owners so the change is demonstrable without exposing sensitive contents or depending on an undocumented manual step.

Decide acceptance with explicit boundaries and gaps

For a request crossing VPC Service Controls perimeters, identify the client, referenced resources and operation. Policies of every involved perimeter must permit the request; one ingress rule is not a universal recipe. Describe the criteria needed for that flow and validate the intended result without replacing diagnosis with Owner. In the final case, the team must also distinguish enforcement from audit history. Prepare an acceptance decision with four fields: criterion, existing evidence, gap and resolution owner. If the criterion requires seven days that were never collected, do not invent backfill. Propose a plan to collect evidence and address the gap; any alternative requires owner approval before replacing the requirement. These exercises use documentation and fictional scenarios, not policy execution in a Google environment or a bank’s internal procedures. Keep the remaining acceptance conditions visible throughout remediation.

IN PRACTICE

A review finds a dry-run-only policy and an archive created today, while acceptance requires actual blocking and seven days of records.

Common pitfalls

Treating exceptions as allow, Unknown as permission, dry run as enforcement and retention duration as existing history.

Related topics: IAM governance · Operational audit · Handover criteria

Take this idea with you

Each conclusion needs scope and evidence: who, which resource, which permission, which policy and which observed period.

Create account

Reference: IAM deny policies · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)

Google Cloud is a trademark of Google LLC. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by Google. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.