Task 2.2: Configuring boundary segmentation.

• AA VPC network in each team's project, peered with a hub VPC network that the network team manages

  Incorrect

  With peering, each team administers its own VPC network, routes and firewall rules, so the network team would not own them.

• BShared VPC, with the Network User role granted on the host project to each team

  Incorrect

  Network User on the whole host project lets a team use every shared subnet, including other teams' subnets.

• CShared VPC, with the Network User role granted only on each team's own subnet in the host project

  Correct

  In Shared VPC the host project holds the network, and granting compute.networkUser on a single subnet limits a service project's users to that subnet.

• DShared VPC, with Compute Network Admin granted to each team so that teams can pick their subnet

  Incorrect

  Network Admin lets teams change the network itself, which is the control the central team must keep.

Shared VPC keeps networking in a host project administered centrally while service projects run the workloads. A Shared VPC Admin can share all subnets or only selected ones, and granting the Network User role on individual subnets limits which subnets each team can use.

• AThe domain restricted sharing organization policy, limited to the company's own Cloud Identity customer ID

  Incorrect

  Domain restricted sharing stops IAM grants to outside identities; it does not stop an insider from copying data to a project where they already have access.

• BAn egress firewall rule that denies traffic from the analysts' VMs to all Google API address ranges

  Incorrect

  VPC firewall rules do not govern API calls made from laptops or other networks, and blocking the APIs breaks legitimate work.

• CAn IAM deny policy that removes the BigQuery data read permission from the analysts on the datasets

  Incorrect

  Denying the read permission stops the analysts' legitimate work instead of only blocking copies that leave the boundary.

• DA VPC Service Controls service perimeter around the projects that hold the datasets, restricting the BigQuery API

  Correct

  A service perimeter blocks restricted API calls that cross its boundary, so data cannot be copied to projects outside it even with valid credentials.

VPC Service Controls defines service perimeters around projects and restricts chosen Google APIs. Requests that cross the perimeter, such as a copy to a project outside it or access from an untrusted network, are refused regardless of IAM, which is why it is the control for exfiltration by stolen or misused credentials.

• AAn ingress rule for that service account, limited to the object creation method on that bucket

  Correct

  Ingress rules allow calls from outside a perimeter for chosen identities, services, methods and resources, so only uploads to that bucket are let in.

• BAn access level that matches the partner's public IP range, added to the perimeter

  Incorrect

  An access level on the perimeter lets matching requests reach every restricted service and resource in it, far more than one bucket.

• CA perimeter bridge between this perimeter and a new perimeter around the partner's project

  Incorrect

  Bridges allow free communication between the bridged projects and require the partner's project to be in the same organization.

• DRemoval of Cloud Storage from the perimeter's restricted services list, with IAM on the bucket

  Incorrect

  Unrestricting Cloud Storage removes perimeter protection from every bucket in the project, not just the landing bucket.

Ingress and egress rules are the precise way to let traffic cross a perimeter. An ingress rule's from block names the identities and sources, and its to block names the services, methods and resources, so a partner can be allowed to create objects in one bucket and nothing else.

• AA global network firewall policy in every VPC network that denies port 22 from 0.0.0.0/0

  Incorrect

  Network firewall policies are attached per network by people with rights on that network, so project teams could change or detach them.

• BA hierarchical firewall policy on the organization: deny port 22 from 0.0.0.0/0, goto_next for the rest

  Correct

  Hierarchical firewall policies are evaluated before the networks' own rules and cannot be changed from projects; goto_next hands everything else down to the lower levels.

• CThe organization policy constraint that restricts VM external IP addresses to an empty allowed list

  Incorrect

  Removing external IPs blocks all inbound internet traffic, not just SSH, and SSH could still arrive through a load balancer.

• DThe organization policy constraint that disables serial port access on every VM in the organization

  Incorrect

  Serial port access is a separate console path; blocking it does not stop SSH connections from arriving from the internet.

Hierarchical firewall policies are attached to the organization or folders and apply to every VPC network beneath them. Their rules can allow, deny or use goto_next to delegate evaluation to lower levels, so a central team can enforce a few non-negotiable rules and leave the rest to project-level firewall rules and policies.

• ANetwork firewall policy rules that target a secure tag, which only the security team may bind to VMs

  Correct

  Secure tags are IAM-governed resources, so only principals allowed to bind the tag value can place a VM under the rules that use it.

• BUse a longer, harder to guess network tag name and rotate it every month

  Incorrect

  Network tags are arbitrary attributes that anyone who can edit the VM can set, whatever their names.

• CUse target VM IP addresses in the rules and update them when VMs change

  Incorrect

  Hard-coded addresses break as VMs are recreated and still do not express who may join the group.

• DAdd firewall rules logging to the database rule and review the logs every week

  Incorrect

  Logging shows who connected after the fact; it does not stop the tag change.

Network tags are free-form attributes that any principal able to edit an instance can change, which changes the firewall rules that apply to it. Secure tags, used by Cloud NGFW firewall policies, are resources controlled with IAM, so binding a VM to a tag value can be limited to a chosen group.

• AVPC Network Peering between the two networks, with the appliance in one of them

  Incorrect

  Peered networks exchange subnet routes directly, so traffic between the tiers would bypass the appliance.

• BShared VPC, with both tiers moved into one host project's network

  Incorrect

  Merging the tiers into one network removes the separation instead of forcing traffic through the appliance.

• CA multi-NIC appliance VM spanning both networks, with routes through it

  Correct

  A VM can have interfaces in several VPC networks, so an appliance placed between them, with routes sending traffic to it, sees every packet.

• DCloud NAT in each network, so that the tiers reach each other through public addresses

  Incorrect

  Cloud NAT is for outbound internet traffic and would send internal traffic out to the internet path.

Network virtual appliances are built from VMs with multiple network interfaces, each in a different VPC network. Routes in each network send traffic for the other tier to the appliance's interface, so inspection cannot be skipped, unlike peering, which connects the networks directly.

• AEnforce the perimeter on a Friday evening and roll it back if pipelines fail over the weekend

  Incorrect

  Enforcing it refuses the requests the team is trying to discover.

• BConfigure the perimeter in dry run mode and study the logged violations

  Correct

  In dry run mode, requests that would violate the perimeter are logged but not denied.

• CTurn on VPC Flow Logs in every network that calls the projects' APIs

  Incorrect

  Flow logs record VM network connections, not API calls that a perimeter would refuse.

• DRun Policy Troubleshooter for each pipeline's service account on each project

  Incorrect

  Policy Troubleshooter explains IAM decisions, not VPC Service Controls perimeter decisions.

A service perimeter can have a dry run configuration next to, or instead of, its enforced one. Requests that would violate the dry run configuration are allowed but recorded in audit logs, so teams can find the ingress and egress rules they need before enforcement.

• AAn ingress rule that blocks all identities from calling unrestricted services

  Incorrect

  Ingress rules allow selected access into a perimeter; they do not limit which APIs the perimeter's own networks can call.

• BAn egress firewall rule that denies all traffic to 0.0.0.0/0 from the VMs

  Incorrect

  A blanket egress deny breaks other traffic and does not distinguish between Google APIs.

• CA perimeter bridge between this perimeter and an empty perimeter

  Incorrect

  Bridges let projects in different perimeters communicate; they do not restrict APIs.

• DThe VPC accessible services setting, limited to the restricted services

  Correct

  VPC accessible services limits which services can be reached from networks inside the perimeter, so other Google APIs are blocked there.

VPC accessible services defines which services can be accessed from VPC networks inside a service perimeter. Setting it to the perimeter's restricted services, or a chosen list, stops workloads in the perimeter from reaching other Google APIs that could be used to move data out.