Bird
Raised Fist0

Security Fundamentals - AuthN, AuthZ, Encryption at Rest and in Transit

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Security Fundamentals - AuthN, AuthZ, Encryption at Rest and in Transit
45 min · senior
senior

You are designing the core security infrastructure for a consumer-facing platform with 50 million daily active users (DAU). The system must provide robust Authentication (AuthN), fine-grained Authorization (AuthZ), and ensure data encryption both at rest and in transit. The platform requires sub-200ms P99 latency for login and authorization checks to maintain user experience. Compliance with GDPR and HIPAA mandates encryption key management and audit logging. The system must support offline token validation and scale to handle peak loads of 10K login requests per second.

Constraints
  • All sensitive data must be encrypted at rest using envelope encryption with hardware security module (HSM) integration.
  • All network communication must use TLS 1.3 with mutual authentication for internal services.
  • Authorization decisions must be fine-grained and support attribute-based access control (ABAC) with low latency (<200ms P99).
  • Offline token validation must be supported to reduce latency and dependency on central services.
  • Audit logs must be immutable and tamper-evident, stored for at least 1 year for compliance.
  • The system must handle 10,000 login requests per second at peak with horizontal scalability.
📋
Guided Steps
1/6
Step 1
Designing Authentication Flow
How would you design the authentication mechanism to securely handle 10K login requests per second with sub-200ms P99 latency?
💡 Hint
Consider stateless token issuance and scalable credential verification methods.
Key Decision
Use OAuth 2.0 with JWT access tokens signed by AWS KMS-backed keys for stateless authentication; user credentials verified against Amazon Cognito user pools for horizontal scalability.
Interviewer Expectation
Mid: Names OAuth 2.0 and JWT for stateless tokens. Senior: Explains JWT signature verification offloads state, AWS KMS for key management, and Cognito's horizontal scaling for credential verification.
⚠️Common Wrong Answer
Using server-side session storage for login state - leads to bottlenecks and state synchronization issues at 10K RPS.
Step 2
Authorization Model and Enforcement
How would you implement fine-grained authorization with attribute-based access control (ABAC) ensuring P99 latency under 200ms?
💡 Hint
Think about policy evaluation engines and caching strategies for attributes.
Key Decision
Use Open Policy Agent (OPA) as a sidecar for policy evaluation combined with Redis caching of user attributes and policies to achieve low-latency ABAC enforcement.
Interviewer Expectation
Mid: Mentions OPA for policy evaluation. Senior: Details Redis caching of attributes and policies to avoid repeated DB calls, and sidecar pattern to isolate policy logic.
⚠️Common Wrong Answer
Querying a relational database synchronously for every authorization check - causes high latency and poor scalability.
Step 3
Encryption at Rest and Key Management
How will you ensure data encryption at rest with secure key management that meets compliance requirements?
💡 Hint
Consider envelope encryption and hardware security modules (HSMs).
Key Decision
Implement envelope encryption using AWS KMS with customer-managed keys stored in FIPS 140-2 Level 2 validated HSMs; data encrypted in S3 and DynamoDB with KMS data keys.
Interviewer Expectation
Mid: Names AWS KMS for key management. Senior: Explains envelope encryption reduces key exposure, HSM compliance for GDPR/HIPAA, and integration with S3/DynamoDB native encryption.
⚠️Common Wrong Answer
Encrypting data with application-managed keys stored in the same database - risks key leakage and non-compliance.
Step 4
Encryption in Transit and Mutual TLS
How would you secure all network communication, including internal service-to-service calls, to prevent man-in-the-middle attacks?
💡 Hint
Think about TLS versions and mutual authentication.
Key Decision
Enforce TLS 1.3 with mutual TLS (mTLS) using Istio service mesh for internal service communication, and AWS ALB with TLS termination for external traffic.
Interviewer Expectation
Mid: Mentions TLS 1.3 for encryption. Senior: Explains mTLS for mutual authentication, Istio integration for automatic certificate rotation, and ALB TLS termination for external clients.
⚠️Common Wrong Answer
Using TLS 1.2 without mutual authentication - vulnerable to internal spoofing and downgrade attacks.
Step 5
Offline Token Validation
How can offline token validation be supported to reduce latency and dependency on central authorization services?
💡 Hint
Consider token formats and revocation strategies.
Key Decision
Use JWT tokens with embedded claims and short expiration, validated locally by verifying signature with public keys fetched from AWS KMS; implement token revocation via short TTL and blacklist cache in Redis.
Interviewer Expectation
Mid: Describes JWT signature verification for offline validation. Senior: Explains public key rotation strategy, revocation via TTL and blacklist cache, and trade-offs of offline validation.
⚠️Common Wrong Answer
Using opaque tokens requiring central introspection - increases latency and single point of failure.
Step 6
Audit Logging and Compliance
How would you design audit logging to be immutable, tamper-evident, and compliant with GDPR and HIPAA?
💡 Hint
Think about append-only storage and cryptographic integrity.
Key Decision
Use AWS CloudTrail integrated with Amazon S3 immutable object lock enabled buckets and AWS Glue for log cataloging; logs are cryptographically signed and stored with lifecycle policies for 1-year retention.
Interviewer Expectation
Mid: Mentions CloudTrail and S3 for logging. Senior: Details S3 object lock for immutability, cryptographic signing for tamper evidence, and lifecycle policies for compliance.
⚠️Common Wrong Answer
Storing logs in mutable databases without immutability - risks tampering and non-compliance.
🔌
API Design Challenge
Sketch 3 core API endpoints for the security system: user login (AuthN), authorization check (AuthZ), and token validation (offline).
Hints
  • How does the client securely send credentials and receive tokens?
  • How does the service perform low-latency authorization checks with attribute-based policies?
  • How can offline token validation be achieved without contacting central servers?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Stateless authentication using JWT signed by a secure KMS-backed key store
  • Fine-grained ABAC authorization with low-latency policy evaluation and caching
  • Envelope encryption with HSM-backed key management for compliance
  • TLS 1.3 with mutual TLS for all internal and external communication
Good to Have - 30%
  • Offline token validation using JWT signature verification and revocation cache
  • Immutable, tamper-evident audit logging with cryptographic signing and object lock
Bonus - 10%
  • Automatic certificate rotation for mTLS using service mesh
  • Integration with AWS Glue for audit log cataloging and querying
Anti-patterns to Avoid
✅
Model Answer
▼ Reveal

The system uses OAuth 2.0 with JWT tokens signed by AWS KMS for stateless authentication, enabling horizontal scalability to handle 10K RPS with sub-200ms latency. Authorization is enforced via Open Policy Agent (OPA) sidecars combined with Redis caching of user attributes and policies to achieve low-latency ABAC decisions. Data at rest is encrypted using envelope encryption with customer-managed keys stored in FIPS 140-2 Level 2 validated HSMs via AWS KMS, ensuring compliance with GDPR and HIPAA. All network communication uses TLS 1.3 with mutual TLS (mTLS) enforced by Istio service mesh internally and AWS ALB TLS termination externally. Offline token validation is supported by JWT tokens with embedded claims and short expiration, validated locally by verifying signatures with public keys from AWS KMS and revocation handled via Redis blacklist cache. Audit logs are immutable and tamper-evident using AWS CloudTrail integrated with Amazon S3 buckets with object lock enabled and cryptographic signing, stored for at least one year.

Key Decisions
  • Use OAuth 2.0 with JWT tokens signed by AWS KMS for stateless authentication to handle 10K RPS with sub-200ms latency
  • Implement fine-grained ABAC authorization using OPA sidecars with Redis caching to achieve low-latency policy evaluation
  • Apply envelope encryption with AWS KMS customer-managed keys stored in FIPS 140-2 Level 2 validated HSMs for compliance
  • Enforce TLS 1.3 with mutual TLS via Istio service mesh for internal communication and AWS ALB TLS termination for external clients
  • Support offline token validation by verifying JWT signatures locally with public keys from AWS KMS and revocation via Redis blacklist cache
  • Design audit logging with AWS CloudTrail and Amazon S3 immutable buckets with object lock and cryptographic signing for tamper evidence and compliance
  • OAuth 2.0 with JWT tokens signed by AWS KMS for stateless, scalable authentication
  • Open Policy Agent (OPA) sidecar with Redis caching for low-latency ABAC authorization
  • Envelope encryption using AWS KMS with HSM-backed customer-managed keys for data at rest
  • TLS 1.3 with mutual TLS (mTLS) enforced via Istio service mesh for secure internal communication
  • JWT offline token validation with public key verification and Redis-based revocation blacklist
  • AWS CloudTrail and Amazon S3 with object lock for immutable, tamper-evident audit logging

Practice

(1/5)
1. In the request flow for delivering an HLS video segment, at step 4 the Delivery Worker checks the cache status of the requested segment. What happens if the segment is not found in the edge cache at this step?
easy
A. The Delivery Worker waits for the client to retry the request later
B. The Delivery Worker fetches the segment from the origin server and caches it locally before delivery
C. The Delivery Worker immediately returns a 404 error to the client
D. The Delivery Worker redirects the client to another edge node

Solution

  1. Step 1: Trace Delivery Worker decision at Step 4 -- cache miss handling

    On cache miss, the Delivery Worker does not immediately fetch from origin but queues the request and waits for the segment to be fetched asynchronously.

  2. Step 2: Eliminate other options

    Immediate 404 is incorrect as segments may be fetched; redirecting client is inefficient; immediate fetch blocks delivery worker, violating async design.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Delivery Worker waits for segment availability before responding [check]
Hint: Cache miss triggers async fetch; delivery waits, no immediate fetch [check]
Common Mistakes:
2. In the training pipeline trace, at Step 5 the Feature Joiner component receives feature data from multiple sources. What happens if one source's feature data arrives late at this step?
easy
A. The Feature Joiner buffers the data and waits until all sources have arrived or a timeout occurs
B. The Feature Joiner discards the entire training batch and retries fetching all features
C. The Feature Joiner immediately proceeds with partial data, marking missing features as null
D. The Feature Joiner triggers an alert but continues processing with stale cached features

Solution

  1. Step 1: Understand Feature Joiner role at Step 5

    The Feature Joiner must combine features from multiple sources to create a consistent training dataset.

  2. Step 2: Analyze late arrival handling

    To maintain data consistency, the joiner buffers incoming data and waits for all sources or a timeout. Proceeding immediately risks inconsistent feature vectors; discarding entire batches is inefficient; using stale cached features risks training on outdated data.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Feature Joiner buffers and waits or times out for consistency [check]
Hint: Feature Joiner buffers until all sources arrive or timeout [check]
Common Mistakes:
3. In a request flow where a client sends a request through a forward proxy to an external server, at step 3 the forward proxy modifies the request headers. What exactly happens at this step?
easy
A. The forward proxy removes client-identifying headers and adds its own IP as the source
B. The forward proxy caches the response before forwarding the request
C. The forward proxy encrypts the entire request payload before forwarding
D. The forward proxy replaces the destination IP with its own IP before forwarding

Solution

  1. Step 1: Understand forward proxy header modification

    At step 3, the forward proxy removes headers that reveal client identity and inserts its own IP as the source to hide the client.

  2. Step 2: Eliminate other options

    It does not replace destination IP (that would break routing), nor encrypt payload (that's TLS), nor cache response before request forwarding.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Forward proxy masks client IP by header modification [check]
Hint: Forward proxy swaps client IP with its own in headers [check]
Common Mistakes:
4. A website experiences sudden traffic spikes from global users, causing high latency and origin server overload. Which component best handles this scenario?
easy
A. Content Delivery Network caching static assets near users
B. Load balancer distributing requests evenly across origin servers
C. Relational database scaling vertically to handle more queries
D. Origin server increasing CPU and memory resources dynamically

Solution

  1. Step 1: Identify the bottleneck caused by global traffic spikes

    Origin servers face latency and overload due to distant users and high request volume.

  2. Step 2: Recognize CDN's role in caching static content closer to users

    CDNs reduce latency and offload origin servers by serving cached content from edge locations.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    CDN caches reduce origin load and latency globally [check]
Hint: Cache static content near users to reduce origin load [OK]
Common Mistakes:
5. You must design a cache for a system with highly skewed access patterns and limited memory. Which eviction policy is best suited to adapt dynamically between recency and frequency to maximize hit rate?
medium
A. Use TTL eviction to remove stale entries after fixed time
B. Use Adaptive Replacement Cache (ARC) to balance recency and frequency
C. Use LRU eviction to remove least recently used entries
D. Use LFU eviction to remove least frequently used entries

Solution

  1. Step 1: Identify need for dynamic adaptation

    ARC dynamically balances recency and frequency, ideal for skewed access and limited memory.

  2. Step 2: Eliminate static policies

    TTL ignores usage patterns; LRU and LFU optimize only one dimension, not both.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    ARC adapts between recency and frequency for skewed workloads [check]
Hint: ARC adapts dynamically; LRU/LFU optimize only one metric [OK]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard