Networking and Security Basics Questions

Covers foundational networking and security concepts that underpin secure system design and assessment. Topics include virtual private cloud design and segmentation subnets firewalls security groups network access control lists demilitarized zones differences between public and private endpoints network isolation patterns least privilege and defense in depth principles encryption at rest and in transit common authentication and authorization flows in cloud environments and high level compliance considerations such as data residency and payment card industry data security standards.

HardTechnical

29 practiced

Compare firewalls (stateful network appliances), cloud security groups, and host-based firewalls (iptables, Windows Firewall). For each, explain ideal deployment placement, scalability characteristics, performance trade-offs, and situations where each is required.

Sample Answer

High-level summary:- Stateful network firewalls (physical or virtual appliances) inspect connection state and enforce network-layer and some application-layer policies at network chokepoints.- Cloud security groups are simple, scalable, cloud-provider-managed ACLs tied to NICs or instances—stateless in many providers or minimally stateful for return traffic.- Host-based firewalls (iptables/nftables, Windows Firewall) enforce per-host policies with process/user-level context and can apply microsegmentation.

Ideal placement:- Stateful network firewall: perimeter of a VPC/zone, between trust zones (DMZ ⇄ internal), or at data center edge. Good for central policy, IDS/IPS, VPN termination.- Cloud security groups: attached directly to instances/subnets; use as first-line, east-west/ north-south filtering inside cloud tenancy.- Host-based firewall: on every server/VM/container for last-mile control and zero-trust microsegmentation; colocate in host OS or container sidecar.

Scalability characteristics:- Stateful appliances: scale vertically (bigger box) or horizontally with complex clustering/load-balancing; can be a scaling bottleneck and require HA and session sync.- Cloud security groups: highly scalable, distributed by provider, apply instantly to large fleets; near-zero management overhead at scale.- Host firewalls: scale naturally with hosts; management complexity grows—use automation (CM, IaC, orchestration) for policy drift.

Performance trade-offs:- Stateful appliances add throughput/latency constraints and may inspect deeper (IDS/IPS) at CPU cost. Good for centralized logging/analytics.- Security groups are lightweight with minimal latency; limited inspection depth and fewer features.- Host firewalls have low latency for local decisions, can enforce fine-grained rules, but per-host resource use and policy churn can impact management and boot-time delays.

When each is required:- Stateful firewall: regulatory boundary controls, cross-network segmentation, centralized compliance/auditing, IPS/SSL inspection, VPN hubs.- Security groups: mandatory in cloud for baseline network isolation; use for rapid, scalable allow/deny rules and microsegmentation primitives.- Host firewall: required for defense-in-depth, protection against lateral movement, app/process-level policies, when environment spans untrusted networks or containers.

Trade-offs & recommendation (Solutions Architect view):- Use layered approach: cloud SGs for coarse-grain perimeter and subnet rules, stateful appliances for centralized inspection/ingress egress control where needed, and host-based firewalls for microsegmentation and application-aware controls. Automate policy generation and drift detection, and evaluate performance/cost trade-offs for stateful middleboxes vs. distributed cloud-native controls.

MediumSystem Design

36 practiced

Design a VPC and network segmentation approach for a multi-tenant SaaS platform that must support 1,000 tenants with strong isolation guarantees. Compare shared-vpc, per-tenant VPCs, and account-per-tenant models and recommend an architecture, explaining trade-offs in manageability, cost, and security.

Sample Answer

Requirements & constraints:- 1,000 tenants, strong isolation (security/compliance), reasonable cost, operational scale, per-tenant customizations, multi-region HA, need for centralized observability and automation.

Recommendation (hybrid): Use a small-perimeter shared VPC for common services + account-per-tenant for high-risk tenants and grouped per-VPC for the rest. Automation via IaC and org-level policies.

Comparison:

1) Shared-VPC (single VPC with namespaces/segments)- Security: weaker blast radius; relies on network ACLs, SGs, namespaces (good for soft-multi-tenancy).- Manageability: simplest networking, single routing table and centralized services.- Cost: lowest (fewer VPCs, shared NAT/GW).- Trade-offs: risky for strict isolation/regulatory tenants; complex micro-segmentation needed (e.g., service mesh, eBPF/NSX).

2) Per-tenant VPCs (each tenant gets isolated VPC)- Security: strong network isolation; separate routing, subnets.- Manageability: operational overhead at 1k VPCs but manageable with automation (Terraform, modules).- Cost: higher (NAT, endpoints, peering/transit costs).- Trade-offs: scales well for logical isolation; requires central transit (Transit Gateway or Service Mesh) for shared services.

3) Account-per-tenant (separate cloud account/tenant)- Security: strongest isolation (billing, quotas, IAM boundary).- Manageability: high overhead (1k accounts) but enterprise orgs can automate with landing zones, guardrails.- Cost: highest per-tenant baseline; cross-account networking via Transit Gateway or VPC peering is required.- Trade-offs: best for regulated/high-risk tenants; more complex for cross-tenant features and monitoring.

Architecture details:- Use AWS Organizations / Azure Management Groups for account hygiene.- Central Transit (Transit Gateway / hub-and-spoke) for routing and shared services; use VPC endpoints to avoid internet egress.- Identity: central IdP + per-tenant roles; avoid cross-account IAM keys.- Network controls: flow logs, IDS/IPS, WAF in hub; strict Security Group + NACL policies per pod.- Automation: Terraform/CloudFormation modules, account factory, CI/CD for infra, policy-as-code (Sentinel/OPA).- Cost optimization: group low-risk tenants into shared-VPC "pools" (10–50 tenants/VPC) to balance cost vs isolation; reserve account-per-tenant for top 5–10% high-risk.

Decision rationale:- Hybrid maximizes ROI: strong isolation for regulated tenants via account-per-tenant; reasonable isolation via per-tenant VPCs for most; shared-VPC only for completely low-risk/metadata-only tenants. This balances security, manageability (automation reduces overhead), and cost (grouping and central transit reduces duplicate resources).

HardTechnical

31 practiced

Compare and contrast the use of VPC endpoints (private link) versus NAT Gateway for outbound access from private subnets. Discuss security benefits, monitoring, pricing, scalability, and how each approach affects the ability to prevent or detect data exfiltration.

Sample Answer

High-level summary: VPC Endpoints (AWS PrivateLink/Interface or Gateway endpoints) provide direct, private, and service-specific connectivity between private subnets and AWS services or supported partner services without traversing the internet. NAT Gateway provides general-purpose outbound internet access from private subnets by translating private IPs to a public IP and routing via the internet.

Security:- VPC Endpoints: Stronger security posture because traffic never leaves AWS network; can be restricted with endpoint policies and IAM, and combined with security groups (Interface endpoints) and VPC route table controls (Gateway endpoints). Reduces attack surface and eliminates exposure to public internet.- NAT Gateway: Exposes egress to the internet; needs NACLs, security groups on egress resources, and more careful patching/controls. Source IPs are the NAT’s public IP(s), which can be logged/blocked.

Monitoring & Detection:- VPC Endpoints: You can enable VPC Flow Logs, CloudWatch metrics, and CloudTrail for endpoint API calls. Endpoint-specific logs are more granular for service access. But detecting data exfiltration still requires application-level logging, CloudTrail, S3 access logs, and IDS/behavior analytics.- NAT Gateway: VPC Flow Logs and VPC Flow aggregation for NAT IPs give visibility into destinations; combining with network packet capture (Traffic Mirroring) and IDS improves detection. Outbound DNS and TLS SNI monitoring can reveal suspicious exfiltration.

Pricing:- VPC Endpoints: Interface endpoints incur hourly and per-GB data processing charges; gateway endpoints (S3/DynamoDB) are free for data transfer within the region. PrivateLink to third parties can be costlier per-GB. Cost predictable when traffic is service-specific.- NAT Gateway: Charged per-hour + per-GB processed. For high-volume egress, NAT cost can be significant but simple. If many AZs, you need per-AZ NATs for high availability — cost scales.

Scalability & Availability:- VPC Endpoints: Managed and scales automatically for supported services; Interface endpoints may require scaling for high throughput but AWS manages backend. Gateway endpoints scale well for S3/DynamoDB.- NAT Gateway: Highly available within an AZ; recommended to deploy per-AZ for fault tolerance and bandwidth. Can become a bottleneck if not architected per-AZ or if throughput spikes.

Ability to Prevent/Detect Data Exfiltration:- Prevention: VPC Endpoints allow tight whitelisting of specific AWS services and endpoints, eliminating general internet egress—this is the strongest preventative control for service-bound traffic. Gateway endpoints to S3 + S3 bucket policies + VPC endpoint conditions effectively block uploads to non-approved buckets. NAT Gateway cannot inherently restrict destinations; you'd need egress proxies, firewall appliances, or allowlists via third-party or AWS Network Firewall.- Detection: Both approaches rely on logs (CloudTrail, S3 access logs, VPC Flow Logs). VPC Endpoints simplify attribution (service calls are internal APIs) and you can enforce endpoint policies to block noncompliant actions; NAT requires correlating flow logs to DNS/TLS, which is noisier. For robust detection, combine either with DNS egress control (Route53 Resolver Firewall), Network Firewall, IDS, and centralized logging/analytics.

Recommendations (solutions-architect view):- Prefer gateway endpoints for S3/DynamoDB when you can: free data transfer within region, strong policy controls, and easy prevention of internet egress.- Use Interface endpoints (PrivateLink) for service-specific, private connectivity to AWS services or partners—better security and lower attack surface for service traffic.- Use NAT Gateway only when workloads require generalized internet access (OS updates, external APIs). Mitigate risks by per-AZ NATs, strict NACL/SGs, egress proxies, and Network Firewall to enforce allowlists and TLS inspection where needed.- For strict data exfiltration protection, combine VPC endpoints + S3 bucket policies + IAM conditions, and supplement with Network Firewall, DNS filtering, and strong logging/alerting pipelines (CloudWatch Logs, GuardDuty, Security Hub, SIEM).

Trade-offs:- Security vs flexibility: VPC endpoints lock you to specific services (better security); NAT gives flexibility but increases exposure and detection complexity.- Cost vs control: Interface endpoints can be more expensive per-GB than NAT for heavy, varied egress; gateway endpoints (S3/DynamoDB) are cost-effective and secure.

Example pattern:- Sensitive workloads: Private subnets with gateway endpoint to S3 (block all internet egress), PrivateLink to APIs, no NAT; use VPC endpoints + bucket policies + GuardDuty alerts.- General-purpose workloads: Per-AZ NAT Gateways + Network Firewall + egress proxy + detailed logging; restrict critical data flows via endpoints or proxy rules.

This balanced approach lets you minimize exfiltration risk while controlling cost and maintaining necessary outbound functionality.

MediumTechnical

52 practiced

Create a threat model for a public API that issues OAuth tokens to browser-based clients storing tokens in local storage. Identify key threats (token theft, CSRF, replay), propose mitigations at network and application layers (CORS, SameSite, secure cookies, short token lifetimes), and explain residual risk.

Sample Answer

Scope & assets- Public OAuth 2.0 authorization server issuing access (and optionally refresh) tokens to single-page apps (SPAs) in browsers that store tokens in localStorage. Threat surface: browser, network, API, third-party scripts.

Key threats1. Token theft via XSS (malicious script reads localStorage).2. CSRF causing unwanted API calls using bearer token (if app auto-sends token).3. Token replay/interception (man-in-the-middle on non-TLS or compromised network).4. Refresh token leakage or long-lived token abuse.5. Malicious third-party script or supply-chain compromise.6. Clickjacking / UI-redress attacks capturing auth flows.

Mitigations — network layer- Enforce TLS 1.2+ with HSTS and certificate pinning where possible.- Use short-lived access tokens (minutes) and rotate refresh tokens.- Require PKCE for all OAuth flows from public clients.- Use token binding (MTLS or DPoP) if clients can support it to prevent replay.- CORS: limit allowed origins (exact match), preflight checks, and avoid wildcard origins.

Mitigations — application/browser layer- Avoid localStorage for sensitive tokens. Prefer httpOnly, Secure, SameSite=strict cookies for session tokens where feasible.- If SPA must use storage, use in-memory token storage and silent refresh; persist minimal state.- Set SameSite=Lax/Strict on cookies to mitigate CSRF; enforce CSRF tokens for state-changing endpoints.- Content Security Policy (CSP) restricting script-src to trusted origins; Subresource Integrity (SRI).- Sanitize inputs and adopt secure coding to reduce XSS risk.- Implement token introspection and revocation endpoints; monitor and alert on anomalous token usage.- Limit scopes and least privilege; per-client rate limiting and anomaly detection.

Residual risk and trade-offs- If cookies (httpOnly) are used, CSRF risk remains unless SameSite or CSRF tokens enforced. If tokens stored in-memory, risk of page-refresh losing session and UX degradation.- XSS remains highest residual risk; CSP + secure coding reduce but do not eliminate it—third-party scripts are a recurring vector.- DPoP/MTLS reduces replay but increases client complexity and may not be supported by all browsers.- Short lifetimes mitigate theft impact but increase token refresh frequency and load.

Recommendation (solution-level)- For highest security with reasonable UX: use Authorization Code + PKCE, store refresh tokens in httpOnly Secure SameSite cookies, use short-lived access tokens (stored in memory), enforce strict CORS, CSP, and monitoring. Document trade-offs for customers and provide an implementation checklist (CSP, input sanitization, origin allowlist, logging/alerts, token rotation).

MediumTechnical

37 practiced

Explain common authentication and authorization flows used in cloud environments: OAuth2 authorization code flow, OIDC, and SAML SSO. For each, describe where it fits in an enterprise SSO design and how it ties into network controls (e.g., conditional access based on network location).

Sample Answer

OAuth2 Authorization Code Flow- What: OAuth2 is an authorization framework; the Authorization Code flow is used by confidential or public clients to obtain access tokens via an authorization server after a user authenticates. The client directs the user to the IdP’s authorize endpoint, receives a short-lived code, then redeems it for tokens at the token endpoint (server-to-server), keeping client secrets confidential.- Fit in SSO: Use when apps need delegated access to APIs (web apps, SPAs with PKCE). It’s core for modern SSO where apps rely on a central IdP for token issuance.- Network controls: Conditional access is enforced at the IdP during the authorize request — policies can require MFA, block/allow by IP range, require compliant device, or deny if network location is risky. Access tokens can be scoped and short-lived to limit exposure.

OpenID Connect (OIDC)- What: OIDC is an identity layer built on OAuth2 that returns ID tokens (JWTs) containing user identity claims in addition to access tokens.- Fit in SSO: Primary choice for federated SSO for modern apps and API-driven architectures; enables single sign-on, user profile retrieval, and session management (logout, refresh tokens).- Network controls: IdP evaluates conditional access before issuing ID tokens (MFA, network location). Claims can carry device/network context for downstream services to enforce additional controls (e.g., restrict admin operations to corporate IPs).

SAML SSO- What: XML-based federated authentication protocol where a Service Provider (SP) redirects users to an Identity Provider (IdP) for authentication; IdP issues signed assertions consumed by the SP.- Fit in SSO: Dominant for legacy enterprise apps, enterprise SSO portals, and when rich attribute assertions or long-lived SSO sessions are needed. Often front-doors for SaaS apps via SAML integrations.- Network controls: Conditional access is enforced at the IdP before issuing assertions. IdP can include assertion attributes indicating authentication context (e.g., MFA performed) or deny authentication from untrusted networks. Some SPs also enforce network checks using assertion attributes or by invoking access gateways.

Comparisons & Architecture Guidance- Use SAML where legacy app support and rich assertion attributes are required; use OIDC/OAuth2 for API-first, mobile, and modern web apps.- Centralize conditional access at the IdP/Access Proxy (Azure AD, Okta, Ping) so network/location/device controls are evaluated once and propagated via tokens/assertions.- For stricter network enforcement, combine IdP conditional access with network-level controls: VPN, private endpoints, WAF, identity-aware proxies (IAP) or CASBs that validate tokens and enforce geolocation/IP-based policies.- Best practices: short token lifetimes, use PKCE for public clients, sign and validate tokens/assertions, include auth context claims, and log events for access reviews and forensics.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.