Amazon Site Reliability Engineer (SRE) Mid-Level Interview Preparation Guide

Site Reliability Engineer (SRE)

Amazon

Mid Level

6 rounds

Updated 6/22/2026

This guide is based on industry-standard SRE interview practices for mid-level candidates at large-scale technology companies. Specific Amazon SRE interview process details from official company sources were not available during research. The guide incorporates AWS-specific knowledge relevant to Amazon's infrastructure and emphasizes principles applicable to Amazon's scale and engineering culture.

Amazon's SRE interview process for mid-level candidates typically consists of a recruiter screening phase, followed by a technical phone screening, and multiple onsite interviews focusing on system design, infrastructure expertise, operational excellence, and cultural alignment. The process evaluates technical depth in distributed systems and cloud infrastructure, alongside soft skills including collaboration, ownership, and alignment with Amazon Leadership Principles.

Interview Rounds

Recruiter Screening

45 min5 focus topicsbehavioral

What to Expect

Initial phone call with recruiter followed by a second discussion after technical screens are scheduled. This round focuses on validating your background, understanding your motivation for the SRE role at Amazon, assessing cultural fit, and confirming your experience with reliability engineering and on-call responsibilities. The recruiter will discuss team structure, role expectations, compensation, and organizational context.

Tips & Advice

Research Amazon's leadership principles before the call and reference them when discussing your experience. Be honest about your on-call experience and comfort level with incident response. Clearly articulate why you want to transition to an SRE role and why Amazon specifically appeals to you. Ask thoughtful questions about the team's current reliability challenges and how SRE is positioned within the organization. Emphasize automation projects you've led independently and quantify their impact on system reliability or operational efficiency.

Focus Topics

Automation Philosophy and Infrastructure as Code Expertise

Demonstrate your philosophy about automating repetitive operational work and reducing toil through code. Provide concrete examples of large automation or Infrastructure as Code projects you've owned, tools used (Terraform, CloudFormation, Ansible), and quantified business impact.

Practice Interview

Study Questions

Cross-Functional Collaboration and Influence

Share examples of effective collaboration with development teams, product managers, and other engineers. Discuss times you've advocated for reliability investments, educated teams about SRE practices, or influenced architecture decisions to improve reliability.

Practice Interview

Study Questions

On-Call Experience and Operational Culture Fit

Discuss your comfort with on-call rotations, typical page frequency, your experience responding to critical incidents at 3 AM, and your perspective on blameless culture and continuous learning from failures. Share specific, concrete examples of high-pressure situations you've navigated.

Practice Interview

Study Questions

Motivation for SRE Role and Amazon

Articulate your genuine interest in reliability engineering as a discipline, why you're excited about the SRE role specifically (versus pure development), and what attracts you to Amazon. Connect your motivation to Amazon's customer obsession principle and the criticality of uptime for customer experience.

Practice Interview

Study Questions

Your SRE Background and Hands-On Experience

Discuss your practical experience with system reliability engineering, incident response, monitoring architecture, and automation projects. Highlight specific, quantifiable achievements: systems you've stabilized, MTTR improvements, automation projects that reduced operational toil. For mid-level, focus on projects you've owned end-to-end and areas where you made independent decisions.

Practice Interview

Study Questions

Technical Phone Screen

60 min6 focus topicstechnical

What to Expect

A 60-minute technical phone screen conducted by an SRE or senior engineer. This assesses your foundational systems knowledge, systematic troubleshooting approach, understanding of core infrastructure concepts, and problem-solving ability. You'll be asked questions spanning networking, Linux systems administration, monitoring and observability principles, and basic infrastructure automation. Some questions may involve live troubleshooting scenarios or short scripting tasks. The interviewer expects clear thinking, asking good clarifying questions, and explaining your reasoning.

Tips & Advice

Think out loud when troubleshooting - explain your mental model and reasoning. Use shared whiteboards or tools to draw diagrams for networking questions. Be honest about technologies you haven't used, but explain how you'd approach learning them. Focus on demonstrating strong fundamentals and your systematic problem-solving approach. For coding/scripting tasks, prioritize correctness and clarity over cleverness. Have a notebook nearby to work through problems. Ask clarifying questions before diving into solutions. Explain trade-offs when applicable.

Focus Topics

Service-Level Objectives (SLOs) and Error Budgets

Understanding of how SLOs are defined, measured, and used to guide decision-making. Knowledge of error budgets and their relationship to feature development velocity vs. reliability work. Ability to explain SLOs, SLIs, and SLAs and their distinct purposes.

Practice Interview

Study Questions

Infrastructure Automation and Scripting

Practical ability to write automation scripts (Python, Bash, etc.) to solve operational problems. You may write a script to parse logs, manage configuration, or automate deployment tasks. Prioritize clean, maintainable code that others could understand and modify.

Practice Interview

Study Questions

Monitoring, Observability, and Alerting Principles

Conceptual understanding of metrics, logs, traces, and how monitoring systems function. Knowledge of SLOs (Service Level Objectives), SLIs (Service Level Indicators), and alert design principles. Understanding the difference between monitoring and observability, and how to design effective alerting that minimizes false positives.

Practice Interview

Study Questions

Linux and Unix Systems Administration

Strong working knowledge of Linux command-line tools, file systems, process management, permissions, and system monitoring. Comfort with tools like ps, top, iostat, vmstat, df, du, and understanding of system resource allocation. Ability to read and interpret system logs, understand process states, and diagnose common system issues.

Practice Interview

Study Questions

Systematic Troubleshooting Methodology

Your approach to diagnosing unknown problems: gathering baseline information, forming hypotheses, testing systematically, and iterating. Be prepared for scenario-based questions like 'CPU usage spiked on this server - what do you check first?' Walk through your thinking.

Practice Interview

Study Questions

Networking Fundamentals and Troubleshooting

Deep understanding of TCP/IP networking, DNS resolution process, ports, sockets, and network connectivity. Practical troubleshooting using netstat, ss, tcpdump, ping, traceroute, nslookup, and understanding of routing, firewalls, and network protocols. Ability to diagnose connectivity issues systematically.

Practice Interview

Study Questions

System Design Interview - Onsite

75 min5 focus topicssystem design

What to Expect

A 75-90 minute onsite interview where you design a large-scale system emphasizing reliability, operational excellence, and scalability. You may design a distributed system architecture, define monitoring and alerting strategy, plan disaster recovery, or design a CI/CD pipeline for reliability. The focus is on thinking holistically about systems, considering failure scenarios, planning for scale, and making well-reasoned trade-offs. You should ask clarifying questions, engage in discussion, and iterate on your design based on feedback.

Tips & Advice

For mid-level, design systems that scale but avoid over-engineering. Start by clarifying requirements and scale assumptions. Draw clear architecture diagrams showing components, communication patterns, and data flow. Always consider reliability: redundancy, failover mechanisms, monitoring, and incident response. Discuss trade-offs openly (consistency vs. availability, latency vs. reliability, simplicity vs. features). Mention specific AWS services where appropriate. Justify your architectural choices and be open to the interviewer's challenges and alternative suggestions. Think about operational aspects: how would you monitor this? How would you deploy changes? What happens when components fail?

Focus Topics

Disaster Recovery, Failover, and Business Continuity Planning

Plan for major failure scenarios: service outages, data center failures, cascading failures, or data corruption. Define Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Discuss backup strategies, replication approaches, and failover procedures. Consider automation for recovery.

Practice Interview

Study Questions

AWS Services for Reliability and Operational Excellence

Incorporate relevant AWS services into your design: RDS or DynamoDB for databases, S3 for storage, CloudWatch for monitoring, ECS/EKS for containers, load balancers, auto-scaling groups, multi-region strategies, and managed disaster recovery services. Show familiarity with AWS operational tools.

Practice Interview

Study Questions

Defining Service-Level Objectives and Reliability Metrics

In your system design, define meaningful SLOs (e.g., 99.9% availability, P99 latency < 100ms), explain SLIs you'd measure to track these objectives, and discuss how error budgets guide decision-making. Connect reliability metrics to business impact and customer experience.

Practice Interview

Study Questions

Comprehensive Monitoring, Alerting, and Observability Architecture

Design the monitoring strategy: what metrics to collect, log aggregation strategy, distributed tracing for request flows, and alerting thresholds. Discuss how to detect incidents quickly while avoiding alert fatigue. Plan for post-incident analysis and observability of system behavior.

Practice Interview

Study Questions

Designing Scalable and Resilient Distributed Systems

Design systems that scale horizontally, handle partial failures gracefully, and maintain availability during failures. Understand load balancing strategies, data replication, caching layers, circuit breakers, retry mechanisms, and graceful degradation patterns. For mid-level, focus on practical, proven patterns rather than experimental approaches.

Practice Interview

Study Questions

AWS & Infrastructure Technical Interview - Onsite

60 min5 focus topicstechnical

What to Expect

A 60-minute deep technical interview on AWS services, infrastructure management, and operational practices. Expect practical questions about AWS service selection for specific use cases, troubleshooting real infrastructure problems, optimizing databases and compute resources, container orchestration, Infrastructure as Code, and security practices. Scenario-based questions might include troubleshooting RDS performance issues, designing multi-region failover, or securing container images. Expect to draw architecture diagrams and explain trade-offs.

Tips & Advice

Demonstrate deep, practical AWS knowledge grounded in real experience. For each AWS service you mention, be ready to explain your use case reasoning and trade-offs versus alternatives. Draw clear architecture diagrams. When presented with troubleshooting scenarios, follow a systematic approach: gather metrics from CloudWatch, check CloudTrail logs, form hypotheses, and test. Discuss security best practices (encryption, IAM policies, secrets management). Show familiarity with IaC tools and infrastructure versioning. Be ready to discuss performance optimization strategies for databases (indexing, query analysis, read replicas) and compute (right-sizing, reserved instances, auto-scaling policies).

Focus Topics

Infrastructure as Code and Configuration Management

Practical experience with Terraform or CloudFormation for infrastructure provisioning and management. Version control for infrastructure, testing infrastructure changes, managing state files, handling secrets, and rollback strategies. Understanding of IaC best practices and how to prevent configuration drift.

Practice Interview

Study Questions

Database Performance, Scaling, and Reliability

Database scaling strategies including read replicas, sharding, partitioning, and multi-region replication. Performance tuning (indexing, query optimization, connection pooling). Backup and recovery strategies, point-in-time restore capabilities, and RPO/RTO planning. Both relational (RDS/Aurora) and NoSQL (DynamoDB) approaches.

Practice Interview

Study Questions

Troubleshooting AWS Infrastructure Issues

Practical troubleshooting of common AWS problems: RDS high CPU or I/O issues (using Performance Insights), EC2 connectivity failures, EKS cluster issues (pod failures, resource contention), load balancer misconfiguration, and networking problems (security groups, NACLs, routing). Use CloudWatch metrics, CloudTrail logs, and AWS-specific tools systematically.

Practice Interview

Study Questions

Container Orchestration (ECS/EKS) and Containerized Deployments

Practical experience with containerized deployments using ECS or EKS, including deployment strategies, auto-scaling policies, health checks, rolling updates, rollback procedures, and container monitoring. Understanding of Docker fundamentals, container networking, and Kubernetes concepts if applicable.

Practice Interview

Study Questions

AWS Service Architecture and Selection Decisions

Deep knowledge of AWS services relevant to SRE: RDS (including Aurora, performance insights), DynamoDB, S3, EC2, ECS, EKS, Lambda, CloudWatch, CloudTrail, VPC, networking (load balancers, NAT gateways), and managed services. Understand when to use each service, trade-offs (e.g., RDS vs. DynamoDB, EC2 vs. ECS vs. EKS), cost implications, and operational characteristics.

Practice Interview

Study Questions

Operational Excellence & Incident Management - Onsite

60 min5 focus topicsbehavioral

What to Expect

A 60-minute interview focused on your operational mindset, real-world incident response experience, and how you drive reliability improvements. You'll discuss specific incidents you've handled (diagnosis, response, resolution, and learning), your approach to post-incident reviews and blameless culture, how you use error budgets to balance development velocity with reliability work, and your strategies for automating operational toil. Expect behavioral questions grounded in operational scenarios that reveal your judgment and leadership.

Tips & Advice

Use the STAR method (Situation, Task, Action, Result) for all examples. Focus on incidents where you took meaningful ownership, systematically debugged the problem, and drove improvements afterward. Discuss your understanding of blameless culture and how you approach post-mortems without blame or finger-pointing. Give quantifiable results when possible (reduced MTTR by 60%, automated manual process affecting 20 incidents per year, etc.). Demonstrate your continuous improvement mindset and how you've grown from failures. Show your reasoning about prioritizing reliability vs. feature development using error budgets. Be humble about knowledge gaps but confident in your ability and willingness to learn.

Focus Topics

Cross-Team Collaboration and Influencing Development Teams

Discuss how you partner with development teams to improve reliability. Share examples of educating developers about SRE practices, advocating for reliability improvements, or collaborating to resolve conflicts between velocity and reliability. Demonstrate your communication and influence skills.

Practice Interview

Study Questions

Identifying and Automating Operational Toil

Describe your approach to identifying repetitive, manual operational work (toil) and systematically automating it. Share examples of significant automation projects you've owned: what problem they solved, how much time they saved, and how that freed you to focus on higher-impact work.

Practice Interview

Study Questions

Blameless Culture and Post-Incident Reviews

Explain your understanding of why blameless culture matters and how it drives organizational learning. Discuss your approach to conducting post-incident reviews focused on systemic issues, not individual blame. Share examples of insights gained from post-mortems and how they led to systemic improvements.

Practice Interview

Study Questions

Real Incident Response and Crisis Management

Walk through a significant production incident you personally handled: what failed, how you diagnosed it, actions you took under pressure, how quickly you restored service, and what you learned. Be specific and honest about challenges and mistakes. For mid-level, focus on incidents where you led or made key contributions to resolution.

Practice Interview

Study Questions

Error Budgets and Prioritization of Reliability Work

Discuss how error budgets guide prioritization between reliability improvements and new features. Give specific examples of times you've advocated for reliability investments, communicated their necessity to development teams or management, and influenced resource allocation decisions.

Practice Interview

Study Questions

Behavioral & Amazon Leadership Principles - Onsite

60 min5 focus topicsbehavioral

What to Expect

A 60-minute behavioral interview with an Amazon manager or senior leader assessing cultural fit and alignment with Amazon Leadership Principles. You'll be asked about your problem-solving approach, collaboration style, learning mindset, ownership philosophy, and customer focus. Expect questions like 'Tell me about a time you failed and what you learned' or 'Describe a situation where you had to influence someone without direct authority.' The interviewer evaluates evidence of Amazon Leadership Principles including Customer Obsession, Ownership, Invent and Simplify, Are Right, A Lot, Learn and Be Curious, Think Big, and others.

Tips & Advice

Research and deeply internalize Amazon's Leadership Principles before the interview. Weave concrete examples demonstrating these principles throughout your responses. Use the STAR method for all behavioral questions. Focus on specific, quantifiable outcomes and business impact. Be genuine and authentic - Amazon values sincerity over polish. Show your customer-centric thinking by connecting reliability improvements to customer experience and business outcomes. Demonstrate ownership by describing problems you've owned end-to-end, even across team boundaries. Ask thoughtful questions about team structure, current challenges, and opportunities to grow. Be prepared to discuss long-term career goals and how the role aligns with them.

Focus Topics

Amazon Leadership Principle: Invent and Simplify

Your approach to finding creative solutions while keeping them simple and elegant. Share examples where you've challenged the status quo, questioned why something is done a certain way, found simpler approaches to complex problems, or invented novel solutions to operational challenges.

Practice Interview

Study Questions

Amazon Leadership Principle: Earn Trust

How you build and maintain trust within teams through reliability, communication, transparency, and listening. Share examples of strong relationships you've built across teams, situations where you've demonstrated integrity, and how you handle mistakes.

Practice Interview

Study Questions

Amazon Leadership Principle: Learn and Be Curious

Your commitment to continuous learning and intellectual curiosity. Discuss new technologies or practices you've learned, how you stay current in your field, and how you've taught others. Share examples of times you admitted knowledge gaps, asked for help, or sought feedback to improve.

Practice Interview

Study Questions

Amazon Leadership Principle: Ownership

Your approach to ownership: taking responsibility for outcomes regardless of setbacks, thinking long-term rather than short-term, acting on behalf of the business without being asked. Share examples where you've owned problems end-to-end, acted beyond your initial scope, stepped up when needed, and took responsibility for both successes and failures.

Practice Interview

Study Questions

Amazon Leadership Principle: Customer Obsession

How you prioritize customer impact in technical and operational decisions. For SRE, demonstrate how you connect reliability improvements to customer experience. Share examples of times you've deeply considered customer impact, advocated for reliability improvements because of customer benefit, or made trade-offs with customer value as the primary consideration.

Practice Interview

Study Questions

Frequently Asked Site Reliability Engineer (SRE) Interview Questions

Cloud Infrastructure Knowledge (AWS/GCP/Azure)EasyTechnical

57 practiced

Describe VPC networking components (subnets, route tables, internet gateway, NAT gateway, security groups, network ACLs). For a typical 3-tier application, sketch a recommended private/public subnet layout, explain traffic flows, and justify how this layout supports security and operational needs.

Sample Answer

VPC components — brief definitions:- Subnet: IP CIDR slice within a VPC; can be public (has route to Internet Gateway) or private (no direct IGW route).- Route table: Maps destination CIDRs to targets (IGW, NAT, peering, TGW, ENI); associated per-subnet.- Internet Gateway (IGW): Horizontally scaled gateway that enables inbound/outbound traffic between VPC and Internet for public subnets.- NAT Gateway (or NAT instance): Allows resources in private subnets to initiate outbound Internet connections (patching, image pulls) while preventing inbound initiation.- Security Group (SG): Stateful virtual firewall attached to ENIs; rules allow inbound/outbound by IP/port; return traffic auto-allowed.- Network ACL (NACL): Stateless subnet-level firewall; explicit allow/deny rules evaluated by rule number; must allow return traffic explicitly.

Recommended 3-tier layout (text sketch):- Public subnets (across AZs): Load balancers, bastion/jump hosts. Route table → IGW.- Private app subnets (across AZs): Application servers. Route table → NAT Gateway in public subnet.- Private DB subnets (across AZs, further restricted): Databases, caches. Route table → no NAT/IGW (optional minimal NAT for backups).

Traffic flows:- Client → Internet → IGW → Public subnet ELB → SG allows 80/443 from 0.0.0.0/0 → ELB forwards to app instances in private subnet (SG allows only ELB SG on necessary ports).- App instances → DB in DB subnet (SG allows only app SG on DB port). DB has no IGW access.- App instances outbound to Internet (OS/patches) go through NAT Gateway in public subnet; NAT’s elastic IP handles responses.- Admin SSH: Bastion in public subnet (SG restricts SSH to trusted IPs); from bastion to app/db via internal SG rules.

Why this supports security and operations:- Principle of least privilege: SGs restrict traffic by role (ELB→app, app→db). Databases never directly reachable from Internet.- Defense-in-depth: SGs (stateful) + NACLs (stateless, optional deny rules for broad threats) provide layered controls.- High availability: Subnets and NAT/IGW deployed per-AZ; multi-AZ ELB and DB replicas ensure failover.- Operational needs: NAT enables outbound updates while preventing inbound exposure; bastion + IAM + session logging/audit support secure admin access. Route tables and tagging simplify routing, automation, and IaC provisioning.- Monitoring/incident readiness: Flow logs on VPC/subnets + CloudWatch/Prometheus metrics help troubleshoot traffic anomalies and enforce SLOs.

Error Budget Management and Release VelocityEasyTechnical

35 practiced

You need to choose SLO target and measurement window for a newly created latency-sensitive service. Describe the criteria you would use to pick (a) the SLO percentage target and (b) the measurement window length (e.g., 30d vs 7d), including trade-offs and signals you would collect before finalizing the SLO.

Sample Answer

Situation: For a new latency-sensitive service I must pick an SLO percentage target and measurement window.

Approach / criteria for SLO percentage target:- Customer impact: map latency percentiles to user-visible harm (e.g., 95th / 99th latency causing timeouts or abandonment). Prefer an SLO that ensures acceptable UX—e.g., 99% of requests < target latency if business requires very snappy responses; 95–99% for less strict cases.- Business risk & cost: higher targets (99.9%+) increase ops and infra cost; balance value of reduced errors vs cost.- Baseline performance: measure current production latencies for 2–4 weeks. Pick a target slightly better than current median behavior but reachable with reasonable effort (avoid unreachable stretch SLO).- Error budget policy: choose target that leaves an actionable error budget (e.g., 0.1–1% errors) to allow safe deployment/canary/experimentation.

Criteria for measurement window length:- Traffic variability: if daily traffic or release cycles vary widely, use longer windows (30d) to smooth noise; if traffic is stable and you need fast feedback, shorter windows (7d).- Incident cadence & operational tempo: teams that want rapid feedback and tighter control may prefer 7d; for services with rare incidents, 30d avoids overreacting to one spike.- Seasonal patterns: if weekly patterns dominate, 7d captures weekly cycles; monthly windows capture rarer events.- Change lead time: longer windows delay detection of long-term regressions, shorter windows can cause noisy paging.

Trade-offs:- Short window (7d): faster detection, more sensitive, higher false alarm/noise — useful for active iteration.- Long window (30d): stable, less noisy, but slower to detect regressions and less useful for rapid rollout control.

Signals to collect before finalizing:- Latency histogram and percentiles (p50, p90, p95, p99)- Request volume and traffic patterns by hour/day- Error rates, timeouts, circuit-breaker trips- User-facing metrics: conversion, abandonment correlated with latency- Deployment/rollout frequency and past incident timelines- Capacity headroom and infra cost estimates to reach higher targets

Final decision pattern I use:1. Run 2–4 week baseline; examine p95/p99 and business impact.2. Select an SLO percentile that protects UX but is achievable (e.g., 99% at target latency).3. Choose window: 7d for active development/fast feedback or 30d for stable production with monthly reviews.4. Document error budget rules and revisit after a month of data.

Blameless Postmortem and Organizational LearningEasyTechnical

55 practiced

Explain how to build a precise timeline in a postmortem. List the timestamps to capture (alert fired, oncall acknowledged, mitigation started, service restored), evidence sources to link (logs, traces, deploy IDs), and how to handle timezones and clock drift in enterprise systems.

Sample Answer

To build a precise postmortem timeline, treat it like an evidence-driven forensic record: capture canonical timestamps, link verifiable artifacts, and normalize time so every entry is unambiguous.

Key timestamps to capture (with recommended source):- Alert fired — monitoring alert timestamp (Prometheus alertmanager / PagerDuty event ID)- On-call acknowledged — PagerDuty/phone log timestamp and acknowledgement event- Mitigation started — runbook execution start (automation job ID / manual action log)- Change/deploy initiated — CI/CD deploy ID and pipeline timestamps- Rollback or remediation completed — deploy/rollback ID and completion timestamp- Service restored / SLA met — synthetic probe/health-check timestamp and client-side success metrics- Post-fix verification window — range of probe passes after fix

Evidence sources to link:- Logs (correlate by request ID, session ID, or trace ID)- Distributed traces (span IDs showing root cause latency/failure)- Metrics dashboards and raw time-series data- Alerting and incident platform events (IDs for immutability)- Deploy/CI artifacts (commit SHA, image tag, pipeline logs)- Network captures or firewall logs if relevant

Handling timezones and clock drift:- Normalize everything to UTC in the timeline and display local tz only as annotation.- Prefer server-side timestamps from NTP/Chrony-synchronized hosts; record NTP status/offsets when available.- If hosts show drift, capture host clock offset at incident time (chronyc tracking / ntpq -p) and annotate corrected timestamps.- Use monotonic timestamps for measuring intervals where possible (e.g., process uptime, monotonic clocks in traces).- When correlating events from different systems, align by a dependable anchor (e.g., a synthetic probe or a single authoritative service) and compute offsets.

Practical tips:- Collect immutable IDs (event IDs, trace IDs) so others can re-fetch evidence.- Use a template: timestamp, actor, action, source, evidence link, notes.- Automate extraction of events (scripts to pull alert/PD/CI logs) to avoid human error.

Automation and ScriptingEasyTechnical

89 practiced

Explain idempotency in the context of operational automation and SRE scripts. Provide concrete examples of idempotent and non-idempotent operations, explain why idempotency matters for retries, scheduled jobs, and incident recovery, and list practical techniques (checks, CAS, temporary files, atomic renames) you'd use to make an automation idempotent.

Collaboration With Engineering and Product TeamsHardTechnical

88 practiced

You are asked to produce an SLO contract template to sign off with product for a monetized feature. Create a template that defines success metrics, measurement methods, reporting cadence, error budgets, remediation commitments, and any billing or penalty clauses. Explain negotiation points where product may push back.

Sample Answer

SLO Contract Template — Monetized Feature

Service / Feature- Name: [product.feature.name]- Owners: Product: [name/email]; SRE: [name/email]; Engineering: [team]

Scope & Business Context- Description: [short description of feature and monetization model]- Business impact: [ARR or % revenue tied to feature, % of customers affected]

Success Metrics (SLOs)- Primary SLO (availability): e.g., "99.95% successful payment processing per rolling 30d window"- Secondary SLOs: - Latency: "95th percentile payment authorization latency < 300ms" - Correctness: "Transaction consistency error rate < 0.01% per 30d" - UX-impact metric: "Checkout abandonment rate attributable to feature < 2% relative lift"- Measurement windows: rolling 30-day and calendar-month reporting

Measurement Methods- Sources: production telemetry from [service], payment gateway logs, API gateway metrics- Definitions: success = response status 2xx with downstream confirmation; failure = 5xx, timeout > 2s, or downstream declined due to system error- Instrumentation requirements: distributed tracing, request IDs, schema of logs (fields listed)- Data retention & auditability: raw metrics retained for 90 days; aggregation stored for 13 months

Reporting & Cadence- Weekly automated SLO dashboard (live)- Monthly written SLO report to stakeholders (incl. trends, incident summaries)- Quarterly review meeting: product + SRE + Eng to revisit SLOs and revenue assumptions

Error Budget Policy- Error budget = 1 - SLO (e.g., 0.05% over 30d)- Consumption accounting: each failure consumes budget proportionally by impact (e.g., failed paid transaction = 1 unit)- Burn rules: - If budget burn > 50% in 7 days → SRE notifies product and throttles non-essential releases - If budget fully consumed → freeze feature changes impacting production; emergency remediation plan executed

Remediation & Commitments- SRE commitments: - Response targets: P1 ack < 15 min, P2 ack < 1 hour - Runbooks and escalation paths in place - On-call remediation within SLA defined timelines- Product/Engineering commitments: - Prioritize hotfixes when error budget is breached - Provide business context for risky changes; participate in post-incident reviews- Post-incident: blameless RCA within 5 business days and remediation roadmap within 10 business days

Billing & Penalty Clauses (Monetized Feature)- Credits: If monthly SLO < target, product agrees to issue customer credits proportionate to downtime/revenue impact according to schedule: - 99.95–99.9% → 5% credit on affected transactions - 99.9–99% → 10% credit - <99% → 20% credit + joint executive review- Cap: total credits capped at [X]% of monthly revenue from the feature- Exceptions: exclusions for agreed maintenance windows, third-party provider outages with confirmed SLAs, customer-caused errors- Audit rights: product and SRE may audit metrics/flags used to calculate credits

Governance & Change Control- Any SLO change requires written sign-off from Product and SRE, with 30-day notice before enforcement- Emergency change board: SRE + product + engineering lead must approve hotfixes during error budget freeze

Negotiation Points & Likely Product Pushback- SLO level vs. revenue risk: Product will push for tighter SLOs to reassure customers but tighter SLOs increase operational cost — be prepared with cost estimates and risk trade-offs.- Measurement granularity: Product may request business-facing metrics (e.g., revenue lost) that require instrumentation — negotiate scope and delivery timeline.- Billing/credits severity: Product will resist high credit caps or frequent credits that affect revenue; offer tiered credit schedule and caps, plus carve-outs for third-party failures.- Maintenance windows & exceptions: Product may want narrow maintenance windows; negotiate predictable, communicated maintenance windows and emergency exception process.- Release freezes: Product will resist automatic freezes that block feature delivery—propose mitigations like gated canary releases, feature flags, and stricter rollout controls instead of full freezes.- RCA timeline: Product may demand faster RCAs; balance speed with quality by committing to interim updates and a full RCA within the agreed timeframe.

How to negotiate- Present SRE cost and risk analysis for different SLO targets.- Offer staged SLO tightening with instrumentation and automation investments committed in roadmap.- Use pilot/customer agreements for initial period (e.g., 90-day probation with relaxed penalties).- Emphasize shared ownership: align remediation playbooks and release controls to reduce probability of breaches.

This template can be adapted per feature; ensure everything is measurable, auditable, and has explicit sign-offs.

Cloud Infrastructure Knowledge (AWS/GCP/Azure)HardTechnical

38 practiced

Design a CI/CD pipeline and modular Terraform architecture to provision consistent networking and compute across AWS, GCP, and Azure. Explain how you would handle provider-specific differences, remote state management, secrets, and testing to ensure parity while minimizing duplication.

Sample Answer

Requirements (clarify): consistent VPC/VNet/subnet patterns, common tagging, VPN/Transit/GW, compute (VMs / instance templates / autoscaling), observability, IAM guardrails, drift protection, compliance.

High-level approach:- Single pipeline repo (infrastructure) with provider-specific directories and shared modules.- Terraform modules: "networking-core" (abstract interfaces: cidr_blocks, env, region, tags), "compute-core" (instance_size, autoscale_policies, ssh_keys), "common-services" (monitoring, logging, DNS).- Adapter modules per cloud that implement the abstract interfaces using provider resources (aws/, gcp/, azure/). Keep adapters thin to avoid duplication.

Handling provider differences:- Define a canonical resource model (what we need) and map to provider features in each adapter.- Use feature flags in module inputs (e.g., support_for_private_subnets: true) and conditional logic in adapters.- Encapsulate provider-only extras in optional extension modules (eg. AWS Transit Gateway, GCP Shared VPC).

Remote state management:- One backend per cloud and environment: S3+DynamoDB lock for AWS, GCS for GCP, Azure Storage for Azure.- Use a naming convention: infra-{org}-{env}-{cloud}-{component} and store Terraform state metadata in a central catalog (DynamoDB/GCS/Blob index) for discovery.- Enable state locking and encryption at rest; use IAM roles/service principals scoped to least privilege.

Secrets:- Do not store secrets in TF state or repo. Use secrets manager per cloud (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).- CI retrieves secrets via short-lived credentials: GitHub Actions/Opsgenie runners assume role via OIDC to cloud, fetch secrets, inject as env vars into Terraform.- Use SOPS/age for encrypted files if needed; never check secrets plaintext.

CI/CD:- Pipeline stages: validate (terraform fmt, tflint, checkov), plan (immutable plan artifact), policy/guardrail (OPA/Rego, Sentinel-like rules), approval gate for prod, apply using ephemeral runners with OIDC-auth.- Separate pipelines per cloud that reuse common steps via reusable workflow templates.- Version modules via registry (internal Terraform Registry or git tags). Promotes reproducible deployments.

Testing:- Unit: terraform validate + tflint + custom unit tests for modules (terratest in Go).- Integration: deploy to ephemeral test envs in each cloud using pipeline, run end-to-end smoke tests (connectivity, IAM, instance boot).- Compliance: run policy tests and drift detection (periodic run + resource drift alerts).- Use golden-configuration tests to compare resource attributes across clouds for parity where applicable.

Minimizing duplication:- Keep business logic and interfaces in common modules; only provider mapping in adapters.- Use helper libraries/scripts (Go/Python) for generating provider-specific bindings from canonical definitions when patterns repeat.- Centralize tagging, naming, and lifecycle settings.

Trade-offs:- Some cloud features don't map 1:1 — accept small provider-specific extension modules.- More upfront design and tests reduce long-term drift and firefighting.

This design yields consistent, testable, least-privilege infrastructure with clear separation between canonical intent and provider implementations, automated CI/CD, secure secret handling, and robust remote state control.

Error Budget Management and Release VelocityMediumTechnical

25 practiced

Implement a Python script (or describe code) that queries an error budget service and decides whether to proceed with a release. Inputs: current_error_budget_remaining_percent, burn_rate_last_1h, proposed_release_risk_score (0-100). Output: ALLOW, THROTTLE, or BLOCK. Explain thresholds you choose and why.

Sample Answer

Approach: combine error budget remaining, recent burn rate, and proposed release risk into a simple decision score and apply clear thresholds. Use conservative SRE-first defaults: block if budget exhausted or burning fast; throttle for borderline; allow only when budget healthy and burn low relative to risk.

python

def decide_release(remaining_pct, burn_rate_1h, risk_score):
    """
    remaining_pct: error budget remaining as percent (0-100)
    burn_rate_1h: burn rate over last hour (x means x times the allowed rate; 1.0 = normal)
    risk_score: proposed release risk 0-100 (higher = more risky)
    Returns: "ALLOW", "THROTTLE", or "BLOCK"
    """
    # Hard blocks
    if remaining_pct <= 0:
        return "BLOCK"            # no budget left
    if burn_rate_1h >= 4.0:
        return "BLOCK"            # runaway burn

    # Compute a normalized risk factor (0..1)
    risk_factor = risk_score / 100.0

    # Compute a composite pressure score: higher => more likely to block
    # weight burn more (we care about current trend), then remaining budget, and release risk
    pressure = (burn_rate_1h * 0.5) + ((1 - remaining_pct/100.0) * 0.3) + (risk_factor * 0.2)

    # Thresholds chosen to be conservative:
    # pressure < 0.7 => ALLOW, 0.7-1.2 => THROTTLE (canary, lower traffic), >1.2 => BLOCK
    if pressure < 0.7:
        return "ALLOW"
    if pressure < 1.2:
        return "THROTTLE"
    return "BLOCK"

Why these thresholds:- Block immediately when no budget or extreme burn (protect availability).- Burn rate weighted highest because fast consumption indicates imminent SLO breach.- Throttle region supports canary deployments to observe impact without full rollout.- Tunable constants: adjust weights/thresholds per service SLOs, traffic patterns, and historical incident tolerance.

Complexity: O(1) time/space. Edge cases: clamp inputs, handle NaN, integrate cooldown windows, and allow overrides for emergency patches with audit logging.

Blameless Postmortem and Organizational LearningHardTechnical

44 practiced

Draft a public (customer-facing) postmortem for a cloud provider network issue that caused four hours of downtime for a subset of customers. Include a clear timeline, customer impact, known root causes, mitigations applied, and steps to prevent recurrence. Also discuss legal/regulatory considerations for public disclosure.

Sample Answer

SummaryOn 2025-11-10 between 09:12 and 13:15 UTC, a network configuration error caused loss of connectivity for a subset of customers in Region A, resulting in up to four hours of degraded or unavailable service for ~2.3% of our active tenants. We take responsibility and are sharing findings, immediate mitigations, and steps to prevent recurrence.

Timeline (UTC)- 09:12 — Automated change: routing-policy update deployed to core-spine routers in Region A to optimize traffic engineering.- 09:13 — Monitoring alerts began: spikes in packet loss and BGP flap events for specific prefixes; some customer tunnels reported route withdrawals.- 09:18 — First on-call SRE paged; initial roll-forward attempted to rollback the change but failed due to automation race with parallel validation job.- 09:45 — Incident declared; mitigation: manual rollback initiated for affected devices.- 10:30 — Partial restoration for most customers; persistent failures for customers using enhanced DDoS-protected NAT gateways and overlapping BGP communities.- 11:10 — Identified root trigger: routing-policy contained an unintended community that matched customer-exposed prefixes, causing policy to suppress advertisement to upstream peers.- 11:30 — Targeted manual fixes applied to restore correct community tagging for affected prefixes.- 13:15 — All services verified restored; monitoring showed normalized flows; incident closed after verification and customer confirmations.

Customer impact- Affected: ~2.3% of tenants in Region A (mix of VPCs using provider-managed NAT, BGP, and direct connect).- Symptoms: inability to reach public IPs, intermittent packet loss, some BGP sessions showing route withdrawals.- Duration: up to ~4 hours for fully isolated customers; most restored within 1.5–2.5 hours after rollback/start of targeted fixes.- No customer data was accessed or altered; control-plane changes did not expose customer content.

Root cause (known)- A human-introduced configuration change deployed via automated pipeline contained an incorrect BGP community expression.- That community matched and suppressed advertisement of a subset of customer prefixes to upstream peers (intended for internal traffic shaping only).- Concurrent validation job created a race condition preventing automated rollback from completing promptly.- Insufficient unit tests in the config validation stage did not catch the community-match regression.

Mitigations applied (during incident)- Emergency manual rollback of the routing-policy on affected routers.- Targeted re-tagging of customer prefixes to remove problematic community matches.- Throttling of automated deployment pipeline to require manual approval for region-wide routing changes.- Customer communications: real-time status updates via status page, dedicated support channels, and follow-up emails.

Longer-term fixes (prevent recurrence)- Immediate (next 7 days): - Add unit and integration tests for routing-policy community patterns in CI. - Disable fully automated region-wide routing changes; require two-person approval and Canary rollout stages. - Resolve race condition in deployment/validation orchestration.- Medium-term (30–60 days): - Implement simulated dry-run in full staging environment that mirrors upstream peer interactions. - Improve monitoring alerts to surface community-suppressed advertisements within 60s. - Create automated canary rollback that preempts validation race conditions.- Long-term (90+ days): - Introduce immutable routing templates and stronger linting tools. - Conduct runbooks and tabletop exercises focused on network config rollback and BGP community failures.

Compensation and support- Affected customers will receive a credit per our SLA policy; account teams will reach out with details and assist with any remediation.- For customers who require written attestations for audit purposes, contact compliance@ourcloud.example.

Legal and regulatory considerations for public disclosure- We coordinated this disclosure with Legal and Compliance to ensure no privileged or customer-confidential information was exposed.- We avoided publishing IPs, customer identifiers, or internal secrets. Public postmortem focuses on system-level causes and corrective actions.- For regulated customers (e.g., financial, healthcare), we are offering tailored incident reports with additional technical detail under NDA where required for compliance audits.- We reviewed notification obligations (data breach laws, PCI/HIPAA/GLBA where applicable); because there was no data exfiltration, no statutory breach notification was required. If customers require specific notifications, we will assist.

What we learned- Tighten gating on network change automation; treat BGP community changes with higher safeguards.- Improve observability for policy-level misconfigurations.- Enhance incident playbooks and practice rollbacks to remove single points of failure in automation.

ContactFor questions or to request a customer-specific incident packet, please contact support@ourcloud.example or your account manager. We apologize for the disruption and are committed to preventing recurrence.

Automation and ScriptingMediumSystem Design

91 practiced

Design a rollback strategy for automated deployments that uses canary releases and feature flags. Define detection thresholds that trigger automated rollback, automated rollback steps, verification checks after rollback, and how to coordinate rollback if a database migration is part of the release.

Sample Answer

Requirements / constraints:- Use canary rollouts + feature flags to limit blast radius.- Automatic detection and rollback when reliability SLOs degrade.- Safe handling of DB migrations (prefer backwards-compatible / feature-flagged).- Integrate with monitoring (Prometheus), flag service (LaunchDarkly), and orchestration (K8s + Istio/Ingress).

Canary strategy:- Rollout percentages: 1% → 5% → 20% → 100%, with wait windows (e.g., 5m, 10m, 20m).- Feature flags gate user-facing features; default off until canary passes.

Detection thresholds (examples; tune per service baseline):- Error rate: sustained increase > 3× baseline error-rate or absolute > 1% for 5 minutes.- Latency: p95 latency increase > 2× baseline for 5 minutes or p50 increase > 50% for 10 minutes.- Saturation: CPU or mem > 85% for 5 minutes or instance OOMs/crashloop detected.- SLO breach: estimated error budget burn rate > 4×.- Business signals: conversion drop > 10% vs expected for 10 minutes.- Any crashloop/backoff or healthcheck failure on >10% of canary pods immediately triggers.

Automated rollback steps (orchestration script / pipeline):1. Pause rollout: stop advancing percentages and mark canary as paused.2. Toggle feature flag to off for canary and prod via feature-flag API (atomic).3. Shift traffic back: decrement canary weight to 0 and route to previous stable (Istio/Ingress or K8s rollout).4. Deploy previous stable image revision if needed (k8s rollout undo or CI artifact pin).5. If DB migration included, see DB coordination below.6. Run automated verification (see below).7. Notify on-call, create incident with rollout metadata, save logs/traces.

Implementation notes:- Use CI/CD job that listens to Prometheus Alertmanager webhook and triggers rollback playbook in GitOps (ArgoCD) or Helm/Kubectl ops. Ensure it’s idempotent and requires sign-off only for non-critical thresholds (but default is automated).

Verification checks after rollback:- Pod health: all pods Ready and passing k8s liveness/readiness.- Synthetic transactions: run smoke tests (login, critical path) with 95% success rate.- Metrics: error rate and p95 latency return to within 10% of baseline for 10 minutes.- Logs/traces: no spike in new exception signatures; distributed trace error rates normalized.- Canary isolation: ensure feature flag fully disabled and no new users exposed.- Automated sanity must pass before auto-closing the rollback; otherwise keep incident open.

Database migration coordination:Preferred pattern: backward-compatible migrations + feature-flagged activation.- Phase 0 (pre-deploy): Apply additive DB migrations only (add columns, new tables, not destructive). Use versioned migration tooling and run in a separate controlled job.- Phase 1 (deploy app): Deploy code that can read/write both old and new schema (dual-write or tolerant reads). Feature flag gates new behavior.- Phase 2 (enable feature): Flip feature flag for canary users only. If detection triggers rollback: - If migration was additive and compatible: rollback app and disable feature flag — DB remains compatible; no DB rollback needed. - If destructive/irreversible migration was mistakenly applied: automated rollback must not attempt destructive DB revert. Instead: - Pause traffic, switch to read-only or route to stable DB replica if available. - Run compensating migration script in CI after human approval OR promote fallback service that uses old schema view (if you have view-layer compatibility).- For migrations requiring schema downgrade: require manual approval; block automated full rollout until migration is reversible or wrapped in backward-compatible steps (blue-green DB, feature flags).- Use migration toggle table (feature-flags backed) and run migrations in small batches; record migration id + canary id for traceability.

Coordination & observability:- Centralized runbook: exact threshold values, playbook steps, CI job names, rollback authorization policy.- Audit logs: record flag toggles, traffic weights, image hashes.- Post-incident: capture root cause, adjust thresholds, and harden migrations (add migration checks & dry-runs).

Trade-offs:- Aggressive thresholds reduce user impact but risk false positives; tune with historical data.- Fully automated DB downgrade is risky — prefer blocking destructive migrations or requiring manual approval.

This strategy balances safety (feature flags, small canaries, additive migrations), speed (automated rollback on clear thresholds), and operational control (manual gates for risky DB changes).

Collaboration With Engineering and Product TeamsEasyTechnical

69 practiced

Explain the difference between an SLI, an SLO, and an SLA. For a web API product that serves user requests, give a concrete example SLI (for example p95 latency or success rate), propose a measurable SLO, and draft how you would word an SLA for external customers and a plain-language explanation for nontechnical product stakeholders.

Practice Site Reliability Engineer (SRE) questions across all topics

Additional Information

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse Site Reliability Engineer (SRE) jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs

Amazon Site Reliability Engineer (SRE) Mid-Level Interview Preparation Guide

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Automation Philosophy and Infrastructure as Code Expertise

Practice Interview

Study Questions

Cross-Functional Collaboration and Influence

Practice Interview

Study Questions

On-Call Experience and Operational Culture Fit

Practice Interview

Study Questions

Motivation for SRE Role and Amazon

Practice Interview

Study Questions

Your SRE Background and Hands-On Experience

Practice Interview

Study Questions

Technical Phone Screen

What to Expect

Tips & Advice

Focus Topics

Service-Level Objectives (SLOs) and Error Budgets

Practice Interview

Study Questions

Infrastructure Automation and Scripting

Practice Interview

Study Questions

Monitoring, Observability, and Alerting Principles

Practice Interview

Study Questions

Linux and Unix Systems Administration

Practice Interview

Study Questions

Systematic Troubleshooting Methodology

Practice Interview

Study Questions

Networking Fundamentals and Troubleshooting

Practice Interview

Study Questions

System Design Interview - Onsite

What to Expect

Tips & Advice

Focus Topics

Disaster Recovery, Failover, and Business Continuity Planning

Practice Interview

Study Questions

AWS Services for Reliability and Operational Excellence

Practice Interview

Study Questions

Defining Service-Level Objectives and Reliability Metrics

Practice Interview

Study Questions

Comprehensive Monitoring, Alerting, and Observability Architecture

Practice Interview

Study Questions

Designing Scalable and Resilient Distributed Systems

Practice Interview

Study Questions

AWS & Infrastructure Technical Interview - Onsite

What to Expect

Tips & Advice

Focus Topics

Infrastructure as Code and Configuration Management

Practice Interview

Study Questions

Database Performance, Scaling, and Reliability

Practice Interview

Study Questions

Troubleshooting AWS Infrastructure Issues

Practice Interview

Study Questions

Container Orchestration (ECS/EKS) and Containerized Deployments

Practice Interview

Study Questions

AWS Service Architecture and Selection Decisions