k6 Scenario Interview Questions for Performance Testers (2026)

TL;DR

Model demand with the correct k6 executor, define tagged service objectives, and validate both the generator and system telemetry. State assumptions, trade-offs, verification steps, and stopping conditions.

Key Takeaways

• Choose open or closed workload models from business behavior.
• Gate latency, errors, checks, and business transactions with scoped thresholds.
• Verify generator capacity before blaming the application.
• Control correlation, test data, cache state, and metric cardinality.
• Use server telemetry and traces to locate bottlenecks.
• Version tools, scripts, data, and run metadata for reproducibility.

The most useful k6 scenario interview questions performance testers receive test judgment, not memorized syntax. A strong answer turns business behavior into a defensible workload, sets measurable pass criteria, protects test validity, and connects k6 results to system evidence.

This hub gives you 50 distinct scenario questions, concise model answers, and runnable k6 examples. Use it with the API performance testing tutorial, the cloud-native performance testing guide, and the performance bottleneck investigation guide.

TL;DR

Start by stating assumptions. Name the workload model, expected rate, duration, data policy, and service objective. Finish by explaining how you would verify the generator and locate the constraint.

1. k6 Scenario Interview Questions Performance Testers Get About Metrics

Q: What is the difference between latency and response time?

Latency is time spent waiting after a request is sent, while response time often covers the full client-observed duration, including connection setup, redirects, transfer, and tool overhead. I define the timer because tools label these fields differently. For an API, I separate DNS, connect, TLS, waiting, and receive time. That decomposition keeps a slow handshake from being blamed on application code.

Q: What is throughput, and can higher throughput be bad?

Throughput is completed work per unit of time, such as successful orders per second. Raw request count can rise because retries or errors create extra traffic, so I report business throughput beside request throughput. Higher throughput is bad if it comes from skipped validation, overload, or breached latency objectives. The useful measure is correct work finished within the SLO.

Q: How do you explain p95 correctly?

A p95 latency of 600 ms means 95 percent of samples completed in 600 ms or less and 5 percent took longer. It does not mean one request spent 95 percent of its time waiting. I also state the window, transaction, and sample count. For low volume, I supplement p99 with slow observations and traces.

Q: What is coordinated omission?

Coordinated omission occurs when a generator waits for a slow response before scheduling the next request and therefore misses arrivals real users would have made. Its histogram understates pain when the service stalls. Arrival-rate executors reduce the bias by scheduling independently of completion. I still inspect dropped iterations because an underprovisioned injector can create a misleadingly gentle workload.

Q: What is Little's Law?

Little's Law says average concurrency equals arrival rate multiplied by average time in the system: L = lambda times W. At 20 checkout starts per second and two seconds average duration, roughly 40 are in flight. It helps size VUs and sanity-check dashboards. It assumes a stable window, so I avoid applying it to a rapidly growing queue.

2. Workload Modeling and k6 Executors

Q: How do you calculate an error budget?

For a 99.9 percent availability SLO, the allowed bad fraction is 0.1 percent. Across one million eligible requests that permits 1,000 bad requests, assuming a request-based SLI. I define which failures count and exclude only agreed events. Test gates should reuse those event semantics rather than inventing a convenient success rule.

Q: What is SLO burn rate?

Burn rate compares the current bad-event rate with the rate the error budget can sustain. A burn rate of one consumes budget evenly; ten consumes it ten times faster. During a test I examine short and longer windows so a brief disturbance is distinguishable from sustained exhaustion. It provides urgency and duration context missing from a standalone error percentage.

Q: How do you derive a latency threshold from an SLO?

I begin with the production SLI, such as 99 percent of successful search requests below 800 ms, then map it to the environment and scenario. The same threshold is defensible only if traffic, data, dependencies, and capacity are equivalent. Otherwise I document a mapped target. I never choose the gate after seeing the result.

Q: How do you model an ecommerce funnel?

I obtain proportions for landing, search, product detail, cart, and checkout, then model transitions rather than five unrelated percentages. Users abandon at each stage, while purchases require unique inventory and payment data. Think time and session reuse matter. I verify the resulting endpoint rates against analytics because a plausible journey mix can still create an implausible backend mix.

Q: How do you model retries?

Retries belong in the model when clients, proxies, or services perform them, but the generator must not silently hide the first failure. I cap attempts, reproduce backoff and jitter, and tag originals versus retries. Under distress they can amplify traffic into a storm. Reports show user-visible success, attempts, and capacity consumed by recovery.

A complete executor example should run as written:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  scenarios: {
    catalog: {
      executor: 'constant-arrival-rate',
      rate: 5,
      timeUnit: '1s',
      duration: '30s',
      preAllocatedVUs: 5,
      maxVUs: 20,
      exec: 'browse',
      tags: { journey: 'catalog' },
    },
  },
  thresholds: {
    'http_req_failed{journey:catalog}': ['rate<0.01'],
    'http_req_duration{journey:catalog}': ['p(95)<500'],
    checks: ['rate>0.99'],
  },
};

const baseUrl = __ENV.BASE_URL || 'https://test.k6.io';

export function browse() {
  const response = http.get(`${baseUrl}/`, { tags: { operation: 'home' } });
  check(response, {
    'status is 200': (r) => r.status === 200,
    'body has title': (r) => r.body.includes('Collection of simple web-pages'),
  });
  sleep(1);
}

Verify it with k6 run script.js. The summary must list the catalog scenario, checks, and both thresholded HTTP metrics.

3. k6 Checks, Thresholds, and CI Gates

Q: How do you choose ramp-up duration?

Ramp-up should expose intermediate behavior without accidentally becoming a spike. I consider autoscaling windows, cache warming, connection setup, and real traffic growth. Capacity studies often use stepped plateaus so the curve's knee is visible. A flash-sale exercise uses a fast ramp deliberately because scaling delay is part of that risk.

Q: Why include warm-up?

Warm-up allows JIT compilation, pools, caches, and scaling to reach a named state before steady measurement. I do not discard it universally because cold-start behavior may be the actual product risk. Reports label cold and steady results separately. This prevents initialization noise from corrupting comparisons without hiding the worst customer minutes.

Q: How do you select data cardinality?

Cardinality must reproduce cache reuse, index selectivity, lock contention, and business constraints. Ten thousand VUs reading one product measures a hot cache; completely unique reads may be unrealistically cold. I derive distributions from sanitized analytics and reserve unique records for writes. Duplicate keys or shared carts are harness defects, not capacity evidence.

Q: Which k6 executor fits a public API?

I usually choose constant-arrival-rate or ramping-arrival-rate because external starts should not slow just because responses slow. I size preAllocatedVUs from expected iteration duration and set a justified maxVUs ceiling. Dropped iterations are a validity signal. A fixed worker population may instead call for constant-vus or per-vu-iterations.

Q: How do k6 checks differ from thresholds?

A check records whether an individual response satisfies a condition, but a failed check does not automatically fail the process. A threshold evaluates an aggregate metric and can fail the run, such as a check failure rate below one percent. I add tagged custom metrics for business transactions. Validation and release policy remain separate.

A CI-focused threshold example can be run without external packages:

import http from 'k6/http';

export const options = {
  vus: 2,
  duration: '10s',
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<750'],
  },
};

export default function () {
  http.get(__ENV.BASE_URL || 'https://test.k6.io/');
}

Verify this third example with k6 run ci-thresholds.js; a successful run prints two green threshold evaluations and exits with status zero.

Use custom metrics when the business transaction spans more than one request:

import http from 'k6/http';
import { check } from 'k6';
import { Trend, Rate } from 'k6/metrics';

const journeyDuration = new Trend('journey_duration', true);
const journeyFailed = new Rate('journey_failed');
const baseUrl = __ENV.BASE_URL || 'https://test.k6.io';

export const options = {
  vus: 1,
  iterations: 1,
  thresholds: {
    journey_duration: ['p(95)<1000'],
    journey_failed: ['rate<0.01'],
  },
};

export default function () {
  const started = Date.now();
  const response = http.get(`${baseUrl}/`);
  const ok = check(response, { 'journey succeeds': (r) => r.status === 200 });
  journeyFailed.add(!ok);
  journeyDuration.add(Date.now() - started);
}

Verify it with k6 run script.js and confirm that journey_duration and journey_failed appear in the end-of-test summary.

4. Correlation, Test Data, and Script Safety

Q: What does dropped_iterations mean in k6?

It means an arrival-rate executor could not start scheduled work, often because maxVUs was reached or the injector lacked resources. Achieved demand no longer matches intended demand, so I treat it as a validity alarm. I inspect iteration duration and generator health, adjust capacity, and rerun. Accepting drops can make an unstable service look healthy at reduced traffic.

Q: How do you run k6 in CI?

Scripts and thresholds live in version control, secrets come from the CI store, and summaries plus raw metrics are archived. Pull requests run short stable scenarios against isolated targets; scheduled jobs run representative load. Exit codes enforce predeclared gates. Trend comparisons require matched topology and data, so noise in shared staging does not automatically block release.

Q: How do you use CSV Data Set Config safely?

I decide whether rows are shared or scoped, disable recycling when uniqueness is required, and stop threads at end-of-file. Distributed workers need disjoint shards or a documented collision plan. Secrets remain outside source control. A preflight proves the row count covers maximum users and every state-changing request uses its intended identity.

Q: How do you identify generator saturation?

I monitor injector CPU, memory, garbage collection, file descriptors, bandwidth, connection errors, scheduling, and dropped work. I compare one injector with a horizontally split run at equal total load. If more generators increase achieved demand while service metrics barely change, the harness was limiting. Capacity claims require headroom on every generator.

Q: How do you diagnose a database bottleneck?

I correlate transaction latency with database CPU, active connections, pool waits, slow queries, locks, IOPS, cache hit ratio, and replication lag. An exhausted application pool does not prove slow SQL because leaked connections can create the queue. Traces identify dominant statements. I alter one hypothesis and rerun the same model for before-and-after evidence.

5. Generator Capacity and Environment Fidelity

Q: How do you recognize connection-pool saturation?

Pool wait time and pending borrowers grow while downstream execution may remain moderate. Throughput plateaus near effective concurrency and application workers wait for leases. I inspect leaks, transaction duration, pool sizing, downstream limits, and timeouts together. Enlarging the pool blindly can move overload into the database and make failure worse.

Q: What does growing queue depth mean?

A brief rise that drains can absorb a burst as designed. A continuously growing queue means arrivals exceed sustainable service rate even if producers return quickly. I pair depth with oldest-message age, enqueue and completion rates, retries, and consumer saturation. User harm may appear later, so a fast producer endpoint does not prove system health.

Q: How do you investigate a memory leak?

I hold representative load across many garbage-collection cycles and plot live-set memory after collections, not raw peaks. Allocation rate, pauses, container RSS, native memory, object counts, and restarts add context. A rising post-GC floor is stronger evidence than one spike. Controlled heap dumps reveal which objects remain retained.

Q: How does autoscaling affect a performance test?

I test steady capacity and scaling behavior separately. The run records initial replicas, scaling signal, thresholds, cooldowns, startup time, maximum replicas, and downstream limits. During a ramp I compare demand with readiness and latency. Starting fully scaled misses elasticity risk, while autoscaling cannot solve a database ceiling.

Q: How do you performance test Kubernetes services?

I capture requests and limits, replicas, placement, throttling, restarts, readiness, autoscaler events, ingress behavior, and node pressure alongside application SLIs. CPU throttling can happen below node saturation when container limits are tight. The generator should not share constrained target nodes. Topology and scaling state belong in every run record.

6. Diagnosing Application Bottlenecks

Q: How do you test caching behavior?

I define expected hit ratio and key distribution, then separate cold start, warm steady state, eviction pressure, and cache failure. Metrics include hit and miss latency, evictions, memory, origin traffic, stampedes, and stale responses. Random unique keys are not automatically realistic. A fast cache returning old prices still fails the test.

Q: How do you test asynchronous workflows?

I measure from accepted command to observable completion, not just the quick HTTP 202. Correlation IDs join producer, queue, consumer, and persistence timestamps. I watch backlog, oldest age, consumer throughput, duplicates, retries, and dead letters. Completion checks use bounded polling or events so the harness does not become a polling attack.

Q: How do you test gRPC performance?

I model unary and streaming calls separately, preserve protobuf sizes and metadata, and account for HTTP/2 connection reuse. Metrics cover status, message throughput, stream setup, per-message delay, flow control, cancellations, and saturation. The selected tool must support real streaming semantics. Multiplexing and connection lifetime are workload inputs, not invisible defaults.

Q: How do you test WebSockets?

I separate connection establishment from message traffic, then model concurrent sockets, send rate, receive latency, heartbeats, reconnects, and duration. File-descriptor limits can fail before CPU. Message IDs validate ordering and loss. One million idle connections and ten thousand active chat sessions answer different capacity questions, so socket count alone is inadequate.

Q: How do you include browser performance?

Protocol load establishes backend capacity while a smaller browser cohort measures rendering, JavaScript, Web Vitals, and waterfalls. Thousands of browsers are costly and usually unnecessary. I correlate browser timing with APIs and CDN behavior under representative backend load. The layers answer different risks and prevent a fast API from hiding a blocked main thread.

7. Distributed Systems and Cloud Workloads

Q: How do you compare two builds fairly?

I hold workload, data state, topology, configuration, warm-up, duration, and background traffic constant, then repeat runs to measure variance. Comparisons use transaction distributions and successful throughput, not one average. Build IDs and feature flags are metadata. If environments differ, I label the result directional rather than inventing a precise regression percentage.

Q: How do you handle noisy results?

I measure run-to-run variation before defining a regression gate. Shared neighbors, batch jobs, cache state, autoscaling, data drift, and network paths commonly add noise. Isolation, fixed capacity, longer windows, repeats, or robust statistics can help. Widening every threshold until failures disappear destroys the test's decision value.

Q: What should abort a performance test?

Abort rules protect systems and people: wrong production target, excessive real-user errors, dependency distress, corruption, runaway cost, generator failure, or agreed infrastructure limits. Owners and stop commands are named beforehand. A release threshold is not always an immediate abort. Destructive writes stop instantly, while a latency miss may continue for diagnosis.

Q: How do you report a failed run?

I lead with target demand, achieved successful throughput, failed SLI, validity, and release risk. Then I show a small set of correlated graphs, a supported bottleneck hypothesis, and next experiments with owners. Raw dashboards belong in appendices. Decision makers need evidence and options, not hundreds of percentile screenshots.

Q: How do you test rate limiting?

I verify steady allowance, bursts, identity scope, response code, headers, retry guidance, and recovery after reset. Distributed clients must use intended keys or addresses. Rejected work should be cheap and never reach protected dependencies. Client backoff is bounded and jittered so the exercise exposes rather than hides retry oscillation.

8. Reliability, Recovery, and Overload

Q: How do you validate graceful degradation?

I define which features may become slower, stale, queued, or unavailable while critical journeys retain their objective. Then I constrain a dependency under controlled load and verify fallbacks, timeouts, circuit breakers, and recovery. Avoiding a crash is insufficient. Responses must remain correct and restored capacity must not trigger a retry flood.

Q: How do you model third-party dependencies?

I include a real sandbox when its latency and limits are part of the requirement, otherwise use a controlled stub with documented distributions and failure modes. Quotas, cost, and authorization are agreed before execution. The report states which path was real. A perfect stub cannot certify a payment provider, while uncontrolled calls can cause an incident.

Q: How do you test a retry storm?

I inject bounded downstream failures while clients and services use production retry policies. Metrics distinguish original calls, attempts, backoff delay, queue growth, and final user outcomes. Jitter should prevent synchronized waves. Safety limits stop amplification before shared systems are harmed. Recovery is successful only when backlog drains without another surge.

Q: How do you test timeout settings?

I introduce controlled latency around each boundary and verify the caller times out before its own upstream deadline. Budgets should shrink down the call chain, leaving time to return a useful failure. I inspect abandoned work, connection reuse, retries, and thread occupancy. A short client timeout can improve perceived speed while hidden server work continues consuming capacity.

Q: How do feature flags affect comparisons?

Flags change code paths, calls, payloads, and cache shapes, so their states are stored with run metadata. I test the configuration intended for release and sometimes exercise both branches to quantify rollout risk. A baseline with the flag off cannot validate the on path. Percentage rollouts also change the effective scenario mix.

9. Advanced k6 Scenario Interview Questions Performance Testers Should Practice

Q: How do you performance test search?

The data corpus, query popularity, filters, pagination, typo rate, indexing freshness, and cache distribution must resemble use. I separate query latency from indexing and measure empty, common, and expensive searches. Success includes relevance and complete responses, not HTTP 200 alone. A tiny synthetic index can conceal memory, shard, and merge behavior.

Q: How do you test file uploads?

I model realistic size and type distributions, multipart overhead, concurrent streams, network shaping, antivirus scanning, object storage, metadata persistence, and asynchronous processing. Checks verify integrity and completion. Generator disk and bandwidth require headroom. Upload acceptance latency and time until the file becomes usable are distinct user-facing measures.

Q: What is the knee of a capacity curve?

It is the region where added demand stops producing proportional useful throughput and latency begins rising sharply, often as a resource saturates or a queue grows. I find it with stepped load and steady plateaus. The exact point includes error and business-success criteria. Operating capacity needs headroom below the knee, not a target placed directly on it.

Q: How do you test recovery after overload?

After controlled stress, I reduce arrivals and observe whether latency, errors, queues, pools, replicas, and circuit breakers return to baseline without manual intervention. I verify new traffic succeeds while backlog drains. Recovery time is an explicit metric. A service that survives overload but remains degraded for an hour has not demonstrated resilience.

Q: How do you performance test multi-tenant systems?

I model tenant size distribution, noisy-neighbor traffic, shared and isolated quotas, cache keys, database partitions, and fairness. One heavy tenant should not consume every worker or connection. Results are segmented per tenant class as well as globally. A healthy aggregate can hide starvation of smaller customers, so fairness becomes a measured requirement.

10. Senior Performance Testing Decisions

Q: How do you protect production during a test?

Explicit approval, a bounded target, synthetic identities, traffic labels, rate ceilings, monitoring, abort rules, on-call coordination, and a tested kill switch are prerequisites. Destructive journeys and third parties receive special controls. I start small and increase only when telemetry is healthy. Production fidelity never excuses an uncontrolled blast radius.

Q: How do you performance test serverless functions?

I separate cold starts from warm invocations and model the real concurrency burst rather than sending a smooth average. Metrics include initialization time, execution duration, throttles, concurrency limits, downstream connections, memory configuration, and cost. Unique deployment versions may reset warm capacity, so the initial state is recorded. A fast function can still overwhelm a database when thousands of instances open connections together. I also verify idempotency because platform retries can turn a timeout into duplicate work.

Q: How do you test CDN performance?

I define regions, cache keys, object sizes, compression, TTLs, invalidation, and expected hit ratios before generating traffic. Edge timing is separated into DNS, connection, TLS, time to first byte, and transfer, while origin dashboards show miss impact. Cold-cache, warm-cache, and purge events are independent scenarios. I validate content correctness because a stale edge response can be quick but wrong. Generator location and network quality are documented so geography is not confused with application regression.

Q: How do you test database connection recovery?

I interrupt or constrain database connectivity under bounded traffic and observe pool detection, timeout, retry, circuit-breaker, and reconnection behavior. The test checks whether stale connections are evicted and whether reconnect attempts use jitter rather than arriving simultaneously. Successful recovery includes correct transactions, stable pool size, and drained queues after service returns. Duplicate writes and partially committed operations are explicitly checked. I coordinate the fault with database owners and use a disposable environment unless production approval is unambiguous.

Q: How do you performance test batch jobs?

I measure total completion time, records per second, failure and retry counts, checkpoint progress, resource consumption, and impact on interactive workloads. Input volume and data skew must resemble production because one oversized partition can dominate the critical path. Tests cover restart from a checkpoint and idempotent reprocessing, not just a clean happy path. When a batch shares a database with APIs, I run overlap scenarios at the scheduled hour. The acceptance criterion combines deadline completion with protection of user-facing SLOs.

How Interviewers Grade Your Answers

Interviewers grade the reasoning chain: requirement, model, measurement, validation, diagnosis, and decision. A capable answer distinguishes open from closed traffic, uses illustrative numbers without presenting them as universal, and scopes thresholds by operation. It also checks generator health and asks for server telemetry.

Senior answers challenge ambiguous concurrency targets, anticipate account contention and metric cardinality, define abort and recovery controls, and propose an experiment that could disprove the leading hypothesis. Practice explaining these trade-offs in the QA interview practice area, or tailor examples after reviewing your background in the resume upload dashboard.

Common Mistakes

• Treating VUs, requests per second, and concurrent requests as equivalent.
• Using a global percentile that lets fast endpoints hide a slow checkout.
• Forgetting that fast failures can make latency look better.
• Adding order IDs or user IDs as metric tags and creating unbounded cardinality.
• Sharing one account accidentally and measuring lock contention instead of capacity.
• Saturating the injector and blaming the service.
• Changing data, infrastructure, and traffic between comparison runs.
• Calling a short ramp a soak test or a gradual increase a spike test.
• Reporting client latency without traces, dependency metrics, and resource signals.
• Printing access tokens or embedding credentials in the script.

Compare your reasoning with API scenario-based interview questions and the automation testing interview question bank.

Conclusion

These k6 scenarios reward precise modeling over configuration recall. Start with workload intent, choose an executor that represents it, define scoped objectives, and protect the validity of every run.

Run the examples, change one assumption at a time, and explain the metric changes aloud. That practice turns tool familiarity into the evidence-based judgment interviewers want from a performance tester.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• k6 Scripting Interview Questions for Performance Testers (2026)
• REST Assured Scenario Interview Questions for Senior Testers (2026)
• AI Agent Evaluation Interview Questions for Testers (2026)
• Appium 3 Interview Questions for Senior Testers (2026)
• Cypress Network Interception Interview Questions for Testers (2026)
• Database Testing Scenario Interview Questions for Senior QA (2026)