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

18 practiced

Your NAT Gateway costs have grown dramatically due to large volumes of container image pulls and OS updates across many accounts. Propose a combination of architecture and operational changes to reduce NAT and egress costs while maintaining security isolation and reliability for development and production workloads.

Sample Answer

**Clarify goals & constraints**

- Reduce NAT gateway and egress costs significantly- Preserve network isolation between accounts/environments- Maintain reliability and security posture (no open internet for private workloads)- Support large container image pulls and OS updates

**Solution summary (architecture + ops)**

1. Centralized regional caching layer - Deploy a highly available pull-through cache per region (e.g., Amazon ECR pull-through, open-source registry cache like Sonatype Nexus/Harbor) in a centralized tooling account inside private subnets with its own NAT or directly in public with security controls. - All accounts use VPC peering/Transit Gateway and route image registry DNS to that cache via PrivateLink or Route53 Resolver rules.

2. Use S3/CloudFront + Signed URLs for OS/image artifacts - Mirror frequently-used OS updates and base images into a central S3 bucket, expose via Origin Access or CloudFront; use VPC Gateway Endpoint or Private DNS to avoid NAT for S3 access.

3. Reduce per-request NAT egress - Replace per-VPC NAT Gateway with central egress through a NAT fleet or NAT Gateway plus Transit Gateway—consolidate egress to fewer NATs to reduce hourly+data charges. - Consider AWS Network Load Balancer + EC2 NAT instances for lower data transfer cost at scale if operationally acceptable.

4. DNS + routing + IAM controls - Use Route53 Resolver rules in each account to forward registry domains to the cache; enforce image pull policies with IAM/effective RBAC and Registry lifecycle rules to limit pulls. - Enable PrivateLink for third-party registries (Docker Hub, GitHub Packages) where available to avoid public egress.

5. Operational controls & telemetry - Implement image provenance and immutable tags; use guardrails to prevent developers from pulling large remote images repeatedly. - Add metrics and cost allocation: per-account egress, cache hit ratio, pull volume; set alerts and chargeback. - Automate sync jobs for mirrors, lifecycle policies, and cache scaling.

**Trade-offs & rationale**

- Central cache + S3 mirrors reduce repeated egress and NAT data charges; Route53/PrivateLink preserves isolation.- Consolidating NAT reduces hourly cost but introduces a critical egress path—mitigate with HA across AZs, autoscaling, and clear runbooks.- Using EC2 NAT instances lowers cost at scale but increases operational overhead.

**Success metrics**

- Target: ≥70% reduction in cross-account egress to Internet, cache hit ratio >80%, reduced NAT hourly cost by 50%, no increase in failed pulls.

HardSystem Design

17 practiced

Design a network observability system that provides packet-level traceability for security investigations while preventing storage of PII in logs and remaining GDPR-compliant. Cover data collection, redaction/anonymization strategies, tiered retention, access controls and just-in-time access to raw captures, and audit mechanisms for any access to sensitive captures.

Sample Answer

**Clarify requirements & constraints**- Packet-level traceability for security investigations- No persistent storage of PII in logs; GDPR-compliant (data minimization, purpose-limitation, right-to-erasure)- Support on-demand just-in-time (JIT) raw capture access with strong auditability

**High-level architecture**- Agents (eBPF/XDP, TAPs) capture metadata + indexed pointers to encrypted raw segments -> central Ingest (streaming pipeline: Kafka) -> Processing (redaction/anonymization, enrichment) -> Storage (tiered object store + index DB) -> Access/Governance layer -> Audit & SIEM.

**Data collection**- Capture full packets in ephemeral local ring buffers; stream to ingest over mTLS; include flow metadata (5-tuple, timestamps, DSCP).- Apply client-side policy hooks to pre-filter irrelevant traffic.

**Redaction / anonymization**- Pipeline stage A: deterministic pseudonymization for identifiers used in investigations (e.g., IP -> HMAC(IP, per-tenant salt)) stored in index to preserve traceability without PII.- Pipeline stage B: schema-driven redaction for payloads (PII patterns): regex detection, ML PII detector; redact or tokenize sensitive fields while keeping structural context.- Raw encrypted captures: encrypted with envelope keys per-tenant; not kept in primary index unless tagged for JIT retrieval.

**Tiered retention**- Tier 1 (30–90 days): enriched metadata + pseudonyms in hot store (Elasticsearch/Cassandra).- Tier 2 (90–365 days): compressed, tokenized traces in cold object storage (S3 Glacier/IA).- Tier 3 (>365 days): cryptographically sealed backups subject to legal hold only.

**Access controls & JIT raw access**- Role-based + attribute-based access control (RBAC + ABAC) integrated with IdP (OIDC, SCIM). Investigators request JIT raw capture access via ticketing/approval workflow (automated policy + human approval for high-sensitivity).- When approved, a short-lived decryption key is issued by a Key Management Service (KMS) after multi-party approval (separation of duties); raw object is decrypted into ephemeral workspace/VPC with strict egress controls and time-bound access (e.g., 1 hour).

**Audit & accountability**- Immutable audit log (WORM-backed ledger, e.g., append-only in cloud storage or ledger DB) recording every request, approval, key issuance, and access session metadata; logs forwarded to SIEM and monitored by detection rules.- All JIT sessions are session-recorded (screen/video) and capture hashes; periodic attestation and quarterly access reviews.

**GDPR controls**- Data minimization: default pipeline stores only pseudonyms & metadata.- Purpose limitation & DPIA: maintain per-investigation justification stored with access log.- Right-to-erasure: map pseudonyms to raw objects; upon erasure, remove keys and index entries, and attest destruction.- DPI & lawful basis: integrate legal hold and consent mechanisms; keep processing records.

**Scalability & trade-offs**- Streaming pipeline scales horizontally; pseudonymization preserves ability to link flows without PII but prevents certain deep-content analyses unless JIT approved.- Trade-off: latency vs thorough redaction—use layered processing: fast pseudonymization for real-time detection, deeper ML redaction async.

This design balances traceability for security investigations with strong privacy controls, enforceable workflows for JIT raw access, and auditable, GDPR-aligned lifecycle management.

EasyTechnical

20 practiced

Explain how route tables work inside a VPC: how route tables are associated to subnets, the concept of local routes, longest-prefix-match (route precedence), propagating routes from virtual gateways (BGP), and how you would handle overlapping routes or conflicting routes when connecting to multiple external networks.

Sample Answer

**Answer (Cloud Architect perspective)**

**How route tables work / association**- Each VPC has one or more route tables; every subnet is associated with exactly one route table (explicitly or with the VPC main table by default). The table controls where traffic from that subnet is sent.

**Local route**- Every route table includes an implicit local route for the VPC CIDR (e.g., 10.0.0.0/16 → local). This cannot be deleted and enables intra-subnet and cross-subnet traffic inside the VPC.

**Longest-prefix-match**- Routing decisions use longest-prefix-match: the most specific prefix wins. Example: route 10.0.1.0/24 → NACL A and 10.0.0.0/16 → local; traffic to 10.0.1.5 matches /24 first.

**Propagating routes (BGP / virtual gateways)**- When you attach a virtual private gateway or Transit Gateway and enable route propagation, BGP-advertised prefixes are added to route tables (often in a propagation table view). These learned routes follow standard preference rules but still obey longest-prefix-match.

**Handling overlapping/conflicting routes**- Prevent overlaps with careful IP planning (use RFC1918 non-overlapping ranges). If overlaps occur: - Use more specific prefixes to steer traffic (create /32 or /29 host or subnet routes). - Prefer route priorities: cloud platforms often prioritize explicit routes over propagated; check provider precedence. - Use separate VPCs and Transit Gateway route isolation, or NAT/proxy patterns to mediate conflicts. - With BGP, control route advertisements and use prefix-lists, route-maps or BGP local-preference to prefer one external path. - For complex mixtures, implement VRFs or separate routing domains (Transit Gateway attachments, route tables per attachment) to avoid leakage.

Example: Two peers advertise 0.0.0.0/0; prefer Provider A by setting BGP local-preference higher and ensure the route table contains the preferred next-hop; use a specific more-specific route for traffic destined to networks only reachable via Provider B.

Best practices: enforce IP governance, document route ownership, use propagated-route filters, and test failover using controlled BGP attributes.

MediumTechnical

19 practiced

Compare Network Load Balancer (NLB), Application Load Balancer (ALB), and Gateway Load Balancer (GWLB). Discuss which OSI layer each operates at, TLS termination options, integration with WAF or appliances, support for sticky sessions or WebSockets, and typical use-cases for each in cloud architectures.

EasyTechnical

17 practiced

Explain what a Virtual Private Cloud (VPC) is in the context of public clouds (for example, AWS/Azure/GCP). Describe the core components you expect when designing a VPC for a new application (subnets, route tables, internet/NAT gateways, security groups, NACLs, endpoints) and key design considerations (isolation, CIDR allocation, AZ placement, scalability).

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.