Describe and analyze your hands on experience designing, operating, and maintaining infrastructure and systems. Candidates should be prepared with three to four concrete examples of systems or infrastructure projects they directly contributed to, including quantitative scale metrics such as user counts, requests per second, data volumes, throughput, and geographic distribution. Discuss architecture decisions and trade offs, component choices, platform boundaries, and how the design met requirements for scalability, reliability, performance, and security. Cover operational aspects such as deployments, configuration management, automation and infrastructure as code, monitoring and observability, incident response and remediation, capacity planning, and disaster recovery and business continuity. Include experience with large scale and multi region deployments, data center operations, networking at scale, and integration points. Also cover enterprise information technology topics where relevant, for example servers and endpoints, storage systems, networking hardware, identity and access infrastructure such as Active Directory, firewalls, routers and switches, and the differences and migration considerations between on premise and cloud infrastructure. Be ready to explain specific challenges faced, how issues were diagnosed and resolved, trade offs made, and the candidate's exact role and contributions.
HardTechnical
35 practiced
During a peak event services A→B→C cascade, CPU spikes and latencies rise but root cause is unclear. Describe a systematic triage plan: which observability signals you would correlate (metrics, traces, logs), instrumentation or tagging you'd add to reconstruct causal chains, temporal correlation techniques, and how to present findings and mitigations in a postmortem.
Sample Answer
Requirements / goal: find causal chain for CPU spike and rising latencies across services A→B→C during peak event, identify root cause, mitigate, and document learnings.Triage plan (high-level):1. Rapid hypothesis generation: overload (traffic surge), hot-path amplification, resource leak, GC/queue/backpressure collapse, or dependency slowdown.Observability signals to correlate:- Metrics: per-service throughput (rps), error rates, p99/p95 latency, CPU, memory, threads, GC pauses, runqueue length, IO wait, syscall rates, socket counts, queue lengths (work queues/backlogs), connection pools. Host/container-level: cgroup CPU throttling, OOM kills.- Traces: end-to-end distributed traces with span durations and tags for upstream/downstream calls; identify slow spans and fan-out patterns.- Logs: structured request IDs, stack traces, warnings (timeouts, retries), rate of retries/failures, upstream error messages.- Events: deploys, config changes, autoscaling actions, infra alerts.Instrumentation / tagging to add (if missing):- Propagate a global request id / trace id through A→B→C and background workers.- Tag spans with: route, feature-flag, throttling-state, queue-length at entry, pool usage, tenant/customer-id for high-cardinality analysis.- Emit structured logs with trace_id, span_id, latency_ms, CPU snapshot, GC metrics at request boundaries.- Add lightweight sampling of full-stack traces for high latency requests.Temporal correlation techniques:- Align timelines using trace_id and timestamps; normalize to UTC and account for clock drift using NTP offsets.- Use trace-driven sessionization: group traces by root trace id and correlate aggregate metrics (CPU, queue length) at that trace time window.- Sliding-window cross-correlation: compute lagged correlations between A’s rps/latency and B/C CPU/latency to find lead/lag relationships.- Causal inference heuristics: if increases in B’s service time consistently precede A’s retries → B likely root. Use event counts (retries, queue spikes) to identify amplification loops.- Heatmaps and flamegraphs: per-endpoint latency heatmap over time; CPU flamegraphs sampled during spike windows.Concrete steps during incident:- Identify top-10 slow traces and top endpoints by latency/CPU.- Pinpoint whether CPU is user vs system vs GC; collect flamegraphs or async pprof profiles.- Check retry loops: increased retries amplify load—throttle or circuit-break as emergency mitigation.- Short-term mitigations: add circuit-breakers, increase concurrency limits, shed traffic via rate-limiting, scale out C or B if stateless, roll back deploy if coincident.- Apply targeted traffic diversion (canary rollback) and observe immediate metric changes.Postmortem presentation:- Timeline: succinct chronology with annotated graphs (traffic, latency, CPU, errors) and traces highlighting causal chain.- Root cause analysis: show evidence—cross-correlation results, representative trace(s), logs showing retry/count spikes, flamegraph supporting CPU hotspots.- Contributing factors: missing attribution (no trace IDs), lack of queue-length metrics, brittle retry policy, low observability sampling.- Actions: Immediate (circuit-breaker/rate-limit, rollback), Short-term (add trace propagation, tag queue lengths, add pprof/heap sampling in peak), Long-term (backpressure, retry budgets, SLO adjustments, improved runbook).- Follow-up: owners, deadlines, verification criteria (tests / observability dashboards), and preventive monitoring (alerts on cross-service latency divergence, retry amplification, CPU/GC per-request).This approach ties metrics→traces→logs with added instrumentation and temporal correlation to reconstruct causal chains and produce actionable mitigations and a clear postmortem.
EasyTechnical
66 practiced
Write a bash script (or clear pseudo-code) that runs daily to rotate application logs, compress rotated files, upload archives to Amazon S3, and enforce a 30-day retention policy in S3. Specify assumptions, idempotency considerations, retries for transient failures, and how to verify success.
Sample Answer
To rotate daily, compress, upload to S3, and enforce 30-day retention idempotently with retries, use the following bash script (assumptions and verification notes follow).
bash
#!/usr/bin/env bash
set -euo pipefail
# CONFIG
LOG_DIR="/var/log/myapp"
ROTATE_DIR="/var/log/myapp/rotated"
S3_BUCKET="s3://myapp-logs"
RETENTION_DAYS=30
AWS_PROFILE="default" # or unset to use env creds
RETRIES=3
BACKOFF=2
timestamp=$(date -u +"%Y-%m-%d")
lockfile="/var/lock/logrotate_myapp.lock"
# simple lock for idempotency
exec 9>"$lockfile"
if ! flock -n 9; then
echo "Another instance is running; exiting."
exit 0
fi
mkdir -p "$ROTATE_DIR"
# rotate: move current logs to timestamped file and recreate empty log
for f in "$LOG_DIR"/*.log; do
[ -e "$f" ] || continue
base=$(basename "$f")
rotated="$ROTATE_DIR/${base}.${timestamp}"
if [ ! -e "$rotated.gz" ]; then
mv "$f" "$rotated"
# recreate original file with same permissions
touch "$f"
chown --reference="$rotated" "$f" || true
chmod --reference="$rotated" "$f" || true
else
echo "Rotated archive already exists for $base; skipping move."
fi
done
# compress any uncompressed rotated files
find "$ROTATE_DIR" -type f ! -name "*.gz" -name "*.log.*" -print0 | while IFS= read -r -d '' file; do
gzip -9 "$file"
done
# upload to S3 with retries and idempotency (use aws s3 cp which overwrites deterministically)
for obj in "$ROTATE_DIR"/*.gz; do
[ -e "$obj" ] || continue
key="$(basename "$obj")"
attempt=0
while [ $attempt -lt $RETRIES ]; do
if aws s3 cp "$obj" "$S3_BUCKET/$key" ${AWS_PROFILE:+--profile $AWS_PROFILE}; then
echo "Uploaded $key"
break
else
attempt=$((attempt+1))
sleep $((BACKOFF**attempt))
echo "Retry $attempt for $key"
fi
done
if [ $attempt -ge $RETRIES ]; then
echo "Failed to upload $key after $RETRIES attempts" >&2
exit 2
fi
done
# enforce retention in S3: delete objects older than RETENTION_DAYS
cutoff=$(date -u -d "$RETENTION_DAYS days ago" +"%Y-%m-%dT%H:%M:%SZ")
# list objects and delete those with LastModified < cutoff
aws s3api list-objects-v2 --bucket "${S3_BUCKET#s3://}" --query "Contents[?LastModified<='${cutoff}'].{Key:Key}" --output json ${AWS_PROFILE:+--profile $AWS_PROFILE} |
jq -r '.[].Key' | while read -r key; do
echo "Deleting old object: $key"
aws s3 rm "$S3_BUCKET/$key" ${AWS_PROFILE:+--profile $AWS_PROFILE}
done
# verification: ensure today's files exist in S3
missing=0
for obj in "$ROTATE_DIR"/*"$timestamp".gz; do
[ -e "$obj" ] || continue
key=$(basename "$obj")
if ! aws s3 ls "$S3_BUCKET/$key" ${AWS_PROFILE:+--profile $AWS_PROFILE} >/dev/null; then
echo "Verification failed: $key not in S3" >&2
missing=1
fi
done
if [ $missing -ne 0 ]; then
exit 3
fi
echo "Log rotation, upload, and retention enforcement completed successfully."
Assumptions:- awscli + jq installed and credentials available (env or profile).- Logs are simple .log files and safe to move (app reopens file or supports truncation).- S3 bucket exists.Idempotency:- Lockfile prevents concurrent runs.- Skip moving when rotated archive exists.- Upload uses deterministic keys (basename + date) so retries/duplicates are safe.Retries:- Configurable RETRIES with exponential backoff for uploads.- Exits non-zero if persistent failure to alert monitoring.Verification:- Script checks each uploaded file exists in S3 (aws s3 ls) and exits non-zero on mismatch.- Integrate with monitoring: run via cron/systemd timer and alert on non-zero exit, or emit metrics/logs.Notes / Improvements:- Use S3 lifecycle rules to offload retention instead of manual deletes.- For high-volume logs, use multipart upload or archive per-day tarballs.- If app holds file descriptors, use logrotate with postrotate signal to reopen logs instead of move.
EasyTechnical
41 practiced
Describe the differences between metrics, logs, and traces in an observability stack. Give two concrete examples of each (tool + data point), explain retention and cardinality trade-offs, and describe which of the three you would consult first for diagnosing a sudden high-latency user request.
Sample Answer
Metrics: numerical time-series summarizing system state (aggregated, low-cost to query).- Example 1: Prometheus — histogram metric http_request_duration_seconds (p50/p95/p99).- Example 2: Datadog — host.cpu.user percentage.Logs: semi-structured text events capturing rich context for individual events; high-detail, high-cardinality, good for forensic investigation.- Example 1: ELK (Elasticsearch) — nginx access log line with request path, status, user-agent, upstream_time.- Example 2: Splunk — application error stacktrace with request-id and user payload.Traces: distributed spans showing causal path and latencies across services for a single request; link metrics to logs.- Example 1: Jaeger — a trace with spans for frontend → auth → db and per-span duration.- Example 2: Zipkin — sampled trace with metadata (service, operation, tags) and timings.Retention and cardinality trade-offs:- Metrics: typically aggregated (histograms, counters). Low cardinality recommended (avoid per-user or per-request labels) because high-cardinality metrics blow up storage and query time. Retain aggregates longer (weeks/months) and raw high-resolution for shorter windows.- Logs: can carry arbitrarily high cardinality (request ids, user ids). Long retention is expensive; common practice is hot storage for recent logs (days/weeks) and cold/archival for longer retention. Use sampling, indexing, and redaction to control cost.- Traces: inherently high-cardinality and heavy (many spans per request). Sample traces (tail or adaptive sampling) to control volume. Retain sampled traces for shorter windows; store trace indices longer for quick lookup.Which to consult first for sudden high-latency user request:1. Metrics first — check latency SLOs, p95/p99, error rates, and affected endpoints to confirm scope and magnitude (fast, high-level).2. Traces second — inspect representative traces for the slow requests to see which service/span caused the latency and where time is spent.3. Logs last — once you have a suspect span/service and request-id from traces, use logs to read detailed application context, error messages, and payloads.This sequence optimizes speed (metrics) → root-cause path (traces) → deep forensic detail (logs) while minimizing noise and cost.
HardTechnical
41 practiced
Design an identity and access infrastructure for millions of end-users and thousands of internal services. Include SSO and federation (SAML/OIDC) for users, service-to-service auth (mutual TLS or token-based), ephemeral credentials and secrets rotation, key management, audit logging, and scaling considerations. Discuss onboarding automation and compliance controls.
Sample Answer
Requirements:- Authenticate millions of end-users (SSO, MFA), federate with partner IdPs (SAML/OIDC).- Authorize thousands of internal services (service-to-service auth), support ephemeral credentials, secrets rotation, centralized KMS, robust audit logging, high availability and scale.- Support automated onboarding and meet compliance (PCI/ISO/SOC2/GDPR).High-level architecture:- Identity Provider (IdP) cluster (OIDC/SAML) — scalable, multi-region, backed by user directory (LDAP/CloudID).- Federation gateway for external IdPs (SAML/OIDC) with token translation.- Access Broker / AuthN/AuthZ plane: OAuth2 Authorization Server issuing short-lived JWTs (access tokens) and refresh tokens; integrate MFA and conditional access.- Service identity platform: SPIFFE/SPIRE for workload identities + mTLS via mesh (Envoy/Istio) OR mutual TLS managed by sidecars.- Secret & credential manager: HashiCorp Vault (HA, auto-unseal with cloud KMS), dynamic secrets (DB creds, cloud STS), PKI issuance for ephemeral certs.- Key Management: Cloud KMS/HSM for root keys; Vault transit for encryption; periodic key rotation policies.- Audit & Monitoring: Immutable audit logs (append-only storage, WORM) fed to SIEM (Splunk/Elastic/Chronicle) with alerting, retention policies for compliance.- Onboarding automation: SCIM for user provisioning; IaC templates (Terraform) and CI/CD pipelines to provision service identities, RBAC roles, and Vault policies; self-service portal with approval workflows.- Compliance controls: RBAC + ABAC, least privilege, MFA required for admin actions, separation of duties, attestations, periodic access reviews, automated evidence collection, key rotation SLAs, encryption-at-rest/in-transit, signed audit trails.- Scaling & reliability: Multi-region active-active IdP and Vault clusters, stateless auth services behind autoscaling groups, token introspection cache (Redis) to reduce load, rate limiting, circuit breakers, health checks and SLOs (auth latency <100ms, 99.95% availability).- Edge cases & trade-offs: mTLS strongest for S2S but operationally complex; JWTs easier but require short TTLs + revocation strategies (token revocation list or reference tokens). Use hybrid: mTLS for critical services, JWTs for external/mobile clients.Key operational practices:- Enforce short-lived credentials (minutes–hours), automated rotation, emergency key compromise procedures, regular penetration testing.- Instrument detailed metrics (latency, error rates, token issuance rates), SLA-driven runbooks, and regular compliance audits.
MediumTechnical
33 practiced
Compare eventual, strong, and causal consistency models. For each of these three services — a shopping cart, a social feed, and a payment ledger — recommend a consistency model and justify architectural choices (replication technique, read-your-writes guarantees), including the latency and availability trade-offs.
Sample Answer
Brief comparison:- Strong consistency: operations appear in a single global order; reads always reflect the most recent write (e.g., linearizability). High coordination (consensus) needed → higher latency, lower write availability under partitions.- Eventual consistency: replicas converge given no new updates; reads may be stale. Very low coordination → low latency and high availability, but weaker correctness guarantees.- Causal consistency: intermediate: preserves causality (if A → B, reads see A before B) but allows concurrent unrelated updates to reorder. Lower coordination than strong, better semantics than eventual for user-perceived ordering.Recommendations per service1) Shopping cart — causal consistency- Why: User expects to see their recent adds/removes and a sensible order across devices; strict global order unnecessary.- Replication: multi-master geo-replication with per-user partitioning (shard by user ID) and vector clocks or dependency tracking to enforce causality.- Read-your-writes: required — ensure clients read their own session’s updates (sticky sessions or client-side session tokens with causal metadata).- Trade-offs: lower latency and high availability across regions; slightly more metadata overhead and conflict resolution for concurrent updates.2) Social feed — eventual or causal (prefer causal)- Why: Feed freshness matters but strict global linearizability across all users is unnecessary; ordering of interactions/comments benefits from causal guarantees.- Replication: fan-out-on-write with async replication + per-author partitioning; use causal middleware for interactions (likes/comments).- Read-your-writes: desirable for authors (so they see their posts/likes immediately); implement local write-forwarding or session guarantees.- Trade-offs: good availability and low read latency (reads served from local caches), eventual convergence for distant replicas; moderate complexity to track causality for user interactions.3) Payment ledger — strong consistency- Why: Financial correctness demands no double-spend, exact balances, and atomicity.- Replication: strongly-consistent consensus (Raft/Paxos) for the account shard or central transaction coordinator; leader-based replication.- Read-your-writes: yes, but ensured by strong consistency semantics.- Trade-offs: higher write latency and reduced availability during partitions (must sacrifice availability to maintain correctness per CAP), simpler reasoning and auditable correctness.Operational notes for SRE:- Instrument metrics for replication lag, conflict rates, and consensus leader latency.- Automate failover and have clear SLOs: tolerate higher P99 latency for ledger writes; optimize for lower latency and high availability for cart/feed reads.- Use client-facing hints (sticky sessions, local caches with short TTLs, background reconciliation) to balance UX vs correctness.
Unlock Full Question Bank
Get access to hundreds of Systems and Infrastructure Experience interview questions and detailed answers.