Technical Foundation and Self Assessment Questions

Covers baseline technical knowledge and the candidate's ability to honestly assess and communicate their technical strengths and weaknesses. Topics include fundamental infrastructure and networking concepts, operating system and protocol basics, core development and platform concepts relevant to the role, and the candidate's candid self evaluation of their depth in specific technologies. Interviewers use this to calibrate how technical the candidate is expected to be, identify areas for growth, and ensure alignment of expectations between product and engineering for collaboration.

MediumTechnical

34 practiced

A global customer asks that personal data stay within tenant-specific legal zones. Describe how you would map data residency and classification requirements into an architecture across AWS regions, including storage placement, failover behavior, backups, and access controls to ensure compliance.

Sample Answer

Requirements mapping: start by classifying data into residency tiers (Tier A — tenant-specific regulated PII that must not leave legal zone; Tier B — sensitive but allowed across approved zones; Tier C — non-sensitive). Capture per-tenant legal zone rules in a policy document/metadata store (e.g., DynamoDB or config repo) used by IaC and deployment pipelines.

High-level architecture:- AWS Organization with OU per legal zone; accounts per environment (prod/non-prod) scoped to OUs.- Deploy services regionally into the AWS region(s) that map to the tenant’s legal zone (e.g., eu-west-1 for GDPR-EU tenants, ca-central-1 for Canada).- Use regional VPCs, private subnets, ALBs/ECS/EKS clusters in-zone.

Storage placement & replication:- Tier A data: keep storage strictly in-region. S3 buckets, RDS, DynamoDB tables created in the tenant’s region. Disable cross-region replication for Tier A. Use S3 bucket policies and organization SCPs preventing PutObject or CreateBucket outside allowed regions.- Tier B: allow cross-region replication only to approved regions using S3 Replication rules or RDS cross-region read replicas, controlled by replication configuration and encryption keys.- Tier C: global replication allowed.

Encryption & keys:- Use AWS KMS with regional CMKs for Tier A; do NOT use multi-region keys for resident-only data. For Tier B/C, multi-region KMS can be used where allowed.- Enforce encryption-in-transit (TLS) and enforce TLS endpoints via ALB and service configs.

Failover behavior / DR:- For Tier A: prefer same-zone or same-region failover. Implement pilot-light or warm standby within the same legal zone (multiple AZs in the same region). If the region becomes unavailable and policy disallows leaving region, fail the request to restore after approval and follow contractual DR process. If policy allows cross-region DR to an approved fallback region, implement asynchronous replication to pre-authorized region with an automated playbook.- For Tier B/C: implement automatic cross-region failover using Route 53 health checks and weighted/priority routing and automated promotion of read-replicas to primary.

Backups:- Backups for Tier A: snapshots/backups retained and stored only in-region. Use AWS Backup with backup vaults in the same region and restrict copy actions via IAM/SCP. Snapshots of RDS and EBS must not be copied cross-region. For Tier B/C, configure cross-region backup copies per policy.- Encrypt backups with regional KMS keys. Maintain backup retention and periodic restore tests; record approvals for any cross-region restore.

Access controls & auditing:- IAM: least privilege roles scoped by account/region and assume-role flows as needed. Use IAM conditions on aws:RequestedRegion and aws:PrincipalOrgID. Apply SCPs blocking resource creation or data movement outside allowed regions.- Network: use VPC endpoints for S3/DynamoDB to avoid public egress; ensure data plane remains within AWS network.- Data tagging: enforce tags (tenant-id, data-tier, legal-zone) at creation; enforce via Service Control Policies or Lambda guardrails.- Logging: CloudTrail, S3 access logs, VPC Flow Logs stored in-region. Centralized monitoring can aggregate metadata but ensure logs containing PII are stored in-region; send only anonymized telemetry out.- Key management: limit who can export/replicate keys; log KMS usage.

Automation & compliance validation:- IaC (Terraform/CloudFormation) templates generate region-specific resources from tenant policy metadata. CI/CD validation prevents deployments that violate residency.- Continuous compliance: AWS Config rules, Custom Lambda rules, and automated remediation (e.g., detect cross-region S3 replication for Tier A and disable). Periodic attestation reports and audit trails for legal teams.

Trade-offs & justification:- Keeping Tier A strictly regional increases operational complexity (more accounts, deployments) but fulfills legal requirements. Where allowed, asynchronous replication and pilot-light reduce RTO while preserving residency constraints.- Use automation to reduce human error and ensure enforceable, auditable controls.

This mapping gives a clear, enforceable mapping from data classification to region-specific architecture, storage placement, failover, backups, and access controls suitable for regulatory compliance.

MediumTechnical

71 practiced

Enterprise customers require API stability. Propose an API versioning and deprecation strategy that minimizes client disruption. Describe versioning mechanisms (URL/versioned header/content negotiation), deprecation timelines, and how you'd coordinate with large customers who cannot upgrade quickly.

Sample Answer

Requirements & goals:- Minimize disruption for enterprise customers who expect stability and long upgrade cycles.- Make breaking changes explicit, enable smooth opt-in, and provide clear timelines and migration paths.

Versioning mechanism (recommended hybrid):- URL versioning for major (breaking) changes: /v1/..., /v2/... — simple, cache-friendly, explicit.- Versioned headers (Accept-Version) and content negotiation for minor/feature toggles and phased rollouts — enables gradual migration without URL churn.- Use SemVer semantics: MAJOR = breaking, MINOR = new backwards-compatible features, PATCH = bug fixes.

Deprecation timeline & policy:- Policy: Only MAJOR bumps can break clients. MINOR and PATCH preserve compatibility.- Deprecation phases: 1. Announcement (D0): Publish changelog, migration guide, sample code, and roadmap; notify via email, portal, and API response headers (Deprecation, Sunset). 2. Parallel support (90–180 days typical): Old and new versions run concurrently. Default traffic stays on current version. 3. Opt-in grace (additional 6–12 months for enterprise customers with contractually agreed extended support). 4. Sunset notice (30 days before shutdown): final reminders, export tools, and forced redirects only with explicit consent.- Timelines adjustable per contract; default public clients get shorter windows (e.g., 6 months), enterprise customers can negotiate extended windows.

Coordination with large/slow-to-upgrade customers:- Early engagement: notify key accounts at design time; provide technical migration workshops and dedicated migration engineers.- Custom transitional support: - Contractual extended support windows and SLAs. - Backwards-compatibility shims or proxy adapters (gateway-level translation) as a temporary bridge. - Provide client libraries/SDK updates, sample migration scripts, automated tests, and feature flags to toggle behaviors.- Test & validation: - Provide a stable staging sandbox mirroring production where customers can validate changes. - Offer compatibility test harnesses (postman collections, CI integration) so customers can verify quickly.- Communication cadence: - Publish deprecation in API docs, send direct emails, create portal tickets, and host quarterly migration syncs. - Include machine-readable headers: Deprecation: true; Deprecation-Date: <date>; Sunset-Date: <date>; Link: <migration-guide>.

Operational safeguards:- Monitor client usage by version; alert when high-value customers still on deprecated versions.- Rollback capability and feature flags for emergency hotfixes.- Maintain an internal deprecation dashboard mapping customers, usage, and contractual exceptions.

Trade-offs:- URL versioning is explicit but multiplies endpoints; header negotiation is flexible but more complex for caches and tooling. Hybrid gives clarity for breaking changes and flexibility for incremental rollouts.

This strategy balances explicitness, predictability, and enterprise flexibility—reducing surprises while giving large customers concrete migration options and support.

EasyTechnical

43 practiced

List the key metrics and signals you would include in an early observability plan for a new web service to enable basic SLA/SLO monitoring and rapid incident triage. Explain why each metric matters, for example latency, error rate, and saturation, and how you'd instrument them.

Sample Answer

Start with three golden signals plus a few supporting ones so you can both measure SLOs and triage fast.

1) Latency (p50, p95, p99; per-endpoint and end-to-end transaction)- Why: shows user experience and tail problems that break SLOs.- Instrumentation: use histograms (Prometheus/OpenTelemetry) for request duration with service/endpoint/tag dimensions; capture client-observed and server processing times.

2) Error rate (total and by class: 4xx vs 5xx, auth, dependency failures)- Why: indicates correctness vs client issues; spikes correlate to outages.- Instrumentation: counters for status-code buckets, error types; structured logs with error codes and correlation IDs.

3) Saturation (CPU, memory, thread/connection-pool usage, DB connection usage, queue length)- Why: capacity limits cause cascading failures; tells whether to scale or throttle.- Instrumentation: gauges for CPU/mem, pool metrics from runtimes/DB drivers, queue/backlog sizes.

4) Throughput (RPS, requests/sec per endpoint)- Why: normalizes load and ties latency/error changes to traffic spikes.- Instrumentation: counters and rate calculations.

5) Availability / Uptime and Health checks- Why: simple SLA indicator and fast detection.- Instrumentation: active health endpoints, synthetic transactions from uptime monitors.

6) Dependency health & latency (DB, cache, third-party APIs)- Why: most outages stem from dependencies.- Instrumentation: instrument outbound calls, measure latency/error per dependency, include circuit-breaker metrics.

7) Traces and request logs with correlation IDs- Why: root-cause of complex flows and distributed latency.- Instrumentation: distributed tracing (OpenTelemetry/Jaeger), structured logs (JSON) with trace IDs and user/request ids.

8) Business/Feature signals (transaction success, checkout rate)- Why: ties technical health to customer impact and SLOs.- Instrumentation: custom counters/gauges emitted from service logic.

Alerting & SLO approach:- Define SLOs (e.g., 99.9% requests < 500ms, error budget 0.1%).- Alert on symptoms (increasing error rate, p95 spike, saturation >70%) and on budget burn rather than raw metrics only.- Use escalation thresholds: symptom alert -> runbook link -> paging if unresolved.

Practical notes:- Tag metrics by service, region, environment, endpoint.- Use histogram buckets tuned to SLAs; sample traces to limit cost.- Ensure retention for metrics+logs long enough to investigate incidents.

EasyTechnical

36 practiced

Describe differences between block storage, file storage, and object storage. For storing user-uploaded images, database files, and VM disks respectively, explain which storage type you'd use and why, including performance, semantics, and cost trade-offs.

Sample Answer

Block, file, and object storage differ in interface, semantics, performance, and cost.

- Block storage: Presents raw fixed-size blocks to an OS (like a virtual disk). The OS formats and manages a filesystem. Low-level, high IOPS and low latency — good for databases and boot/VM disks. Examples: AWS EBS, SAN LUNs. Trade-offs: more expensive per GB for high performance; requires a host to manage metadata and consistency.

- File storage: Exposes a filesystem over the network (NFS/SMB). Good when multiple clients need POSIX semantics, directories, and file-level locking. Examples: EFS, Azure Files. Performance varies (throughput and latency) and often simpler for shared access; can be costlier at scale and has consistency/locking considerations.

- Object storage: Stores immutable objects with metadata and a global key via HTTP API (S3). Highly durable, massively scalable, low cost per GB, eventually consistent models depending on provider. Not POSIX, no partial-block writes, higher latency for small random I/O.

Recommended choices:- User-uploaded images: Object storage. Reason: cheap, highly durable, scalable, easy CDN integration, supports metadata and versioning. Performance: good for read-heavy workloads and large files; acceptable latency via caching. Cost: lowest storage cost, pay-per-request considerations.- Database files: Block storage. Reason: databases require low-latency, high-IOPS, synchronous block-level semantics and full control over filesystem and consistency. Performance: optimized for random reads/writes. Cost: higher, especially for provisioned IOPS.- VM disks: Block storage (or file storage for shared volumes). Reason: VM boot/root and local disks need block semantics and single-writer performance (EBS). If multiple VMs need a shared filesystem (e.g., app cluster), use file storage (NFS/EFS) or clustered filesystems. Trade-offs: block offers best performance; file offers shared access but may limit performance and consistency.

In short: use object for scalable assets (images), block for low-latency random I/O (DBs, VM root), and file when you need POSIX shared access.

HardSystem Design

38 practiced

Propose a zero-trust architecture for a distributed application spanning multiple clouds and on-premises partner environments. Cover service authentication (for example mutual TLS), certificate and key rotation, service mesh considerations, identity federation for partners, and operational controls to detect and remediate unauthorized access.

Sample Answer

Requirements:- Zero-trust: never implicitly trust network location; authenticate & authorize every request.- Multi-cloud + on-prem partner environments; low-latency inter-service comms; auditable, scalable ops.- Support partner identity federation, automated cert/key rotation, detection & remediation.

High-level architecture:- Per-environment control plane + federated trust fabric: central Trust Broker (PKI/CA + policy engine) + local Certificate Authorities (sub-CAs) per cloud/partner.- Data plane: service mesh sidecars (Envoy) in each environment to enforce mTLS, RBAC, and telemetry.- Identity: short-lived workload identities (SPIFFE IDs) issued by local CA, mapped to federated identities (OIDC/SAML) for human and partner services.

Core components & responsibilities:1. Trust Broker (central): issues root CA, global policy, trust bundles; exposes APIs for onboarding partners. HSM-backed root keys.2. Local CA: signs workload certificates (short TTL, e.g., 1 hour); integrated with SPIRE/SPIFFE.3. Service Mesh: sidecar enforces mTLS, per-method RBAC, rate limits, and mutual authentication; central policy propagated via control plane.4. Identity Federation: use OIDC/SAML to onboard partner IdPs; map external assertions to SPIFFE IDs via the Trust Broker; enforce attribute-based access control (ABAC).5. Rotation & Key Management: automated rotation pipeline—short-lived certs for workloads, periodic CA key rollover with cross-signing; keys stored and used via KMS/HSM (Cloud KMS + on-prem HSM).6. Monitoring & Ops: distributed telemetry (mTLS metadata, JWT claims) to SIEM and distributed tracing; anomaly detection (unusual identity, geo, service-to-service patterns) with alerting + automated playbooks.

Service authentication & mTLS:- All service-to-service traffic goes through mesh sidecars using mutual TLS with SPIFFE-issued certs. Sidecars validate SAN=SPIFFE ID and check revocation/expiry; control plane distributes trust bundles and RBAC policies.

Certificate & key rotation:- Issue short-lived leaf certs (minutes–hours) automatically via SPIRE agent on workload start.- Automated renewal: SPIRE rotates certs transparently; control plane coordinates CA key rotations using cross-signing: new CA signs old CA for rollout; publish new trust bundles before switching.- HSM-backed root private keys with strict KMS IAM controls and multi-party approval for root operations.

Service mesh considerations:- Use Envoy-based mesh (Istio/Consul Mesh/Linkerd) with mTLS offloaded to sidecars; enable policy checks in sidecar (JWT/OAuth introspection fallback disabled).- Multi-cluster: mesh federation using east-west gateways with enforced mTLS and mutual authentication between clusters; avoid wide-mesh spanning partner networks—use per-partner peered gateways and Trust Broker mappings.- Telemetry: enrich traces with SPIFFE IDs, JWT claims, and policy decisions.

Identity federation for partners:- Onboard partner IdP via OIDC/SAML to Trust Broker; map partner principals to SPIFFE IDs and scoped service accounts.- Use short-lived federation tokens exchanged for SPIFFE certs (token exchange RFC), constrained by scoping policies (time, allowed services, network).- Enforce least privilege via ABAC with attributes from partner assertions (role, contract id).

Operational controls (detect & remediate):- Preventive: strong RBAC, ABAC, network segmentation, deny-by-default firewall rules, sidecar-level L7 RBAC.- Detective: central logging of authn/authz decisions, mTLS telemetry, traces, token exchange events to SIEM; ML-based anomaly detection for unusual call graphs, token reuse, atypical geolocation or volume spikes.- Response: automated playbooks—revoke compromised SPIFFE IDs (push CRL or immediate policy deny), isolate affected workloads (network policy updates at mesh gateway), rotate affected keys, and notify stakeholders.- For partner incidents: enforce short-lived federated tokens and per-session auditing; ability to revoke partner federation immediately at Trust Broker.

Trade-offs & justifications:- Short-lived certs reduce blast radius but require highly-available CA agents (deploy SPIRE agents locally).- Central Trust Broker simplifies policy and audit but must be hardened and geographically redundant.- Mesh adds latency and operational complexity; justify where fine-grained auth/telemetry needed—use gateway-only patterns for legacy or high-throughput services.

This design ensures mutual authentication, automated rotation, federated partner access, and operational controls to detect and remediate unauthorized access while maintaining scalability and auditability.

Unlock Full Question Bank

Get access to hundreds of Technical Foundation and Self Assessment interview questions and detailed answers.

Join thousands of developers preparing for their dream job.