Enterprise Cloud Virtual And Wireless Network Protection practice questions

An AWS Client VPN Endpoint attached to the VPC

Why it fails: Client VPN provides remote user access to the VPC, not private internal routing to S3.

An interface VPC endpoint using AWS PrivateLink

Why it fails: While PrivateLink can be used for S3, a Gateway Endpoint is the standard, cost-effective native mechanism for S3 and DynamoDB without ENI overhead.

A NAT Gateway deployed in the private subnet

Why it fails: A NAT Gateway routes private subnet traffic out to the public internet, which violates the security requirement.

WPA2-Enterprise with TKIP

Why it fails: TKIP is deprecated and insecure, and WPA2-Enterprise relies on 802.1X rather than SAE.

WEP with Shared Key Authentication

Why it fails: WEP is severely broken and obsolete.

WPA-Enterprise with TKIP/AES mixed mode

Why it fails: WPA is an outdated protocol superseded by WPA2 and WPA3.

Static WEP encryption keys

Why it fails: WEP is insecure and easily cracked.

MAC address filtering on access points

Why it fails: MAC addresses are easily spoofed in wireless traffic and provide no real security against determined attackers.

Disabling SSID broadcast (closed network)

Why it fails: Hiding SSID broadcasts does not prevent rogue AP attacks because SSIDs are revealed in probe requests and responses.

Hybrid Tier Routing via Cloud Interconnect

Why it fails: Hybrid tier is not a GCP network service tier name; Interconnect is a dedicated physical connection.

Public IP Tier with SSL offloading

Why it fails: This is not a valid GCP network service tier designation.

Standard Tier Network Routing

Why it fails: Standard tier routes traffic over the public internet, reducing security and performance.

Azure CNI with a user-defined route table and Azure Firewall

Why it fails: Azure CNI assigns each pod an IP from the virtual network subnet, but it does not inherently prevent public IP assignment to nodes. Nodes can still receive public IPs if the cluster is created with a public load balancer. A user-defined route and Azure Firewall control egress but do not remove the public IP association. This option addresses routing, not the requirement to avoid public IPs on nodes.

Azure CNI with a public load balancer and network security group rules

Why it fails: Azure CNI with a public load balancer assigns a public IP to the load balancer, not to the nodes, but nodes still receive public IPs by default when using a public load balancer for outbound connectivity. Network security group rules can restrict traffic but do not remove the public IP assignment. This configuration violates the requirement to avoid public IPs on nodes.

kubenet with a NAT gateway for outbound connectivity

Why it fails: kubenet uses a separate CIDR for pods and relies on route tables for pod-to-pod communication, but it still requires nodes to have public IPs for outbound traffic unless a NAT gateway is used. A NAT gateway provides outbound connectivity without public IPs on the nodes, but kubenet is not the recommended choice for enterprise pod-to-pod communication because it introduces complexity and limited scalability.

EAP-TTLS with PAP

Why it fails: EAP-TTLS with PAP also uses a server certificate and allows username/password authentication, but PAP sends credentials in plaintext inside the tunnel. While the tunnel is encrypted, PAP is considered less secure than MSCHAPv2 because it does not protect against credential replay or provide mutual authentication of the client. It could meet the requirement but is not the best choice for security.

EAP-FAST

Why it fails: EAP-FAST uses a protected access credential (PAC) to establish a tunnel and can support username/password authentication. However, it is Cisco-proprietary and not as widely adopted as PEAP-MSCHAPv2. While it can provide unique credentials, it may introduce compatibility issues and is not the standard choice for WPA3-Enterprise in heterogeneous environments. It does not inherently validate user identity as directly as PEAP-MSCHAPv2.

EAP-TLS

Why it fails: EAP-TLS requires both the client and server to present digital certificates. While it provides strong mutual authentication, it does not use unique user credentials such as username and password. Instead, it relies on client certificates, which may be shared or difficult to manage per user. This method does not meet the requirement for unique credentials per user in the scenario.

Cloud VPN

Why it fails: Cloud VPN connects on-premises networks to Google Cloud VPCs over an encrypted tunnel, but it is not designed for connecting two Google Cloud VPCs across projects. While it can be used to connect VPCs indirectly via on-premises, it adds unnecessary complexity and latency. It does not provide direct internal IP communication between projects as required.

Cloud Interconnect

Why it fails: Cloud Interconnect provides dedicated physical connections between on-premises networks and Google Cloud, not between Google Cloud VPCs. It is used for high-bandwidth, low-latency connections to on-premises. It does not enable internal IP communication between two Google Cloud projects directly, and it involves additional cost and setup.

Shared VPC

Why it fails: Shared VPC allows a host project to share subnets with service projects, enabling resources in service projects to use internal IPs from the host project's VPC. However, it requires a hierarchical relationship and centralized administration, and it does not connect two independent VPCs. It is not suitable for connecting multiple projects that each have their own VPCs and need peer-to-peer communication.

Azure Backup Vault with geo-redundant storage (GRS)

Why it fails: Azure Backup Vault with GRS stores backup copies, not continuously replicated VM disks, so it cannot provide the asynchronous cross-region disk replication the scenario demands. It is tempting because GRS does replicate backup data across regions, which suits long-term retention and restore-from-backup scenarios rather than low-RPO disaster recovery failover.

Azure ExpressRoute Global Reach

Why it fails: ExpressRoute Global Reach links on-premises networks through Microsoft's backbone; it carries no VM disk replication between Azure regions, so it cannot satisfy the asynchronous cross-region replication requirement. It is tempting because it connects regions privately, which suits hybrid connectivity or inter-region network traffic scenarios rather than disaster recovery replication.

Azure Traffic Manager with priority routing

Why it fails: Traffic Manager with priority routing only distributes client traffic to endpoints; it neither replicates VM disks nor provisions secondary VMs, so no cross-region disk copy exists to fail over to. It is tempting because it does orchestrate regional failover, which suits scenarios where replicated VMs or apps already exist in both regions.

Running regular traceroute commands from endpoints

Why it fails: Traceroute maps layer-3 routing paths to remote hosts; it cannot reveal a rogue AP's radio presence or physical location, since the AP sits on the local segment. Traceroute is the correct tool for diagnosing routing loops or path asymmetry across WAN links, not for wireless rogue device hunting.

Enabling port security on enterprise access layer switches

Why it fails: Port security limits MAC addresses per switch port, countering MAC flooding on wired access ports; a rogue AP broadcasting a spoofed SSID is a wireless-layer threat that never registers as a port violation. Port security is correct when stopping unauthorised wired devices from connecting.

Configuring static ARP entries on enterprise switches

Why it fails: Static ARP entries bind IP addresses to MAC addresses to prevent ARP spoofing on wired segments; they neither detect a rogue AP nor locate its radio source. Static ARP is the right control when hardening hosts against cache-poisoning attacks within a trusted broadcast domain.

Azure Application Gateway with Web Application Firewall

Why it fails: Application Gateway with WAF inspects inbound HTTP/S to published web apps, not outbound subnet traffic. It is correct for protecting internet-facing web workloads from Layer 7 attacks, but provides no FQDN-based egress filtering for a subnet.

Network Security Group (NSG) with custom service tags

Why it fails: Network Security Groups filter by IP address, port and protocol; service tags represent Microsoft-published IP ranges, not arbitrary FQDNs, so outbound FQDN rules cannot be expressed. NSGs suit subnet-level IP/port filtering where destination addresses are known. Azure Firewall is required, since it resolves FQDNs for outbound filtering.

User Defined Routes (UDR) pointing to a load balancer

Why it fails: UDRs steer packets by next-hop IP, so they cannot match FQDNs; a load balancer performs Layer 4 distribution, not domain-based egress filtering. UDRs suit forcing traffic through an NVA or virtual appliance for routing, not FQDN policy.

Identity-Aware Proxy (IAP)

Why it fails: Identity-Aware Proxy enforces user authentication and context-aware access to web applications and VMs, operating at the identity layer rather than filtering pod-to-pod packets by label. It cannot express Kubernetes label selectors. IAP is the right choice when protecting internal HTTP apps or SSH/RDP access without a VPN, not for east-west pod traffic.

Google Cloud Armor security policies

Why it fails: Cloud Armor filters HTTP(S) traffic at the external load-balancer edge, so it cannot select pod-to-pod flows by Kubernetes label inside the cluster. It is tempting because it enforces layer 7 rules, but that suits blocking web attacks and geo-based access to published services, not east-west pod traffic.

VPC Firewall Rules using subnet tags

Why it fails: VPC firewall rules operate at the subnet or instance level using network tags, not pod labels, so they cannot select individual GKE pods. They are tempting because they are the standard GCP mechanism for controlling traffic to VM instances; they would be correct for restricting traffic between Compute Engine VMs rather than Kubernetes workloads.

Event Source: s3.amazonaws.com, Event Name: PutBucketPolicy

Why it fails: PutBucketPolicy records changes to an S3 bucket policy, not the assumption of an IAM role. It is tempting because S3 events can reveal permission changes, but the analyst needs the AssumeRole event under the sts.amazonaws.com source.

Event Source: organizations.amazonaws.com, Event Name: AcceptHandshake

Why it fails: AcceptHandshake records an AWS Organizations invitation being accepted, not the assumption of a role. It is tempting because organisations events do track cross-account relationships, but they never capture the AssumeRole API call that grants administrative credentials.

Event Source: iam.amazonaws.com, Event Name: CreateUser

Why it fails: CreateUser records the creation of an IAM identity, not the assumption of privileges by an existing user or role. It is tempting because IAM is the correct event source, but the required event name for tracking assumed administrative access is AssumeRole.

AWS Shield Advanced

Why it fails: Shield Advanced provides DDoS protection for internet-facing resources; it establishes no organisational management structure, so Security Hub cannot centralise findings. It is tempting because it is enabled at organisation level, and would be correct where distributed denial-of-service mitigation across accounts is the requirement instead.

AWS CloudTrail

Why it fails: CloudTrail records API activity for auditing; it does not create the AWS Organizations management account structure that Security Hub requires for centralised multi-account finding aggregation. It is tempting because CloudTrail is a foundational logging service often enabled alongside Security Hub, but the prerequisite here is AWS Organizations.

AWS Transit Gateway

Why it fails: Transit Gateway routes network traffic between VPCs and on-premises networks; it creates no account hierarchy, so Security Hub cannot aggregate findings across accounts. It is tempting because it is an organisation-wide construct, and would be correct where centralised connectivity between many VPCs and accounts is the actual requirement.

Azure Application Gateway Ingress Controller (AGIC)

Why it fails: AGIC terminates inbound HTTP(S) traffic at the cluster edge, so it leaves pod-to-pod and node-to-node traffic inside the cluster unencrypted. It is tempting because it genuinely secures ingress, and would be correct when the requirement is TLS termination or web application routing for external clients rather than east-west encryption.

Azure Key Vault provider for Secrets Store CSI driver

Why it fails: This driver mounts secrets into pods, not network traffic encryption.

Azure Policy for Kubernetes add-on

Why it fails: Azure Policy for Kubernetes add-on enforces governance rules on cluster resources, such as restricting privileged pods or requiring labels; it does not encrypt pod-to-pod traffic. It is tempting because it hardens clusters, but it addresses configuration compliance, not data-plane encryption. Encrypting node-to-node communication requires enabling the AKS network plugin's encryption or mTLS-based service mesh instead.

Azure VPN Gateway with point-to-site configuration

Why it fails: A point-to-site VPN encrypts client traffic into the virtual network, yet the VMs still expose RDP and SSH publicly unless those ports are closed. It is tempting because VPNs secure remote access, and would be correct where administrators need encrypted connectivity from individual devices rather than elimination of open management ports.

Azure Load Balancer with TCP reset enabled

Why it fails: TCP reset terminates idle or unexpected flows on load-balanced connections; it neither removes nor filters inbound RDP and SSH on the public IP. It is tempting because reset behaviour sounds like connection hardening, and would be correct where the goal is dropping stale sessions through a load balancer rather than closing management ports.

Azure Front Door with Web Application Firewall

Why it fails: Front Door with WAF filters HTTP and HTTPS application traffic, so it cannot block RDP or SSH, which are not web protocols. It is tempting because WAFs are the usual public-exposure control, and would be correct where the requirement is protecting an internet-facing web application rather than securing VM management access.

GCP Cloud NAT gateway attached to the subnet

Why it fails: Cloud NAT translates egress traffic to external IP addresses for internet destinations; it does not provide the private path to Google APIs that Private Google Access gives. It tempts because NAT is the correct choice when instances lacking external IPs must reach arbitrary public internet endpoints.

External HTTP(S) Load Balancer

Why it fails: An external HTTP(S) Load Balancer distributes inbound client traffic to backends; it does not give instances a route to Google APIs. It tempts because load balancing is the right choice when publishing an application externally with health checks and global anycast frontends.

Dedicated Interconnect with partner peering

Why it fails: Dedicated Interconnect with partner peering provides private connectivity between on-premises networks and a VPC, not a path from instances to Google APIs. It tempts because Interconnect is the right choice for hybrid traffic that must bypass the public internet entirely.

WPA2-Enterprise with AES-CCMP and TKIP fallback

Why it fails: TKIP fallback permits negotiation down to the deprecated RC4-based cipher, directly enabling the downgrade attacks the scenario forbids, and AES-CCMP caps at 128-bit rather than 192-bit Suite-B. WPA2-Enterprise with CCMP alone suits legacy estates lacking WPA3-capable clients.

Enhanced Open (OWE) with opportunistic encryption

Why it fails: OWE provides unauthenticated opportunistic encryption for open public hotspots, deriving keys via Diffie-Hellman without any supplicant credentials. It cannot enforce 802.1X authentication or 192-bit Suite-B key derivation, so it fails the enterprise requirement. It would suit guest Wi-Fi where no shared credential exists.

WPA3-Personal with SAE and transition mode enabled

Why it fails: SAE derives keys from a shared passphrase, not from 802.1X/EAP credentials, so it cannot deliver per-user enterprise authentication or 192-bit Suite-B strength. Transition mode also retains WPA2 compatibility, undermining downgrade protection. SAE suits WPA3-Personal homes and small offices using a common password.

Terminate the EC2 instance and restore from the latest snapshot

Why it fails: Termination destroys the instance and its volatile memory, so RAM-resident forensic evidence is lost before any snapshot restore. Isolating the instance with a restrictive security group or detached network interface preserves memory. Termination suits decommissioning compromised hosts where no volatile evidence is needed.

Modify the instance state to 'stopped' via AWS CLI

Why it fails: Stopping the instance discards volatile memory contents, destroying the very forensic evidence the administrator must preserve. It is tempting because stopping is a familiar containment step, and it would be correct when memory state is irrelevant and only persistent disk artefacts matter.

Delete the attached Elastic Network Interface (ENI)

Why it fails: Deleting the ENI removes the instance's network interface, but the instance keeps running with its memory intact and could be re-attached to a new ENI, so isolation is not guaranteed. It is tempting because ENIs control network connectivity, and deletion suits decommissioning interfaces, not forensic containment.

AWS Client VPN with split tunneling disabled

Why it fails: Client VPN terminates remote user sessions into a VPC; it does not provide service-to-service connectivity between VPCs. It is tempting because it encrypts traffic without public exposure, and would be correct for granting individual remote workers private access to internal resources.

AWS Direct Connect Gateway with transit VIF

Why it fails: A Direct Connect Gateway with a transit VIF links on-premises networks to VPCs over private connectivity; it does not broker service-to-service traffic between VPCs. It is tempting because it avoids public internet exposure, and would be correct for hybrid connectivity from a data centre into multiple VPCs.

Inter-Region VPC Peering with restrictive Network Security Groups

Why it fails: Inter-Region VPC Peering connects entire VPC CIDR ranges, so any subnet can reach any other, violating the requirement to avoid full subnet access. It is tempting because peering is private and simple, and would be correct when two VPCs must share broad, trusted connectivity.

AWS Shield Standard DDoS mitigation

Why it fails: Shield Standard provides layer 3/4 DDoS protection for resources such as CloudFront and Route 53; it never modifies S3 bucket policies or public access settings. It is tempting because it is an account-level security feature enabled by default, but it is the correct choice when mitigating volumetric network attacks, not restricting bucket exposure.

AWS Trusted Advisor security checks

Why it fails: Trusted Advisor reports on existing configurations through its security checks; it is advisory and does not enforce Block Public Access on newly created buckets. It is tempting because it surfaces public S3 buckets in its dashboard, making it the right tool for auditing posture, not for automatically applying preventive account-level settings.

AWS IAM Permissions Boundary

Why it fails: Permissions boundaries cap the maximum permissions an IAM principal can hold; they do not act on S3 bucket settings, so new buckets still permit public access. They are tempting because they enforce account-wide permission ceilings, which is the right tool for limiting what identities may do, not for applying bucket-level Block Public Access defaults.