Title: API Testing — LearnCoachAssist

Q: What is API testing?
A: API testing verifies that an application's interfaces behave correctly in terms of functionality, contracts, performance, security, and error handling.

Q: Why is API testing valuable?
A: It catches issues below the UI layer, runs faster than end-to-end tests, and provides direct confidence in service behavior.

Q: What is the difference between unit, integration, and API tests?
A: Unit tests isolate small pieces of logic, integration tests verify components working together, and API tests validate behavior at the service boundary.

Q: What is a contract in API testing?
A: A contract describes the expected structure and behavior of requests and responses, including fields, types, and status codes.

Q: Why should you test status codes explicitly?
A: Status codes communicate success, failure, and semantics to clients, so incorrect codes can break integrations even when payloads look reasonable.

Q: What is a happy-path API test?
A: A happy-path test verifies the expected success scenario when valid input is provided under normal conditions.

Q: What is a negative API test?
A: A negative test verifies the API fails correctly when input is invalid, unauthorized, malformed, or otherwise outside the supported path.

Q: Why should API tests validate response shape?
A: A response can return the right status code but still break clients if required fields are missing or typed incorrectly.

Q: What is idempotency?
A: An operation is idempotent if repeating the same request produces the same effect as sending it once.

Q: Why is idempotency important for APIs?
A: Retries happen in real systems, so idempotent endpoints reduce duplicate side effects when clients or networks fail.

Q: What is authentication testing?
A: Authentication testing checks whether the API properly identifies the caller using credentials like tokens, sessions, or API keys.

Q: What is authorization testing?
A: Authorization testing checks whether an authenticated caller is allowed to access a resource or perform an action.

Q: Why test rate limiting?
A: Rate limiting protects systems from abuse and noisy clients, so tests should verify limits are enforced and communicated clearly.

Q: What should a good validation error include?
A: A good validation error tells the client what field failed, why it failed, and how to fix the request.

Q: Why should API tests cover edge cases?
A: Edge cases such as empty payloads, large inputs, missing fields, and duplicate requests are common sources of production bugs.

Q: What is schema validation?
A: Schema validation checks whether a request or response matches an agreed structure such as JSON Schema or OpenAPI definitions.

Q: What is data setup in API testing?
A: Data setup is the creation of predictable preconditions so the test can run reliably and assert meaningful outcomes.

Q: Why are test fixtures useful?
A: Fixtures provide stable known data, making tests easier to read and less brittle.

Q: What is test isolation?
A: Test isolation means one test should not depend on the execution order or side effects of another test.

Q: Why mock external services in API tests?
A: Mocking reduces flakiness, speeds up runs, and makes failure causes clearer when external dependencies are unreliable or expensive.

Q: What is a smoke test for an API?
A: A smoke test is a lightweight check that core endpoints are reachable and functioning after a deployment.

Q: What is regression testing for an API?
A: Regression testing ensures previously working behavior still works after code changes.

Q: Why should APIs return meaningful error messages?
A: Meaningful errors help clients recover quickly and reduce support burden when integrations fail.

Q: What is pagination testing?
A: Pagination testing verifies page size, cursors or offsets, ordering, and boundary behavior when results span multiple pages.

Q: Why should you test sorting and filtering?
A: Sorting and filtering often drive user-facing behavior and analytics, and subtle bugs there can produce wrong results without obvious crashes.

Q: What is a test oracle in API testing?
A: A test oracle is the source of truth used to determine whether the API behaved correctly, such as a schema, database state, or business rule.

Q: What is consumer-driven contract testing?
A: It is a testing approach where consumers define the API expectations they rely on, and providers verify those expectations continuously.

Q: What is a good post-deploy API check?
A: Call a few critical endpoints, verify expected status codes and payload keys, and confirm latency stays within an acceptable range.

Q: What is test data management in API testing?
A: It is the practice of preparing, refreshing, and cleaning up the data conditions tests rely on.

Q: Why should APIs be tested for pagination?
A: Pagination bugs can hide data, duplicate records, or break clients navigating large result sets.

Q: What is a contract drift problem?
A: Contract drift happens when the actual API behavior slowly diverges from its documented or expected interface.

Q: Why test content types and headers?
A: Clients depend on headers like content type, caching, and auth metadata for correct behavior.

Q: What is consumer-driven contract testing?
A: It validates that a provider continues to satisfy the expectations of specific consuming clients.

Q: Why should API tests include malformed payloads?
A: Malformed payloads reveal parser weaknesses, validation gaps, and error-handling inconsistencies.

Q: What is observability in API testing?
A: Observability is the ability to inspect logs, metrics, traces, and responses well enough to debug failures quickly.

Q: Why should API performance assertions be realistic?
A: They should catch regressions without failing simply because environments vary slightly across runs.

Q: What is a flaky API test?
A: A flaky API test passes and fails unpredictably due to timing, shared state, or unstable dependencies.

Q: Why should retries in tests be used carefully?
A: Retries can hide real instability if they are used to mask problems instead of diagnosing them.

Q: What is an end-to-end contract check?
A: It verifies that the full request path, persistence, and downstream effects all match the intended API behavior.

Q: What makes an API test suite valuable long term?
A: It stays fast, readable, isolated, and closely tied to the behaviors clients actually depend on.

Q: What HTTP status code class indicates the client must take additional action, typically supplying credentials?
A: 4xx — client errors (e.g. 401, 403, 404) signal the caller did something wrong and must adjust.

Q: Which HTTP status code class indicates the server understood the request but could not fulfill it?
A: 5xx — server errors (e.g. 500, 502, 503) signal a backend problem the client did not cause.

Q: What does HTTP 401 Unauthorized actually communicate?
A: The request lacks valid authentication credentials; the client should authenticate and retry.

Q: What does HTTP 403 Forbidden actually communicate?
A: The caller is authenticated but is not permitted to access this resource, even with valid credentials.

Q: What is the semantic difference between 401 and 403?
A: 401 means who are you? (no/invalid auth); 403 means I know who you are, but you can't have it (insufficient permission).

Q: When should an API return 404 Not Found vs. 410 Gone?
A: 404 means the resource is not found at this URI (and may exist elsewhere or later); 410 means the resource existed but has been permanently removed.

Q: What is the purpose of HTTP 422 Unprocessable Entity?
A: It indicates the request is syntactically valid (well-formed JSON) but semantically rejected, typically by business-rule validation.

Q: How does 400 Bad Request differ from 422 Unprocessable Entity?
A: 400 usually signals malformed syntax (e.g. invalid JSON, bad header); 422 signals valid syntax that fails business/validation rules.

Q: What does HTTP 429 Too Many Requests communicate?
A: The client has exceeded the rate limit; it should slow down, typically honoring a Retry-After header.

Q: What does HTTP 503 Service Unavailable communicate, and what header often accompanies it?
A: The server is temporarily unable to handle the request (overload, maintenance); it is often paired with a Retry-After header.

Q: What does HTTP 204 No Content indicate?
A: The server successfully processed the request and is intentionally returning an empty body — clients must not expect a payload.

Q: What does HTTP 201 Created indicate, and what should the response include?
A: A new resource was created; the response should include a Location header pointing to the new resource.

Q: Why is the Location header important in a 201 Created response?
A: It gives clients a canonical URI for the newly created resource so they can fetch or reference it without guessing.

Q: What is a safe HTTP method?
A: An HTTP method is safe if it is intended to be read-only and must not cause side effects or modify server state (e.g. GET, HEAD).

Q: Which HTTP methods are defined as idempotent by RFC 7231?
A: GET, HEAD, PUT, DELETE, and (practically) OPTIONS and TRACE — repeated identical calls leave the server in the same state.

Q: What is the difference between PUT and PATCH?
A: PUT replaces the entire resource with the submitted representation; PATCH applies a partial change to specific fields.

Q: Why is testing PATCH endpoints more complex than testing PUT?
A: PATCH accepts partial payloads, varied patch formats (JSON Merge Patch, JSON Patch, etc.), and must preserve unspecified fields — so tests must cover missing, null, and unknown fields carefully.

Q: What is the Idempotency-Key header used for?
A: Clients send a unique key with state-changing requests (especially POST) so the server can deduplicate retries and avoid duplicate side effects.

Q: What is JSON Merge Patch (application/merge-patch+json)?
A: A PATCH format where the request body describes changes: present fields are updated, fields set to null are removed, omitted fields are left untouched.

Q: What is JSON Patch (application/json-patch+json)?
A: A PATCH format defined by RFC 6902 that describes a sequence of operations (add, remove, replace, move, copy, test) against a JSON document.

Q: What is the difference between application/json and application/problem+json?
A: application/json is the general JSON media type; application/problem+json (RFC 7807) is a standardized shape for machine-readable error details.

Q: What fields does an RFC 7807 Problem Details body contain?
A: At least type (URI identifying the problem), title, status, and detail; optionally instance (the specific occurrence URI).

Q: What is the ETag header used for?
A: It carries an opaque token representing a specific resource version, used for caching validation (If-None-Match) and optimistic concurrency control (If-Match).

Q: What is optimistic concurrency control in an API?
A: A pattern where the client sends an If-Match ETag with a write request; the server rejects with 412 Precondition Failed if the resource has changed since the client read it.

Q: What does HTTP 412 Precondition Failed mean?
A: A precondition header (e.g. If-Match, If-Unmodified-Since) evaluated to false, so the server will not perform the request.

Q: What does HTTP 304 Not Modified mean?
A: The resource has not changed since the client's cached version; the client should reuse its local copy. Triggered by If-None-Match / If-Modified-Since.

Q: What is the WWW-Authenticate header?
A: A response header sent with 401 that tells the client which authentication scheme is required (e.g. Bearer, Basic) and any associated parameters.

Q: What is the Retry-After header used for?
A: An HTTP/1.1 response header indicating how long the client should wait before retrying. Used with 429, 503, and sometimes 3xx redirects.

Q: What is a Bearer token in API authentication?
A: An opaque access token sent in the Authorization: Bearer <token> header; possession of the token is sufficient to authenticate the caller.

Q: What is the difference between authentication and authorization headers in practice?
A: Authentication proves identity (e.g. Authorization: Bearer ...); authorization is enforced by the server based on roles/scopes/claims in that identity.

Q: What is OAuth 2.0 in one sentence?
A: An authorization framework where a client obtains a delegated access token from an authorization server, then uses it to call a resource server on behalf of a resource owner.

Q: What is the difference between an access token and a refresh token?
A: An access token is short-lived and used to call the API; a refresh token is long-lived and used only to obtain new access tokens without re-prompting the user.

Q: What is JWT (JSON Web Token)?
A: A compact, signed (and optionally encrypted) token format with three base64url-encoded parts: header, payload (claims), and signature. Self-contained but not automatically revocable.

Q: What are the three parts of a JWT?
A: Header (algorithm and token type), Payload (claims such as sub, exp, iss), and Signature (verifying the token was not tampered with).

Q: Why should JWTs generally be signed, not just encoded?
A: Encoding is reversible; a signature lets the receiver verify the token was issued by a trusted party and its claims were not altered in transit.

Q: What claim in a JWT indicates when the token expires?
A: The exp (expiration time) claim — a numeric date representing seconds since the Unix epoch.

Q: What claim identifies the principal (user) a JWT represents?
A: The sub (subject) claim, which is a stable identifier for the user or entity the token is about.

Q: What is API key authentication and what is its main weakness?
A: API key auth sends a shared secret (header or query param) with each request. Its main weakness is that the key is a single long-lived credential: anyone with it can impersonate the caller.

Q: What is mTLS (mutual TLS)?
A: An authentication scheme where both client and server present X.509 certificates during the TLS handshake, proving identity cryptographically at the transport layer.

Q: What is the difference between Basic and Digest authentication?
A: Basic sends base64(username:password) on every request (trivially decoded); Digest uses a challenge/response hash so the password is never sent on the wire.

Q: What is CSRF and why does it matter for cookie-authenticated APIs?
A: Cross-Site Request Forgery tricks a browser into sending a request with the victim's cookies attached. APIs that rely on session cookies must defend against it (CSRF tokens, SameSite cookies, custom headers).

Q: Why should API tests verify CORS headers?
A: Browser-based clients are blocked by CORS unless the server advertises which origins, methods, and headers it allows; tests should confirm the Access-Control-Allow-* headers expose the intended policy.

Q: What are the key CORS response headers?
A: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials, and Access-Control-Max-Age.

Q: Why is Access-Control-Allow-Origin: * incompatible with credentialed requests?
A: With credentials, browsers require a specific origin (not *) to prevent leaking the user's session to arbitrary sites.

Q: What is the content negotiation mechanism in HTTP?
A: A client signals desired representation via Accept, Accept-Language, or Accept-Encoding headers, and the server picks the best match from the Content-Type it returns.

Q: What does the Vary response header signal?
A: It tells caches which request headers (e.g. Accept, Accept-Encoding, Origin) the response depends on, so caches don't serve wrong variants to later clients.

Q: What is request validation at the API layer?
A: The process of checking that an incoming request meets the contract: required fields present, types correct, values within allowed ranges, and business rules satisfied, before any business logic runs.

Q: What is a common schema for validating JSON request bodies?
A: JSON Schema — a declarative specification (draft 2020-12 being current) describing required fields, types, formats, and constraints that can be checked automatically.

Q: What is OpenAPI (formerly Swagger)?
A: A machine-readable specification (YAML/JSON) describing an API's endpoints, parameters, request/response schemas, auth, and errors — enabling docs, codegen, and contract testing.

Q: What is the difference between OpenAPI and JSON Schema?
A: OpenAPI describes the API as a whole (paths, operations, parameters, security); JSON Schema describes the shape of a single JSON document. OpenAPI reuses JSON Schema for request/response bodies.

Q: What is a postman collection?
A: An exported JSON file containing a group of saved API requests, variables, tests, and environments — portable across Postman, Newman, and many other tools.

Q: What is Newman?
A: The command-line runner for Postman collections, useful in CI to execute API test suites headlessly and produce reports.

Q: What is curl and why is it useful in API testing?
A: A command-line tool for transferring data with URLs. It is invaluable for quick API probing, reproducing bugs, and scripting HTTP calls without a full test framework.

Q: What is the difference between curl -X POST and curl -d '...'?
A: -X POST forces the method to POST; -d sends body data and implicitly switches to POST (but does not automatically set Content-Type). Prefer -d with -H 'Content-Type: ...'.

Q: What is HTTPie?
A: A user-friendly command-line HTTP client that emphasizes readable syntax, colorized output, and built-in JSON support — often used as a more humane alternative to curl.

Q: What is REST?
A: An architectural style for networked APIs centered on resources identified by URIs, uniform interfaces, stateless requests, and representations (often JSON) transferred over HTTP.

Q: What are the core REST constraints (per Fielding)?
A: Client–server, stateless, cacheable, uniform interface, layered system, and (optionally) code-on-demand.

Q: What is the difference between REST and RPC in API design?
A: REST models nouns (resources) and uses HTTP verbs uniformly; RPC models verbs (actions/procedures) and often uses POST + a custom endpoint name, with method semantics defined by the API.

Q: What is GraphQL?
A: A query language and runtime for APIs where clients send a single POST to one endpoint with a query describing exactly which fields they need; the server returns a JSON response matching that shape.

Q: What is a key testing concern unique to GraphQL APIs?
A: You must test for query complexity, depth limiting, and field-level authorization — because a single endpoint can return many resources, a malicious or naive query can otherwise exfiltrate data or DoS the server.

Q: What is a query depth attack in GraphQL?
A: A query that nests fields many layers deep (e.g. user → friends → friends → ...) causing exponential work on the server; defenses include depth limits and query cost analysis.

Q: What is a N+1 query problem in API backends?
A: When a single API response triggers one DB query per item (often due to a loop fetching related rows), causing performance to degrade linearly with result size. Fix with eager loading / batched fetchers.

Q: What is OWASP API Security Top 10?
A: A community-maintained list of the most critical API security risks, currently including Broken Object Level Authorization (BOLA), Broken Authentication, Excessive Data Exposure, Lack of Resources & Rate Limiting, and others.

Q: What is Broken Object Level Authorization (BOLA)?
A: An API vulnerability where the server fails to verify that the authenticated user is allowed to access the specific object ID they are requesting — e.g. GET /orders/123 returns any user's order.

Q: What is Broken Function Level Authorization?
A: When an API fails to restrict access to privileged endpoints (e.g. an /admin route) based on the caller's role.

Q: What is Excessive Data Exposure?
A: An API returns more fields than the client needs (e.g. a user object with password_hash, ssn) because the serializer is overly broad, rather than being tailored to the consumer.

Q: What is Mass Assignment vulnerability?
A: When a backend binds client-supplied fields directly to a model without filtering, allowing attackers to set fields they shouldn't control (e.g. is_admin=true in a profile-update body).

Q: What is SSRF (Server-Side Request Forgery) in API context?
A: An attacker tricks the server into making an HTTP request to an unintended destination (internal service, cloud metadata URL like 169.254.169.254) via a parameter the server fetches.

Q: What is the SSRF risk with cloud metadata endpoints?
A: Cloud providers expose instance metadata at well-known IPs (e.g. 169.254.169.254 for AWS). If an API fetches a user-supplied URL without restrictions, attackers can read IAM credentials from the metadata service.

Q: What is SQL injection in API testing?
A: An attack where untrusted input is concatenated into a SQL query, allowing the attacker to alter the query's logic. Test by sending payloads like ' OR 1=1-- in input fields and verifying the API does not behave differently.

Q: What is parameter pollution testing?
A: Sending duplicate parameters (e.g. ?id=1&id=2) or unexpected combinations to see if the server picks a value inconsistently, leaks info, or behaves unpredictably.

Q: What is fuzz testing for APIs?
A: Sending random, malformed, or unexpected inputs (long strings, binary data, unicode edge cases, negative numbers) to discover crashes, validation gaps, and unhandled exceptions.

Q: What is boundary value testing for APIs?
A: Testing at the edges of valid input ranges (min, min-1, max, max+1, empty, one) where off-by-one errors and validation oversights are most likely.

Q: What is equivalence partitioning in API test design?
A: Grouping inputs into classes that should be treated the same way (e.g. valid emails, invalid emails, empty strings) and picking representative values from each class to keep the test set small but thorough.

Q: What is contract testing in microservice systems?
A: Verifying that a provider service's API matches the expectations of its consumers (request/response shape, status codes, headers) — typically via a tool like Pact running as part of both sides' CI.

Q: What is the Pact framework?
A: A consumer-driven contract testing tool where consumers record their expectations (a "pact") and providers verify against it, enabling safe independent deployments of microservices.

Q: What is a provider vs. a consumer in Pact?
A: The consumer is the service that calls another API (it defines the contract); the provider is the service that exposes the API (it must satisfy all consumer pacts).

Q: What is schema-first API development?
A: Writing the OpenAPI/AsyncAPI spec first, then generating server stubs, client SDKs, and tests from it — keeping implementation, docs, and contracts in sync.

Q: What is a mock server in API testing?
A: A lightweight server that simulates a real API's responses, allowing client teams to develop and test against a stable, controllable fake without waiting for the real backend.

Q: What is the difference between a mock and a stub?
A: A stub returns canned responses to specific calls; a mock also verifies expectations (e.g. "this method was called once with these args"). In API testing, the terms are often used interchangeably.

Q: What is WireMock?
A: A popular open-source library for stubbing and mocking HTTP services, widely used to simulate downstream APIs in tests with recorded/playback scenarios.

Q: What is a virtualization tool for APIs (e.g. Hoverfly, Mountebank)?
A: A tool that records real HTTP traffic and replays it as a virtual service, letting tests run against a captured likeness of upstream APIs without hitting the real dependency.

Q: What is service virtualization?
A: Simulating the behavior of components that are unavailable, slow, or shared (databases, third-party APIs, mainframes) so dependent services can be tested in isolation.

Q: What is Postman Mock Server?
A: A feature of Postman that serves a mock implementation of an API based on a saved collection/example responses, useful for parallelizing client and server work.

Q: What is test coverage for an API?
A: A measure of how much of the API surface (endpoints, status codes, parameter combinations, response branches) is exercised by automated tests — usually expressed as a percentage of lines, branches, or operations.

Q: What is code coverage vs. API coverage?
A: Code coverage measures executed lines/branches in the implementation; API coverage measures which endpoints, status codes, and parameter combinations have been tested at the HTTP boundary.

Q: What is the Arrange-Act-Assert pattern in API tests?
A: A common test structure: Arrange set up preconditions and request data; Act send the HTTP call; Assert verify the response status, body, headers, and side effects.

Q: What is the Given-When-Then (Gherkin) style?
A: A BDD-flavored test structure: Given a precondition, When an action occurs, Then an outcome is expected — useful for readable, behavior-focused API tests.

Q: What is JSONPath?
A: A query language for selecting nodes from a JSON document (e.g. $.user.addresses[0].city), commonly used in API tests to assert on deeply nested fields.

Q: What is JSONassert or json-schema-validator?
A: Libraries that assert an API response matches an expected JSON shape — either as a full schema (JSON Schema) or as a strict subset of expected fields/values.

Q: What is the role of an API client library in testing?
A: A typed wrapper around HTTP calls (e.g. generated from OpenAPI) that makes tests more readable, IDE-friendly, and refactor-safe compared to raw HTTP calls with hand-built payloads.

Q: What is a test pyramid in API testing?
A: A model: many unit tests at the bottom, a moderate number of integration/API tests in the middle, and a small number of end-to-end tests at the top — balancing speed, cost, and confidence.

Q: What is the test trophy (Kent C. Dodds) variation?
A: Emphasizes static typing and integration tests over pure unit tests, putting more weight on API/integration tests because they catch more real-world bugs with less maintenance.

Q: What is shift-left testing for APIs?
A: The practice of running API tests as early as possible — in CI on every commit, in pre-commit hooks, or in local dev — to catch defects long before production.

Q: What is a CI pipeline check for APIs?
A: An automated stage in continuous integration that runs the API test suite on every commit/PR, gates merges on green, and reports results (often in GitHub Actions, GitLab CI, Jenkins, etc.).

Q: What is the difference between integration and end-to-end (E2E) API tests?
A: Integration tests call the API and may exercise the database or one downstream service; E2E tests exercise the full stack including the UI, real third-party APIs, and live infrastructure.

Q: What is a sandbox environment for API testing?
A: A dedicated, isolated environment that mirrors production closely enough to safely run integration and E2E tests without affecting real users or data.

Q: What is data masking in API tests?
A: Replacing sensitive fields (PII, payment data) with realistic-looking but fake values in test environments, so tests stay useful without exposing real customer data.

Q: What is test data seeding?
A: Loading a known dataset (via SQL, factories, or API calls) into the test environment before tests run, so assertions are made against predictable values.

Q: What is a factory in test data creation?
A: A helper that generates valid, randomized test objects (e.g. a UserFactory building a user with a random name and email) so each test gets fresh, isolated data.

Q: What is the difference between unit and component API tests?
A: Unit tests a single function/class in isolation; component tests drive a single service end-to-end through its real HTTP surface (including routing, validation, and persistence) but stub external services.

Q: What is a health check endpoint?
A: A lightweight endpoint (often GET /health or /healthz) that returns the service's liveness/readiness status, used by load balancers, orchestrators, and post-deploy tests.

Q: What is the difference between liveness and readiness probes?
A: Liveness asks "is the process alive?" — restart if not. Readiness asks "should I receive traffic right now?" — remove from the load balancer if not (e.g. warming up, dependencies down).

Q: What is graceful shutdown in API servers?
A: Draining in-flight requests, refusing new ones, finishing DB transactions, and releasing resources cleanly when a SIGTERM is received — important for zero-downtime deploys.

Q: What is blue-green deployment for APIs?
A: A release strategy where a new version (green) is deployed alongside the old (blue); traffic is switched atomically, and the old version is kept warm for instant rollback.

Q: What is canary deployment?
A: Rolling out a new API version to a small subset of traffic first, monitoring for regressions, and gradually increasing the share — limiting blast radius if something goes wrong.

Q: What is feature flagging in API testing?
A: Gating new API behavior behind a flag so tests can exercise both old and new paths in production, and rollouts/rollbacks happen via configuration without redeploy.

Q: What is load testing?
A: Measuring how an API behaves under expected and peak load (concurrent users, requests/sec) to confirm latency, throughput, and error rates stay within targets.

Q: What is stress testing?
A: Pushing an API beyond normal capacity to find its breaking point, surface resource leaks, and observe how it fails (gracefully or catastrophically).

Q: What is soak testing?
A: Running an API at moderate load for an extended period (hours/days) to detect slow leaks: memory growth, file handle exhaustion, connection pool saturation, and slow performance drift.

Q: What is spike testing?
A: Subjecting an API to sudden, short bursts of high traffic to verify it recovers gracefully and doesn't permanently break when the spike subsides.

Q: What is breakpoint testing?
A: Incrementally increasing load until the system fails, used to determine the actual maximum capacity rather than a theoretical one.

Q: What is a common load testing tool?
A: k6, JMeter, Gatling, Locust, and wrk are all popular — they generate virtual users against an API and report latency/throughput metrics.

Q: What does p50, p95, and p99 latency mean?
A: They are percentiles: p50 is the median, p95 is the worst-case for 95% of requests, p99 is the worst-case for 99%. p95/p99 matter more than averages for tail-latency SLOs.

Q: What is an SLO (Service Level Objective) for an API?
A: A quantified reliability target, e.g. "99.9% of requests succeed with p99 latency under 300ms over a 30-day window" — used to gate releases and trigger alerts.

Q: What is the difference between SLO and SLA?
A: An SLO is an internal target for the team; an SLA is a contractual commitment to customers that often carries financial consequences if missed.

Q: What is an error budget?
A: The allowed amount of failure derived from an SLO (e.g. 0.1% downtime = 43 minutes/month). Once exhausted, the team prioritizes reliability over new features.

Q: What is distributed tracing in API testing?
A: A technique that follows a single request across multiple services, correlating spans (timed operations) by a shared trace ID to debug latency and failures end-to-end.

Q: What is a span in tracing?
A: A single unit of work within a trace, with a name, start/end time, attributes (e.g. http.status_code), and a parent span ID — typically following the OpenTelemetry data model.

Q: What is OpenTelemetry (OTel)?
A: An open standard and SDK set for instrumenting applications to emit traces, metrics, and logs in a vendor-neutral format, often exported via OTLP to a backend like Jaeger, Tempo, or Honeycomb.