Cloud Networking and Security Questions

Design and operate isolated cloud networks and the controls that protect them. Core areas include Virtual Private Cloud design, subnetting and IP address planning, routing and route tables, internet gateways and network address translation, public and private subnet patterns, and multi region and multi account connectivity. Connectivity features include virtual private network tunnels, dedicated connectivity services, VPC peering, transit gateways, and service endpoints. Security and isolation topics include instance level security groups, subnet level network access control lists, bastion host and jump box patterns, firewall and third party appliances, segmentation and microsegmentation, identity and access management for network resources, and defense in depth. Data protections include encryption in transit and at rest, secrets management, and key management considerations. Also cover load balancing, high availability and scaling of network paths, performance tuning, monitoring and observability such as flow logs and packet capture, DNS and name resolution patterns, and common hybrid cloud and zero trust architectures. Be prepared to design a topology for a multi tier application, justify trade offs between security and accessibility, and propose operational controls and troubleshooting approaches.

HardTechnical

19 practiced

Design a Terraform-driven pattern to provision Transit Gateway attachments for multiple AWS accounts, automate route propagation from spoke VPCs to the Transit Gateway, and manage cross-account resource sharing securely. Explain module structure, remote state handling, use of AWS RAM for sharing, cross-account IAM roles for deployment, and strategies to avoid Transit Gateway route table explosion at scale.

Sample Answer

**Approach (brief)** I’d implement a reusable Terraform module pattern with a central “network” account owning the Transit Gateway (TGW) and per-spoke-account modules that attach VPCs and automate route propagation. Deployment uses cross-account roles and AWS RAM for sharing TGW resources.

**Module structure**- modules/tgw - creates TGW, route tables, attachment acceptor resources (in network account)- modules/attachment - creates TGW VPC attachment and enables route propagation (in spoke account)- modules/ram-share - creates RAM resource share for TGW and required route tables (network account)- env/root/main.tf - orchestrates roles, remote state data sources, and invokes modules

**Remote state handling**- Store state per-account in S3 with locking (DynamoDB). network account state contains TGW IDs; spoke account configurations read network account remote state via data "terraform_remote_state" referencing S3 backend (read-only).

**AWS RAM for sharing**- Use modules/ram-share in network account to share TGW and optionally specific route tables with target account IDs or organization principals. Only share the minimal ARN (TGW and route-table ARNs) to allow spokes to create attachments and propagate routes without sharing full resources.

**Cross-account IAM roles**- In each spoke account I create a deploy role (assume-role by CI/CD) with scoped permissions to create VPC attachments, modify route tables, and accept RAM shares. In the network account create a “tgw-admin” role to allow operations like accepting attachments or updating TGW route tables; restrict via condition to CI/CD principal.

Example attachment snippet (spoke account):

hcl

resource "aws_ec2_transit_gateway_vpc_attachment" "this" {
  subnet_ids         = var.subnet_ids
  transit_gateway_id = data.terraform_remote_state.network.outputs.tgw_id
  vpc_id             = var.vpc_id
  tags = { Name = "${var.env}-${var.vpc_name}-tgw-attach" }
}

**Automated propagation**- After attachment creation, set propagation to a specific TGW route table via aws_ec2_transit_gateway_route_table_association and aws_ec2_transit_gateway_route_table_propagation resources. Use remote state outputs for TGW route table IDs.

**Avoiding TGW route table explosion**- Use hub-and-spoke route table strategy: - One default regional route table for shared services. - Per-environment or per-billing-group route tables (not per-VPC). - Use route table tags and naming to group spokes; propagate by group membership rather than individually.- For large scale, use route summarization and a combination of: - Prefix lists for CIDR groups (AWS-managed or customer-managed) and programmatic route updates. - Transit Gateway route table automation: a controller (Lambda/Step Function or Terraform in CI) that updates route tables based on dynamic membership rather than each spoke adding routes to all tables.- Consider Transit Gateway Connect + TGW Connect peers or AWS Network Manager for complex multi-account designs.

**Security & best practices**- Least privilege roles, MFA and session duration limits for assume-role; encrypt state in S3; enable resource tagging and drift detection; restrict RAM shares to Organization if possible; CI/CD performs cross-account assumes to apply spoke infra.

This pattern gives clear ownership (network account owns TGW), secure cross-account deployments, deterministic remote-state reads, and scalable routing through grouping and automation.

HardTechnical

24 practiced

At an organization with thousands of VPCs, analyze scalability, security, operational complexity, and cost tradeoffs between VPC Peering, Transit Gateway, and PrivateLink for service connectivity. For each option discuss transitive routing support, route table limits, cross-account access patterns, isolation, and recommended migration approaches when growing from tens to thousands of VPCs.

Sample Answer

**Overview — what to evaluate**- Scalability (how connections grow), security/isolation, ops complexity, cost. I compare VPC Peering, Transit Gateway (TGW), and PrivateLink from a Cloud Engineer POV and give migration guidance.

**VPC Peering**- Transitive routing: none — peering is point-to-point only.- Route table limits / scale: full-mesh grows O(n^2) sessions/routes — quickly unmanageable at hundreds/thousands of VPCs. Per-VPC route table entries also become large.- Cross-account: supported (you can peer across accounts/regions), but each peering requires bilateral acceptance and management.- Isolation/security: high isolation (explicit pairings) but risk of misconfigured broad routes.- Ops & cost: low per-link cost but high operational overhead at scale.- When to use: tens of VPCs, simple B2B or one-off integrations.

**Transit Gateway**- Transitive routing: yes — hub-and-spoke model provides controlled transitive connectivity via TGW route tables.- Route table limits / scale: designed for large scale (centralized route management, attachment model). Better route scaling than full-mesh; consider TGW route table counts and per-table route limits in planning.- Cross-account: strong — share TGW using Resource Access Manager or central network account; attachments can be in other accounts.- Isolation/security: supports multiple TGW route tables, route-table-based segmentation, policy-based route propagation, and AWS Transit Gateway Network Manager for visibility.- Ops & cost: higher baseline cost (hourly + data processing) but much lower operational complexity at thousands of VPCs.- When to use: recommended as scale moves into hundreds→thousands of VPCs as primary hub.

**PrivateLink (Interface Endpoints / Endpoint Services)**- Transitive routing: none — connections are service-specific and not transitive.- Route table limits / scale: scales well because consumers create ENIs to the endpoint; avoids adding many custom routes in consumer route tables.- Cross-account: excellent — providers expose endpoint service (can require acceptance) and consumers across accounts/orgs connect privately.- Isolation/security: strongest isolation: service-level access, integrates with security groups, IAM, VPC endpoint policies — good for exposing single services without full network access.- Ops & cost: per-endpoint hourly and data charges; operationally simpler for service owners but can be costly if many services or many consumer accounts.- When to use: exposing SaaS/microservices across many accounts/VPCs, or when least-privilege network access is required.

**Tradeoffs summary**- For N small (tens): VPC Peering is cheapest/simple.- For N large (hundreds→thousands): TGW centralizes management, reduces config churn, supports transitive routing, recommended despite cost.- For service exposure to many consumers or cross-org SaaS: PrivateLink provides best isolation and minimal route churn; pair with TGW for hybrid architectures.

**Migration approach (tens → thousands)**1. Start with peering for dev/test or small set of VPCs.2. Introduce a central network account and deploy TGW when growth reaches dozens/hundreds — migrate spokes progressively. Use TGW route tables to segment traffic and minimize downtime.3. For owner-managed services that many VPCs consume, front them with PrivateLink; consume via TGW or direct endpoint depending on locality.4. Automate: IaC (Terraform), lifecycle scripts to create/delete attachments, route propagation policies, and drift detection.5. Governance: use org-level sharing (RAM), strict endpoint policies, monitoring (flow logs, VPC Reachability Analyzer), and cost tagging.

**Operational tips**- Plan route/table budgeting early; use route table segmentation in TGW.- Prefer PrivateLink for sensitive data services; use TGW for broad network connectivity.- Model costs (hourly + data) before large rollouts and automate migrations to avoid human error.

EasyTechnical

18 practiced

Explain the differences between a managed NAT Gateway (or equivalent) and a self-managed NAT instance. Cover availability, automatic scaling, maintenance overhead, cost patterns, and situations where a NAT instance might still be preferred (e.g., custom filtering, logging).

MediumTechnical

21 practiced

How would you design IAM policies and operational controls to manage who can create or modify VPCs, route tables, security groups, and peering/transit attachments in a large organization? Discuss least privilege, separation of duties, automation via IaC, Service Control Policies (SCPs), permission boundaries, and auditing strategies.

Sample Answer

**Approach overview**Design IAM and operational controls enforcing least privilege, separation of duties, strong automation, org-wide guardrails (SCPs/permission boundaries), and continuous auditing.

**Least privilege**- Create fine-grained roles with explicit actions (e.g., ec2:CreateVpc, ec2:DeleteVpc, ec2:CreateRoute, ec2:ReplaceRoute, ec2:AuthorizeSecurityGroupIngress) instead of broad ec2:*.- Use resource-level ARNs and tag conditions (aws:ResourceTag/ ec2:Subnet/tag) to limit scope to specific projects/environments.- Use Condition keys (aws:RequestedRegion, aws:TagKeys) to restrict where VPCs can be created.

**Separation of duties**- Split responsibilities: Network Owners (design, peering approvals), Platform Engineers (create base VPC templates, route tables), App Teams (request subnets/security groups via GitOps).- Require approval step for destructive/network-wide ops (peering/transit attachments) via workflow (ServiceNow/Jira) integrated with CI/CD.

**Automation / IaC**- Enforce all infra changes via IaC (Terraform/CloudFormation) stored in Git; deny console creation by SCP where appropriate.- Use GitOps: PRs, automated plan/apply in CI with policy-as-code checks (Terraform Cloud, Atlantis).- Include automated unit & security checks: terratest, InSpec, Terrascan.

**SCPs & Permission boundaries**- SCPs at Org OU level deny actions globally (e.g., deny ec2:CreateVpc in production OU unless tagged/compliant; deny cross-account peering without explicit exceptions).- Use permission boundaries for developer roles to cap the maximum privileges they can grant themselves.

**Auditing & detection**- Centralized CloudTrail ingestion to SIEM; enable AWS Config rules for VPC changes and authoritative snapshots.- Config rules: detect open security groups, unauthorized peering, route propagation changes.- Alert on changes via CloudWatch Events / EventBridge -> Pager/Slack.- Periodic reports and IAM Access Analyzer findings; maintain runbook for remediation and automated rollback where possible.

**Example enforcement**- Role: Network-Engineer-Create-VPC — allows ec2:CreateVpc with condition aws:RequestTag/Project = true and limits to approved CIDR ranges via condition.- SCP: deny ec2:CreateVpc unless request includes Tag: "environment" and originates from CI role.

This design balances developer agility via IaC with strict guardrails, clarity of responsibility, and continuous auditing for security and compliance.

EasyTechnical

24 practiced

Explain what a Virtual Private Cloud (VPC) is across AWS/Azure/GCP. Describe the core components — subnets, route tables, internet gateway (or equivalent), NAT, security groups, and network ACLs — and explain the differences between public and private subnets. Provide a simple example layout for a 3‑tier web application (web, app, db), indicating which tiers belong in public vs private subnets and why.

Sample Answer

**What a VPC is (across AWS/Azure/GCP)** A VPC is a logically isolated virtual network in the cloud where you provision compute, storage and network resources. AWS: VPC. Azure: Virtual Network (VNet). GCP: VPC (global by default). All provide CIDR-based IP addressing, routing, network isolation, and security controls.

**Core components (what they are / cloud equivalents)** - Subnets — IP address ranges inside the VPC (Azure: subnet, GCP: subnetworks). Used to group resources and attach route/NSG rules. - Route tables — control packet forwarding between subnets and external targets (Internet, VPN, peering). - Internet Gateway (IGW) / Azure Internet-facing default route / GCP Internet Gateway — attaches VPC to internet for public IP traffic. - NAT — AWS NAT Gateway / Azure NAT Gateway or Load Balancer outbound rules / GCP Cloud NAT — allows private instances to initiate outbound internet without public IPs. - Security Groups — instance-level/stateful firewalls (AWS SGs, Azure NSG can be subnet/VM-level, GCP firewall rules are network-level but can target instances). Stateful: return traffic allowed automatically. - Network ACLs — subnet-level stateless ACLs (AWS NACLs; Azure uses NSG for similar use; GCP uses firewall rules + VPC service controls). Stateless means you must allow both directions.

**Public vs Private subnets** - Public subnet: route table has 0.0.0.0/0 → Internet Gateway; instances typically have public IPs or load balancer in front. - Private subnet: no direct route to Internet Gateway; outbound internet via NAT. Used for internal services to reduce attack surface.

**3‑tier web app example layout (simple)** - Web tier (public subnet): front-end servers or public ALB/NLB. Needs inbound HTTP(S) from internet. - App tier (private subnet): application servers without public IPs; accessible from web tier via security group rules. Outbound internet via NAT for updates. - DB tier (private subnet, more restricted): RDBMS accessible only from app tier IPs/security group; no internet access (or very limited, via NAT + strict egress rules).

**Security/Networking best practices** - Use security groups for instance-level allowlists; use NACLs sparingly for extra layer. - Least privilege: restrict inbound to necessary ports, use private subnets for stateful/data services, centralize egress controls (Cloud NAT, proxy). - Use VPC flow logs / NSG flow logs for audit and troubleshooting.

Unlock Full Question Bank

Get access to hundreds of Cloud Networking and Security interview questions and detailed answers.

Join thousands of developers preparing for their dream job.