← Professional Cloud Architect: architecture and operations
23 / 25 · 120 MIN

Effective security and acceptance evidence

Evaluate identities, data protection, secret renewal and traceability through evidence-supported architecture and handover decisions.

Build a matrix of decisions and evidence

A useful security review starts with the expected result for a specific identity and operation. For a fictional reconciliation service, draw the path between pipeline, workload, secret, database and archive. At each connection record the caller, target resource, required permission, transport protection and event that supports investigation. Avoid concluding that the system is protected merely because a security product appears in the diagram. A positive test establishes that an authorized path works; a negative test should use an identity or context explicitly excluded by the requirement. Define success in advance, including absence of data in the refused result and expected operational evidence. Do not use real customer data in the exercise. This lesson’s deliverable is a matrix containing requirement, mechanism, effective configuration, trial, evidence and owner for correcting deviations. That matrix enables APS, development and security to discuss acceptance using observable outcomes.

Control changes and runtime identities

An allow policy is updated through read, modify and write operations. When two pipelines start from the same copy, the etag prevents the second from silently replacing the first pipeline’s work. On conflict, read again, reapply only the authorized intent and preserve conditions and concurrent changes before retrying the write. Privilege review should include who can deploy code and choose its runtime identity. A person without direct dataset access may be able to run a workload as a service account that can read it. Restrictions on attachable accounts and their privileges are part of deployment design. For GitHub federation, check expected numeric repository and owner identifiers alongside the authorized workflow context: names can be reused. In the exercise, compare two proposed changes and describe the indirect access each permits. The objective is to explain the complete authorization path without confusing a human account with the account used by a process.

Separate reading, listing and classification

Object content and its name can have different confidentiality requirements. In a bucket, restricting storage.objects.get to a prefix does not automatically limit an independent storage.objects.list grant. If other teams’ names are sensitive, overly broad listing already violates the requirement even when download is refused. A prefix filter selected by the interface does not force another client to use that filter. Review resource separation or permission scope against the specific need. Also distinguish administrative labels from tags used in IAM conditions. Identical text does not mean resource.matchTag finds the required tag binding. In the exercise, identify the source of every grant and design two requests: one that should retrieve content and another that should be refused. Add a third check for names returned by listing. Record the principal and applicable configuration so that an administrator-account demonstration does not hide a failure in the team’s experience.

Verify each segment and enforcement mode

An HTTPS frontend does not establish application TLS between a load balancer and its VMs. Inspect the backend service protocol and define trials for each segment required by the requirement. Similarly, an established Cloud SQL Auth Proxy tunnel does not replace built-in SQL user credentials when automatic IAM database authentication is not configured. Locate the error at the correct boundary before proposing more permissions. Private Google Access provides API connectivity for VMs without external IP addresses; assess authorization and perimeters for supported services separately. In Cloud Armor, a preview rule lets the team observe a match without executing the blocking action. Finally, CORS does not remove a public object read grant: compare browser behavior with a direct client. The exercise is to annotate a diagram containing five security claims and identify the configuration and evidence needed to support each claim.

Treat rotation as an operational change

A SECRET_ROTATE message marks an opportunity to perform work, not completion of renewal. Identify who creates the credential at the dependency, who publishes the new version, how consumers adopt it and when the previous credential can safely be retired. Define recovery if part of the change fails, avoiding removal of a still-needed credential without evidence of adoption. In Cloud Run, an environment-variable secret is resolved at startup: latest does not update that variable in an already running instance. Plan rollout and observation of the version actually loaded. Also distinguish this process from the lifecycle of a KMS key. A version restored during the scheduled-destruction window becomes DISABLED and needs authorized enabling before use. In the exercise, prepare a timeline containing events, owners and decision points. Mark request, execution, adoption and verification separately so the change report does not confuse receipt of a notification with a recovered service.

Maintain protection during data changes

In BigQuery, a column mask does not mean every identity sees only masked values. An identity with Fine-Grained Reader on the policy tag can query the original value when it has the other necessary permissions. Build an identity-specific matrix and avoid testing only as the administrator who created the configuration. During row access policy maintenance, identify what happens between operations. Removing all policies while readers retain table access can create a window of unfiltered reads. An acceptable sequence might suspend access before replacement and restore it after validation; another might create new policies before removing old ones, provided their temporary combination also respects the requirement. The choice depends on availability and permitted access scope. In the exercise, draw three states: before, during and after. For each state, describe which rows a specific analyst can obtain and how you will demonstrate that access did not broaden improperly.

Read effective audit and location configuration

This lesson’s JSON excerpt is a reading example, not a policy ready to apply. DATA_READ is configured for Storage, but the batch service account appears in exemptedMembers. If the objective is to investigate that account’s reads, the configuration fails for the operational principal itself. Review inherited configurations before concluding what the effective result is; the exercise states that none exist. A future change does not recreate events that were never generated. For secret payload location, start from an approved internal requirement and select user-managed replication in the required supported locations. Location policy must allow every selected location. A region-named label does not control replication. The learner should present separate evidence for configuration, observed behavior and organizational requirement. This distinction lets the acceptance owner assess actual coverage without treating a technical example as a legal conclusion about all services or countries.

Decide RUN handover using reproducible evidence

In the final case, the sponsor presents a rotation event and a screenshot showing DATA_READ enabled. The learner should request the renewal execution chain, evidence of consumer adoption and an audited read using the actual batch account. While that account remains exempt and the credential is unchanged, the agreed criteria remain unmet. State the decision with its impact, action, owner and new acceptance condition. A temporary exception depends on explicit approval and compensating controls; it should not be described as meeting the original requirement. Keep trial scope, relevant configuration, versions, times and outcomes in the dossier without including secret values. To finish, explain to a colleague why a successful administrative operation can coexist with an insufficient security outcome. The following questions assess that ability to distinguish configuration, execution and evidence. They are original independent preparation situations; the lesson executes no cloud resources and does not represent any bank’s internal procedures.

{
 "auditConfigs": [
 {
 "service": "storage.googleapis.com",
 "auditLogConfigs": [
 {
 "logType": "DATA_READ",
 "exemptedMembers": [
 "serviceAccount:batch@training-fixture.iam.gserviceaccount.com"
 ]
 }
 ]
 }
 ]
}
IN PRACTICE

A batch has auditing configured but its account is exempt; a rotation notification did not renew the credential used for reconciliation.

Common pitfalls

Confusing connectivity with authorization, preview with blocking, labels with tags, notification with completed rotation and enabled logs with coverage of every account.

Related topics: Identities and privilege boundaries · Change management and production handover · Data protection and traceability

Take this idea with you

Accept a control from its demonstrated outcome for the required principal and operation, including the intermediate state of each change.

Create account

Reference: Understanding allow 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.