Amazon DevOps Engineer (Junior Level) - Comprehensive Interview Preparation Guide

Direct answer

Latency and throughput are not opposites by nature, they trade off through queueing: pushing more concurrent work through a fixed amount of processing capacity increases the time each request waits behind others, and holding latency low means keeping spare capacity in reserve rather than running it flat out. The right balance comes from setting an explicit target for both (a throughput floor and a tail-latency ceiling), then using queueing math plus load testing to find the utilization level where more throughput starts costing more latency than the business can absorb. What to measure at each load level: the full latency distribution, not just the average, including the 95th and 99th percentile (P95/P99), alongside the downstream business metric (conversion rate, task completion time) the latency target exists to protect.

Structured elaboration

Why the tension exists. Little's Law ties the three quantities together:

$L = \lambda W$

where $L$ is the average number of requests in the system (concurrency), $\lambda$ is the arrival rate (throughput), and $W$ is the average time a request spends in the system (latency). For a fixed amount of concurrency capacity $L$, pushing $\lambda$ up forces $W$ up. Throughput and latency are linked by whatever capacity sits between them, they only look independent at low load.

Decision criteria to walk through, in order:

• Is there a hard external constraint (a contractual service-level agreement, or SLA) versus a soft internal preference? Hard constraints bound the feasible region before you optimize anything.
• Is the load steady or bursty? A bursty workload needs headroom sized for the peak, not the average, or tail latency spikes during every burst.
• What is the true cost of extra capacity relative to the revenue or reliability cost of extra latency? If compute is cheap relative to the business impact of latency, buy headroom instead of accepting queueing.
• Which metric does the product actually care about, median latency almost never predicts user-visible pain, the tail does.

Process: baseline the current latency distribution and throughput, ramp load in steps while recording the full distribution at each step, locate the point where the P95 or P99 curve bends upward sharply (the "knee"), then correlate that knee to the business metric to decide whether operating past it is acceptable.

Worked example

Assume, for illustration, a single worker with an average service time of 10 ms per request ($S = 0.01\text{s}$), so its theoretical maximum throughput is $1/S = 100$ requests per second (RPS). Using the M/M/1 queueing approximation (a standard model for one server handling one request at a time, with randomly arriving requests and randomly varying service times, a common simplification for a single queue), the average wait time in queue at utilization $\rho = \lambda S$ is:

$W_q = \frac{\rho \cdot S}{1-\rho}$

Reproducing the middle row: $W_q = \dfrac{0.90 \times 0.01}{1-0.90} = \dfrac{0.009}{0.10} = 0.09\text{s} = 90\text{ms}$, so $W = 90 + 10 = 100\text{ms}$. Going from 70 to 90 RPS (a 29% throughput increase) roughly triples latency; the next 5.6% of throughput (90 to 95 RPS) roughly doubles it again. This is the shape of the trade-off: throughput gains near saturation cost latency disproportionately.

The same law sizes capacity to hit both targets at once. To sustain 5,000 RPS at an average latency target of 15 ms, the required in-flight concurrency is $L = \lambda W = 5000 \times 0.015 = 75$ concurrent request slots. If each server instance can hold 25 concurrent requests (its thread or connection budget), raw sizing needs $75 / 25 = 3$ instances, but running at 100% utilization guarantees queueing, so target roughly 65% utilization for headroom: $3 / 0.65 \approx 4.6$, round up to 5 instances.

Trade-offs & pitfalls

• Treating the median as the target metric hides exactly the users experiencing queueing delay, always instrument and alert on the tail, not the average.
• Adding raw compute capacity fixes queueing-induced latency but does nothing for latency caused by serialization cost or an inefficient algorithm, these are different bottleneck classes and need different fixes (see bottleneck-identification questions for the diagnostic process).
• Batching or coalescing requests can raise both average throughput and average latency-per-request while making the tail worse for whichever request lands first in a batch, batching trades individual completion time for aggregate efficiency and needs a separate tail-latency check.
• Autoscaling on CPU utilization alone can under-react to a pure queueing problem, alerting or scaling on the latency percentile itself, or on queue depth, catches the tension directly.
• Always tie the chosen operating point back to the business metric with real data (an A/B test or canary), a default like "P95 under 300 ms" is only correct if it is where the business metric actually degrades.

Direct answer

Stop an accidental production destroy with layered guardrails, not one control: a built-in per-resource lock in the config itself, an automated policy check that fails the pipeline if a plan touches a protected resource, and a human approval gate for anything that still gets through. None of these alone is sufficient, a resource-level lock protects one resource but not a whole environment, a policy check is only as good as its rule coverage, and a human approver gets fatigued reviewing the same plan every day. Layered together, each one catches what the others miss.

The guardrail layers

Worked example: policy-as-code and a built-in resource lock

The cheapest guardrail, right in the resource block:

resource "aws_db_instance" "prod" {
  # ...
  lifecycle {
    prevent_destroy = true
  }
}

This alone stops the single most common accident, an unintended destroy of one named resource, without needing any pipeline tooling at all. It doesn't help if the resource is later removed from the config entirely (which sidesteps the lifecycle block), so it's a floor, not a ceiling.

Sentinel policy (Terraform Enterprise), denying any destroy on a prod-tagged resource:

import "tfplan/v2" as tfplan

prod_resources = func() {
  result = []
  for tfplan.resource_changes as rc {
    if rc.change.actions contains "delete" {
      if rc.change.before.tags["environment"] == "prod" {
        result.append(rc)
      }
    }
  }
  return result
}()

main = rule {
  length(prod_resources) is 0
}

OPA/Rego equivalent for a Kubernetes admission flow, denying deletion of a prod-labeled object:

package kubernetes.admission

deny[msg] {
  input.request.operation == "DELETE"
  input.request.object.metadata.labels["env"] == "prod"
  msg := "Deleting a prod-labeled resource requires an approved exception"
}

CI staging: unauthenticated static checks (terraform validate, tflint, checkov) run on every PR; the policy check above runs against the generated plan before any apply job can start; non-prod environments auto-apply on merge; prod applies require a recorded manual approval step.

Trade-offs and pitfalls

• Every added gate slows deploys; apply risk-based gating, strict for prod, lighter for dev and staging, rather than the same friction everywhere, or engineers will look for ways around it.
• Tags are a control surface, not a guarantee: a resource missing its environment tag silently escapes tag-based policy rules, so treat "no tag" as a policy failure in its own right, not as "assume dev."
• prevent_destroy protects a resource that's still in the config; it does nothing once that resource block is deleted from the config entirely, plan-level policy is what catches that case.
• If a destroy does slip through: the recovery path is the same discipline as any state incident, restore from the most recent backup or snapshot (RDS snapshot, EBS snapshot, versioned S3 object), reconcile Terraform state to match what's actually there, and only then resume normal applies. Have that runbook written down before an incident, not during one.
• Policies that are too strict without an exception path get quietly bypassed under deadline pressure; build a reviewable, logged exception mechanism into the policy itself rather than leaving break-glass as an undocumented workaround.

Direct answer

When an urgent security issue and a sales-critical demo land the same day, the deciding factor is exposure, not who asked more forcefully: what could go wrong if the security issue waits, and what can still be preserved for the demo without touching the risky path. Usually both can be partially served: contain or fix the security issue first, and give sales something real to show that doesn't depend on the vulnerable code.

Structured elaboration

1. Triage both in parallel, fast

Read the security bulletin and the demo request together. Identify exactly which services, data, or endpoints the vulnerability touches, and exactly what the demo needs to show.

2. Weigh exposure, not urgency of the ask

A security issue usually carries broader exposure (any affected customer, potential data risk) than a single demo (one prospective deal). That asymmetry is normally the tiebreaker, but it should be checked rather than assumed: a demo that's the last step before a major renewal can occasionally weigh more than a low-severity, well-contained finding.

3. Look for a path that serves both

A scoped hotfix with a canary rollout (releasing the fix to a small slice of traffic first, watching it closely, then rolling out to everyone once it looks clean) for the security issue, paired with a sandboxed or stubbed version of the feature for the demo, often means sales isn't actually blocked on the mainline fix landing first.

4. Communicate the decision and the reasoning immediately

Both sides need a concrete plan with timestamps, not just a priority call: what's happening, by when, and what the other side gets in the meantime.

Worked example

The patch ships to a small share of traffic first while being monitored, then rolls out fully once confirmed clean. In parallel, a second engineer builds a stubbed version of the requested feature specifically for the demo environment, so sales can present it without depending on the code currently under remediation. Both sides get an update within a couple of hours: security gets an ETA for full rollout, sales gets confirmation the demo will work and exactly how.

Trade-offs and pitfalls

• Defaulting to whichever request comes from the louder or more senior stakeholder, rather than actual exposure, is the most common failure mode here.
• Building a demo-only workaround without labeling it clearly as temporary risks it quietly becoming the real implementation, skipping the proper fix.
• Failing to give both sides a concrete timeline turns a reasonable prioritization call into a trust problem, even when the call itself was correct.
• Treating this as strictly either/or, instead of looking for a path that partially serves both, wastes an option that's usually available.

Direct answer
A decision genuinely reflects a stated value, rather than merely being compatible with it, when the value actually changed what you chose to do, not just how you described it afterward. The strongest answers make that causal link explicit: what you would have done differently if the value hadn't been a factor.

Structured elaboration

• Situation and task: the decision point, described briefly.
• The counterfactual test: name what the default, easier choice would have been, and what specifically made you choose differently.
• Action: what you actually did, including who you had to convince or coordinate with.
• Result: the outcome, and ideally a signal that the choice was validated rather than merely feeling principled at the time.

Worked example
Faced with a choice between shipping a quick, directionally useful analysis in time for a decision meeting, or spending an additional two weeks on a more rigorous version, the default and professionally "safer" choice would have been to wait for rigor. Choosing to ship the quicker, clearly caveated version instead, because the business decision had a hard deadline and a rigorous-but-late analysis would have been useless, shows a genuine trade-off rather than a reflexive one. The decision was validated when the more rigorous follow-up analysis, completed afterward, confirmed the same direction, meaning the faster call hadn't cost the business a wrong decision.

Trade-offs and pitfalls
A story where the value and the easy choice happen to be the same thing doesn't actually demonstrate anything, since no real trade-off was made; choose a story with genuine tension in it. Naming the value first and building a story to fit it, rather than the reverse, tends to produce something that sounds rationalized rather than genuine; a genuinely reflective answer usually names the counterfactual without being asked. A result stated only as "and it felt right" is weaker than any concrete validation signal, even an imperfect one.

Direct answer

This is a program, not a ticket. It needs a quantified risk case that earns the resourcing, a prioritization method that isn't just "whoever complains loudest," an accountability model across teams you don't directly manage, and a reporting cadence that shows real progress without asking every team to stop shipping.

Structured elaboration

• Quantify the risk: a number leadership can weigh, error-budget burn rate (how fast a team is using up its error budget, the allowed amount of below-target reliability performance before breaching its objective), incident frequency, a vulnerability's exposure window, stated with its uncertainty.
• Prioritize: by risk reduced per unit of effort, not by which team is loudest.
• Milestones and accountability: name one owner per workstream on each team, not "the team," one shared tracker, and a regular cross-team sync, so accountability doesn't default back to you alone.
• Resourcing and buy-in: the quantified risk case plus a phased, bounded ask, not "give us a quarter of everyone's time," and the cost of not funding it stated plainly.
• Measure and communicate without stalling delivery: cap remediation at an agreed share of each team's capacity, and report against the risk number monthly, not just "we're working on it."

Worked example

A shared internal library used by 8 teams has a security vulnerability, and 3 of those teams are separately burning through their error budget from deployments touching the same shared code, both rooted in the same under-owned dependency. Quantify: a 6-week exposure window at current remediation pace, and 140% of the 3 teams' combined monthly error budget already burned. Prioritize: patch the vulnerability first, the highest risk reduced per effort, then address the shared-code instability, bigger effort, bigger payoff. Accountability: each of the 8 teams names one workstream owner, tracked on one shared board with a weekly 15-minute sync across all 8. Resourcing: each team caps remediation at 15% of capacity for 3 weeks, framed against the cost of not doing it, one exploited vulnerability hitting all 8 teams' services at once. Reporting: a monthly one-page update tracking vulnerability status and error-budget burn rate, until burn rate returns under 100%.

Trade-offs and pitfalls

Asking for open-ended dedicated time from every team reads as a real threat to their own delivery and usually gets rejected. Prioritizing by whichever team escalates loudest wastes the program's limited leverage. And reporting only "percent complete" instead of the underlying risk number can look reassuring while the actual exposure hasn't moved.

Secrets needed by tests specifically (an API key for a sandbox third-party service, a database credential for an integration test suite) have a distinct wrinkle compared to production secrets: they're often needed across many short-lived, ephemeral, parallel test environments, and the temptation to just check them into a test-config file is strong because 'it's just a test credential'.

Comparing the approaches

Static secrets in the CI provider's own store (a GitHub Actions or GitLab CI secret variable): simplest to set up, but the credential is long-lived and shared across every test run until someone manually rotates it, and access control is only as granular as the CI provider's own permission model for that secret.

Encrypted files checked into the repo: avoids the CI provider dependency but pushes the key-management problem onto the repository itself (where's the decryption key stored, and who can access it), and still leaves a long-lived credential sitting in the repository's history even in encrypted form.

Dedicated secrets managers (Vault, cloud Secrets Manager): the strongest option, since it enables short-lived, dynamically-issued test credentials scoped to exactly the test run that needs them, and every issuance is centrally logged; the added complexity is a real dependency for every ephemeral test environment to authenticate against.

CI-native secret stores: functionally similar to the static-secrets case above, differing mainly in which system holds the value; the same long-lived-credential caveat applies.

Recommendation, and why

Dynamic, short-lived secrets via a dedicated secrets manager is the right target for anything beyond a small team, specifically because test credentials often grant access to a shared sandbox or staging environment that, if leaked, could be abused far beyond just 'a broken test'; the cost is worth it once test-environment access represents real risk, not just inconvenience.

Least-privilege and auditability for ephemeral PR environments

Each ephemeral test environment (spun up per pull request, then torn down) should authenticate with its own scoped, short-lived identity, tied to that specific PR or build, so a test credential issued for one PR's environment cannot be reused once that environment is destroyed; auditability then means every credential issuance is logged against a specific PR and build ID, so an unusual usage pattern (a credential used from an environment it wasn't issued to) is immediately detectable.

Rotation for test secrets specifically

For a dedicated secrets manager, rotation is largely automatic: since credentials are issued dynamically per test run, there is nothing long-lived to rotate on a schedule at all, each run simply gets a fresh, short-lived credential. For the static-secret approaches (CI-provider store, encrypted files, CI-native store), rotation has to be a deliberate, recurring process: rotate on a fixed cadence regardless of whether a leak is suspected, and rotate immediately, out of cadence, the moment a leak is suspected. Either way, the safe sequencing is the same overlap-then-invalidate pattern used for production credential rotation generally: generate the replacement credential first, update every consumer (the CI provider's secret store, the encrypted file, or the CI-native store) to use it, confirm at least one real pipeline run succeeds against the new credential, and only then revoke or invalidate the old one, keeping both valid for a brief overlap window instead of cutting over instantly. Revoking the old credential before the new one is confirmed working risks an outage mid-rotation: every pipeline run failing to authenticate until someone notices and rolls back. Doing it in the opposite order, generate first, verify, then revoke, means a rotation gone wrong just leaves the old credential live a little longer, not the pipeline broken.

Avoiding accidental leakage

Test output is a genuine, often-overlooked leak vector: test frameworks frequently print request/response bodies or environment dumps on failure for debugging purposes, and a test credential embedded in that debug output leaks the same way a production secret would in a build log; masking test secrets in CI log output and being deliberate about what a test failure handler actually prints closes this specific gap.

Trade-offs

The dynamic-secrets approach adds real setup cost (every ephemeral test environment needs to authenticate to the secrets manager, which is more moving parts than just reading an environment variable); for a team running a handful of tests against genuinely low-risk sandbox services, the static-secret approach may be a proportionate choice, but that judgment should be revisited as soon as the test credentials in question could reach anything more sensitive than a disposable sandbox.

Work from the outside in: start with Application Load Balancer (ALB) metrics since they show whether the problem sits between the client and your service or inside it, then use AWS X-Ray to find which downstream call within the request is actually slow, then drop into logs at that specific span to find the root cause. Amazon CloudWatch instance-level metrics answer one narrow question: is the underlying compute starved of resources. The pattern that separates infrastructure from application problems is whether the slowness correlates with resource saturation (CPU, memory, disk queue) or with a specific downstream call showing up consistently in X-Ray traces.

Diagnostic order and what each layer tells you

1. ALB metrics first: TargetResponseTime (time the backend took to respond), HTTPCode_Target_5XX_Count, HealthyHostCount, and RequestCountPerTarget (average request load per target in the target group; ALB has no client-facing queue-depth metric the way Classic Load Balancers do). Rising TargetResponseTime with a steady HealthyHostCount points at the application; a rising RequestCountPerTarget alongside a dropping HealthyHostCount points at capacity, the same targets absorbing more load because fewer of them are healthy.
2. CloudWatch instance and service metrics: CPU utilization, memory (if the CloudWatch agent publishes it), disk queue length, and status check failures. Sustained CPU above roughly 70 to 80 percent, a growing disk queue, or a failed status check is a real infrastructure signal; normal-looking infrastructure metrics next to a slow ALB response time is a strong sign the problem lives in application code or a downstream dependency, not the host.
3. X-Ray traces: the service map and per-trace latency breakdown show which segment of the request is actually slow, an internal computation, a database call, or a third-party API. A long span on a downstream call, a slow SQL query, a saturated connection pool, is an application or dependency problem even though it shows up as backend latency at the ALB.
4. Logs: once X-Ray points at a specific segment, application logs, database slow-query logs, and container standard output around that timestamp and trace ID confirm the actual cause, a stack trace, a lock wait, a garbage-collection pause, or a connection pool timeout.

Patterns that separate infrastructure from application

• Infrastructure: CPU, memory, or disk saturation across many hosts, failing status checks, or RequestCountPerTarget rising alongside a drop in HealthyHostCount, all independent of what any individual trace shows.
• Application: normal host-level metrics, but TargetResponseTime and X-Ray both point at a specific span (a database call, a downstream API, a lock), and logs at that timestamp show exceptions, long garbage-collection pauses, or connection pool exhaustion.
• Mixed, and easy to misdiagnose: Auto Scaling Group cooldown delays, or a database hitting its own connection or throughput limit, look infrastructure-shaped on a dashboard but are actually caused by an upstream traffic pattern or an application-side connection leak.

Tying this to service-level objectives and alerting

Set alarm thresholds on the same metrics used above, tied to an actual service-level objective (SLO), for example 99.9 percent of requests under 500 milliseconds, rather than an arbitrary round number, so an alarm firing means the error budget (the allowed amount of failure or excess latency for the period) is actually at risk. Track the error budget's burn rate rather than paging on every threshold breach, since a two-minute blip that recovers on its own should not wake anyone up, while a sustained burn that will exhaust the monthly budget in a few hours should.

Worked example

Checkout latency creeps from a 99th-percentile of 200 milliseconds to 1.2 seconds over 20 minutes. ALB metrics show TargetResponseTime climbing while HealthyHostCount stays flat and RequestCountPerTarget stays flat too, ruling out a capacity problem. CloudWatch shows CPU at 25 percent across all targets, ruling out host saturation. X-Ray's service map shows the slow span is consistently a call to the inventory service, with its own latency climbing in the trace timeline. Logs on the inventory service around that window show a specific slow-query pattern: a full table scan on an unindexed column that only becomes slow once the table crossed a size threshold. That is a database and application problem end to end, not infrastructure, and the fix, adding an index, has nothing to do with scaling anything.

Trade-offs and pitfalls

• Jumping straight to logs before narrowing scope with ALB and CloudWatch metrics wastes time searching a haystack. The metrics exist specifically to tell you where to look before you start reading logs.
• X-Ray requires sampling and instrumentation to already be in place before the incident. If tracing is not enabled, or the sampling rate is too low to capture the slow requests, you lose the fastest path to the root cause and fall back to correlating logs by timestamp, which is slower and noisier.
• Alarming on raw metric thresholds instead of an SLO-tied burn rate produces either too many pages (threshold too tight) or missed real degradations (threshold too loose). Revisit thresholds against actual historical percentiles, not a guess.
• A downstream dependency showing up as "your" latency in X-Ray is still your incident to manage even though the root cause sits in a service you do not own. Know the escalation path to that team before you need it.

Direct answer

With no policy or code changes, an intermittent AccessDenied on an assumed role is usually a session-lifetime issue: temporary credentials expire after a fixed duration, and a long-running process reusing one set fails once they lapse. Check CloudTrail's AssumeRole event for issue and expiry time against the failing calls' timestamps.

Structured elaboration

• AssumeRole defaults to a 3,600-second session unless the caller requests longer and the role's MaxSessionDuration (up to 43,200s) allows it.
• Pull CloudTrail's AssumeRole history and correlate the credential expiry against when failures started.
• Also rule out IAM eventual consistency after any recent role or policy change, even one nobody remembers making.
• Fix durably by having the client refresh credentials proactively; most SDKs' default credential provider chain does this unless a team manually cached credentials.

Worked example

A 90-minute (5,400s) job that assumed the role once at the default 3,600s duration:

$5{,}400 - 3{,}600 = 1{,}800 \text{ seconds before expiry, mid-job}$

Every call after the one-hour mark fails, matching "some requests fail, nothing changed."

Trade-offs and pitfalls

Just extending the session duration widens the blast radius if credentials leak; fix the client's refresh behavior instead.

What the interviewer probes next

How the SDK's default credential chain handles refresh, and how you'd alert specifically on ExpiredToken.

The symptom pattern, restarts clustered right after deploys, correlated 5xx errors, points at the liveness probe killing pods mid-warmup rather than an application bug; the fix is to confirm that with evidence, retune the probe, and prove the new values are safe before rolling them out everywhere.

Confirming the misconfiguration

Start from the pod's own restart history and event log:

$ kubectl describe pod api-6f7d9-p2x4k -n prod
...
Restart Count:  4
Last State:     Terminated
  Reason:       Error
  Exit Code:    137
Events:
  Type     Reason     Age   From     Message
  ----     ------     ----  ----     -------
  Warning  Unhealthy  90s   kubelet  Liveness probe failed: HTTP probe failed with statuscode: 503
  Normal   Killing    88s   kubelet  Container api failed liveness probe, will be restarted

Exit code 137 (SIGKILL) combined with a Liveness probe failed event, not an application panic in the logs, is the signature. Then correlate timing:

• Application logs (kubectl logs -p <pod>) around the restart timestamp: if the app was still running startup work (cache warm, DB migration, JIT warmup) when the kill happened, that confirms the probe fired before the app was actually ready to be judged.
• Metrics: plot kube_pod_container_status_restarts_total against 5xx rate and request latency over the same window. A pattern where restarts spike right after each deploy and 5xx errors track the restarts (rather than preceding them) supports the probe-misconfiguration theory over an application regression.

What to change

The core fix is usually a role confusion: liveness should only catch a truly stuck or deadlocked process, and readiness should be the one gating traffic during startup. If liveness is doing readiness's job, it kills pods that are merely slow to start, not actually broken.

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30
  periodSeconds: 2
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  timeoutSeconds: 3
  failureThreshold: 3

A startupProbe (available since Kubernetes 1.20 as stable) is the cleanest fix for exactly this failure mode: while it's still failing, Kubernetes suspends liveness and readiness checks entirely, so a slow-starting container gets as long as failureThreshold * periodSeconds to finish initializing without either probe having a chance to kill or block traffic to it prematurely. Once it succeeds once, liveness and readiness take over on their own (tighter) schedules. Without a startup probe, the fallback is a generous initialDelaySeconds on liveness set comfortably above the observed warmup time, plus a failureThreshold above 1 so a single slow health check doesn't trigger a kill.

Validating the change safely

• Roll the new probe configuration to a small subset of pods first (a canary Deployment or a small maxSurge slice), not the whole fleet at once.
• Watch restart count, 5xx rate, and p95/p99 latency for that subset specifically for a period that comfortably spans several worst-case startup times, not just a couple of minutes.
• Keep the previous, known-bad configuration one kubectl rollout undo away, and have the specific rollback command ready before starting, not something to look up mid-incident.
• Once the canary subset shows zero probe-related restarts and normal 5xx rates across that observation window, roll the change out to the rest of the fleet the same way you'd roll out any other change, not as a special hotfix path.

Trade-offs and pitfalls

• Making liveness too lenient (very high failureThreshold, long periodSeconds) trades away its actual purpose, catching a genuinely wedged process, for safety during startup; a startup probe avoids that trade entirely by handling the startup window separately.
• Both liveness and readiness pointed at the same endpoint with the same thresholds is a common shortcut that reintroduces this exact bug: whatever makes liveness too strict for startup makes it too strict forever, since it's the same check.
• Fixing the probe without first confirming it's actually the cause (timing correlation, exit code 137, the Liveness probe failed event) risks masking a real application startup regression by simply giving it more time to fail more quietly.

Direct answer: "Most impactful" is a claim about scale, reach, or durability of a change, not automatically the project with the single biggest percentage. Come with a short comparison across two or three candidate projects on a common yardstick (people affected, durability of the fix, or how core the process was), and be ready to justify why that yardstick and not just report a number.

A framework for ranking impact across projects

When you don't have hard numbers

• Use proxy metrics: adoption rate, ticket volume, "still in use N months later," or direct stakeholder feedback.
• State explicitly that it's a proxy, not a causal measurement, rather than dressing it up as a precise result.
• Reach and durability are often easier to state honestly than a precise causal percentage, and they're still a legitimate basis for "most impactful."

Worked example (illustrative, arithmetic shown)

Two candidate projects: Project A fixed a rare edge-case bug, reducing its error rate from an estimated 3% to under 1% on the narrow path it affected. Project B rebuilt the new-user onboarding flow that every signup passes through; its effect on conversion wasn't cleanly isolated, but it has been in production for 12 months and the product runs roughly 2,000 signups a month. Reach comparison: Project B touches 2,000 x 12 = 24,000 users over that period, versus Project A's narrow edge case affecting a small estimated fraction of a much smaller baseline. Project B is presented as "most impactful" on reach and durability grounds, even though Project A has the cleaner percentage, and that trade-off is named explicitly rather than hidden.

Trade-offs and pitfalls

• Picking the project with the single biggest reported percentage without checking how narrow its scope was is a common overclaim.
• Confusing "impactful to me personally" with "impactful to the business" weakens the answer under questioning.
• Presenting a proxy metric as if it were a measured causal result erodes credibility once challenged.
• Failing to acknowledge a plausible rival project when asked invites doubt about the whole answer.