Secure Infrastructure & Hardening

“Design a secure multi-tier network for a web application.”

Interviewers use scenarios like this because they want to see whether you can build infrastructure that’s reliable, resilient, and least-privilege by design. Ultimately, they’re evaluating whether you think like a security architect—someone who can balance protection with operational reality.

Strong candidates demonstrate four core abilities:

1. Apply defense in depth across network, identity, compute, and data layers
2. Spot and fix common misconfigurations that lead to breaches
3. Balance security with performance without sacrificing visibility
4. Communicate architecture decisions with clarity and confidence

The key is thinking in layers and explaining why each control reduces risk.

The layered security model

Security isn't a single wall, it's multiple layers that make compromise progressively harder. Here's how to structure your thinking:

Common risks & mitigations

Interviewers often present scenarios with hidden vulnerabilities. Here are the patterns they're testing for:

Example

Prompt: "Design a secure infrastructure for a public-facing web application running on AWS."

Here's how to structure a strong response using SALT:

Scope

Define what infrastructure you're securing and clarify requirements.

"I'm designing infrastructure for a public-facing web application on AWS. This includes:

• External-facing components: Web servers that handle user requests
• Internal components: Application servers and databases
• User interactions: Authentication, data storage, and API access
• Compliance needs: I'll assume we need encryption, audit logging, and access controls for SOC 2 or similar standards"

Why this matters: Setting clear scope prevents you from over-engineering or missing critical components.

Assets

Identify what you're protecting and prioritize based on risk.

"The critical assets are:

1. User data: PII, credentials, and session tokens stored in the database
2. Application code and secrets: API keys, database credentials, and encryption keys
3. Production workloads: The availability and integrity of the application itself
4. Infrastructure access: Admin credentials and IAM roles that control the environment

The highest priority is protecting user credentials and PII, as a breach here has direct compliance and reputation impact."

Why this matters: Assets drive your security decisions. Protecting user data requires encryption and access controls; protecting infrastructure access requires strong IAM.

Layers

Apply defense in depth across network, identity, compute, data, and monitoring.

Walk through each layer systematically:

1. Network layer

• Public subnets for web servers behind an Application Load Balancer (ALB)
• Private subnets for application servers and databases (no direct internet access)
• Outbound traffic through NAT gateways with restricted egress (prevent data exfiltration)

Risk reduced: Limits attack surface. Databases can't be reached directly from the internet.

2. Identity & access layer

• IAM roles for EC2 instances instead of static access keys
• MFA enforced for all human users accessing the AWS console
• Least privilege: Separate roles for developers (read-only prod access) and operators (deployment rights)

Risk reduced: Eliminates credential theft and limits blast radius if an account is compromised.

3. Compute & OS layer

• Use hardened AMIs
• Automated patching via AWS Systems Manager for OS and libraries
• SSH access only through AWS Session Manager or bastion hosts in isolated subnets (no open port 22)

Risk reduced: Closes OS-level vulnerabilities and removes direct SSH exposure.

4. Data layer

• Encrypt at rest using AWS KMS for S3, RDS, and EBS volumes
• Encrypt in transit with TLS 1.3 for all communications (ALB, internal services, database connections)
• Fine-grained access control: IAM policies with condition keys (e.g., require MFA for sensitive data access)
• Database backups encrypted and stored in separate accounts for disaster recovery

Risk reduced: Protects data even if storage is compromised; enforces principle of least privilege at the data level.

5. Monitoring & detection layer

• Enable AWS CloudTrail for all API activity (who did what, when)
• Enable AWS GuardDuty for automated threat detection (unusual API calls, compromised credentials)
• Centralize logs in a SIEM (Splunk, Datadog, or AWS Security Lake) for correlation and alerting

Risk reduced: Provides visibility into attacks in progress and enables rapid incident response.

Tradeoffs

Acknowledge the balance between security, cost, operations, and usability.

"This design increases IAM policy complexity and requires more operational overhead for role management. However, it significantly reduces our attack surface and ensures we can detect and respond to incidents quickly."

Closing summary

“This design isolates environments, limits privilege, and enforces visibility, providing layered security with minimal operational friction.”