Protocols, Supply-Chain Security, SRE Metrics & Platform Engineering — Interview Questions

How to use this lesson

These often come as quick-fire definitions at the end of a senior round. Give a crisp definition, then one practical detail that shows you've used it (a config, a trade-off, or a pitfall). That's usually what separates a senior answer.

Q1. What are Server-Sent Events?

Short answer: SSE is a standard for one-way, server-to-client streaming over plain HTTP:

• Content-Type: text/event-stream, and the connection stays open;
• the server writes events (id:, event:, data:, followed by a blank line);
• the browser EventSource API reconnects automatically, sending the Last-Event-ID header so the server can resume.

Use it for notifications, live dashboards, progress updates, and LLM token streaming. It's simpler than WebSockets when the client doesn't need to push data over the same channel.

In Spring: SseEmitter (MVC), or Flux<ServerSentEvent<T>> (WebFlux).

Pitfalls:

• proxy buffering and idle timeouts (send heartbeat comments);
• HTTP/1.1's limit of about 6 connections per domain in browsers (HTTP/2 multiplexing removes it).

Q2. What are the advantages of HTTP/3?

Short answer: HTTP/3 runs over QUIC, a transport built on UDP, instead of TCP:

• No transport-level head-of-line blocking: streams are independent at the transport level, so a lost packet only stalls its own stream. (HTTP/2 multiplexes over one TCP connection, where a single loss stalls every stream.)
• Faster connection setup: TLS 1.3 is built in (a 1-RTT handshake, and 0-RTT resumption).
• Connection migration: connections survive network changes (Wi-Fi to mobile) through connection IDs.
• Better performance on lossy, mobile networks.

Trade-offs:

• UDP may be blocked or throttled on some networks (it falls back to HTTP/2);
• more CPU in user space;
• tooling and observability are less mature.

It's usually terminated at the CDN or load balancer; backend Java services often still speak HTTP/1.1 or HTTP/2 internally.

Q3. gRPC versus REST?

Short answer:

• Senior points:
  • gRPC deadlines propagate across calls;
  • Protobuf evolution rules (never reuse field numbers; add optional fields);
  • load balancing needs L7 or client-side balancing (HTTP/2 connections are long-lived);
  • Spring support comes from the Spring gRPC project (or grpc-java directly).
• A common setup: REST at the edge, gRPC internally.

Q4. What are the best practices for container security?

Short answer:

• Build:
  • minimal base images (distroless, Alpine, or JRE-only layers; Java images built with jlink or Buildpacks);
  • multi-stage builds (no build tools in the runtime image);
  • pinned versions or digests;
  • no secrets in images or layers;
  • scan the images (Trivy, Grype) in CI, and fail on critical CVEs;
  • sign images (cosign / Sigstore), and generate SBOMs.
• Run:
  • as non-root (USER in the Dockerfile; runAsNonRoot in Kubernetes);
  • a read-only root filesystem;
  • drop all Linux capabilities; allowPrivilegeEscalation: false;
  • seccomp and AppArmor profiles;
  • resource limits;
  • no privileged containers; no host mounts or host networking.
• Platform:
  • Kubernetes Pod Security Standards (restricted);
  • admission policies (Kyverno or OPA Gatekeeper) that enforce signed images from trusted registries, and the rules above;
  • NetworkPolicies (default deny);
  • least-privilege service accounts (no auto-mounted tokens unless needed);
  • runtime detection (Falco).
• Patch continuously: rebuild images regularly to pick up base-image fixes.

Q5. What is IAM least privilege?

Short answer: Every identity (a user, service or pipeline) gets only the permissions it needs, on only the resources it needs, for only as long as it needs them.

• In practice:
  • specific actions and resource ARNs (s3:GetObject on arn:aws:s3:::invoices-bucket/*), not *;
  • roles instead of long-lived keys (IRSA or EKS Pod Identity, GCP Workload Identity), so pods get temporary credentials;
  • separate roles per service and environment;
  • conditions (source VPC, tags, MFA);
  • permission boundaries and SCPs as guardrails;
  • just-in-time elevated access for humans (break-glass, with approval and audit).
• Keep it least over time: access analysers (AWS IAM Access Analyzer) to find unused permissions, periodic reviews, and policies as code, reviewed in PRs.

Q6. What is a WAF?

Short answer: A Web Application Firewall inspects HTTP(S) traffic at layer 7, and blocks malicious requests before they reach the application:

• managed rule sets (the OWASP Core Rule Set: SQL injection, XSS, path traversal, known exploits);
• rate-based rules;
• IP reputation and geo blocking;
• bot management;
• custom rules (block a vulnerable endpoint while you patch it: virtual patching).

Where it runs: at the CDN or edge (Cloudflare, AWS WAF on CloudFront or ALB, Azure Front Door) or as a reverse proxy (ModSecurity or Coraza).

Senior points:

• start rules in count or log mode to tune out false positives, then block;
• a WAF is defence in depth, not a replacement for secure code;
• monitor what it blocks.

Q7. What is API threat modelling?

Short answer: A structured way to find what can go wrong with an API before building it:

1. Model the system: a data-flow diagram (clients, gateway, services, databases, third parties) and the trust boundaries; list the assets (personal data, payments, tokens).
2. Identify the threats per element and flow, using STRIDE:
   • Spoofing;
   • Tampering;
   • Repudiation;
   • Information disclosure;
   • Denial of service;
   • Elevation of privilege. Plus the OWASP API Top 10 (BOLA, broken authentication, excessive data exposure, missing rate limits, SSRF…).
3. Rate and prioritise them (likelihood × impact).
4. Define the mitigations (authentication, object-level authorisation, validation, rate limits, encryption, audit logs), and track them as backlog items and tests.
5. Revisit it when the design changes.

Do it in design reviews, with lightweight tools (OWASP Threat Dragon, Microsoft Threat Modeling Tool, or a whiteboard).

Q8. What is an SBOM? What is a supply-chain attack?

Short answer:

• An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in your software: direct and transitive dependencies, with versions, licences and hashes. The standard formats are CycloneDX and SPDX.
  • For Java: the cyclonedx-maven-plugin or CycloneDX Gradle plugin, or Syft on images. Spring Boot 3.3+ can generate and expose an SBOM through the Actuator sbom endpoint.
  • Why: you can instantly answer "are we affected?" when a CVE appears (as with Log4Shell); licence compliance; and a growing regulatory requirement (US Executive Order 14028, the EU Cyber Resilience Act).
• A supply-chain attack compromises software through its dependencies or build process rather than attacking you directly. Examples:
  • malicious packages (typosquatting, dependency confusion between internal and public names);
  • compromised maintainers or libraries (the xz-utils backdoor, 2024);
  • compromised build systems (SolarWinds);
  • poisoned CI actions or images.
• Defences:
  • dependency pinning and lockfiles (Gradle dependency locking and dependency verification with checksums and signatures);
  • private repository proxies (Nexus or Artifactory) with namespace rules against dependency confusion;
  • SCA scanning;
  • signed artefacts and provenance (Sigstore, SLSA levels);
  • hardened, ephemeral CI runners with least-privilege tokens;
  • pinned CI actions (by commit SHA);
  • review of new dependencies;
  • SBOMs plus continuous monitoring.

Q9. What are the DORA metrics?

Short answer: Four research-backed metrics (from DevOps Research and Assessment, the Accelerate book) that measure software delivery performance:

1. Deployment frequency: how often you deploy to production.
2. Lead time for changes: from commit to running in production.
3. Change failure rate: the percentage of deployments causing failures that need remediation.
4. Time to restore service (failed deployment recovery time): how quickly you recover from failures.

The first two measure throughput, the last two stability. The research shows elite teams do well on both: speed and stability aren't a trade-off.

Senior points:

• measure them automatically from CI/CD and incident tools;
• use them for team improvement over time, not for comparing or ranking teams (they're easy to game);
• combine them with outcome and developer-experience measures (the SPACE framework).

Q10. SLO versus SLA? What is golden-signals monitoring?

Short answer:

• SLI (indicator): a measured ratio, such as successful requests under 300 ms divided by all requests.
• SLO (objective): the internal target for an SLI over a window (99.9% over 28 days). It defines the error budget, and drives alerting and prioritisation.
• SLA (agreement): an external contractual commitment to customers, with penalties (service credits). It is set looser than the SLO, so you get warned and act before breaching the contract.
• The four golden signals (Google SRE book), for any user-facing service:
  • latency (of successful and failed requests, separately; percentiles, not averages);
  • traffic (demand: requests per second);
  • errors (explicit 5xx, and implicit, such as wrong content or timeouts);
  • saturation (how "full" the service is: CPU, memory, thread or connection pools, queue depth; the leading indicator).
• Related methods: RED (Rate, Errors, Duration) for services; USE (Utilisation, Saturation, Errors) for resources.

Q11. What is a multi-cloud strategy?

Short answer: Using more than one cloud provider, deliberately. The motivations:

• avoiding lock-in and gaining negotiating leverage;
• best-of-breed services (BigQuery on GCP, a main platform on AWS);
• regulatory or data-residency needs;
• acquisitions;
• resilience against a provider-wide outage (rarely worth it).

The patterns:

• different workloads on different clouds (the most common and practical);
• portable workloads (Kubernetes, Terraform, open-source data stores), which can move but usually run in one place;
• active-active across clouds (rare, and very expensive).

The costs:

• lowest-common-denominator architecture (you give up the managed services);
• data egress costs and latency;
• several IAM, network and security models;
• more skills to maintain.

A senior stance: avoid multi-cloud as a default. Get portability where it's cheap (containers, IaC, open protocols, abstraction around the few provider-specific APIs), and use multi-cloud only for clear business drivers.

Q12. What is edge computing? What is CDN invalidation?

Short answer:

• Edge computing runs compute close to users or devices (CDN points of presence, or on-premises gateways), instead of in a central region:
  • CDN edge functions (Cloudflare Workers, Lambda@Edge, CloudFront Functions, Fastly Compute) for personalisation, A/B routing, authentication checks, redirects, header manipulation, and edge caching of API responses;
  • IoT edge gateways (filtering and aggregating sensor data locally; working offline).
  • The benefits: lower latency, less backhaul traffic, resilience. The limits: constrained runtimes, data consistency, harder debugging and deployment.
• CDN invalidation removes or refreshes cached content at the edge before its TTL expires:
  • Purge by path or wildcard (CloudFront invalidations, which can be slow and cost money beyond a quota), or by cache tag or surrogate key (Fastly, Cloudflare Enterprise: purge everything tagged hotel-42 at once).
  • Better: avoid invalidation for static assets with versioned (fingerprinted) file names (app.3f9c2.js) and long Cache-Control: max-age=31536000, immutable; only the HTML (short TTL) references the new versions.
  • For dynamic content: short TTLs, stale-while-revalidate, and event-driven purges on content changes.

Q13. What is predictive scaling?

Short answer: Scaling capacity ahead of demand, based on forecasts, instead of reacting to metrics after the load arrives.

• It uses historical patterns (daily and weekly cycles) and ML forecasts. For example, AWS EC2 Auto Scaling predictive scaling learns from history, and provisions capacity before the expected peaks.
• It's combined with scheduled scaling for known events (sales, campaigns), and reactive scaling (HPA or target tracking) for the unexpected.
• Why it matters for Java: JVM services have startup and warm-up time. Reactive scaling alone adds capacity too late for sudden peaks.
• Also consider: node provisioning lead time (Karpenter or cluster autoscaler), and database capacity (which rarely scales as fast).

Q14. What is platform engineering?

Short answer: Building and running an Internal Developer Platform (IDP): a self-service product for the organisation's engineers that provides "golden paths" (paved roads) for building, deploying and operating services, so stream-aligned teams can ship without becoming infrastructure experts. Typical capabilities:

• service templates (a Spring Boot starter with CI/CD, observability, security and Dockerfile preconfigured);
• self-service environments and infrastructure (IaC modules, Crossplane);
• CI/CD pipelines;
• a developer portal (Backstage: a service catalogue, documentation, scorecards, ownership);
• secrets, observability and policy built in.

Principles:

• treat the platform as a product (users, roadmap, feedback, adoption metrics);
• make golden paths optional but attractive;
• reduce cognitive load;
• measure success by developer experience and DORA improvements.

It evolves the "you build it, you run it" DevOps idea, without making every team reinvent the tooling (Team Topologies calls this the "platform team").

Follow-up questions this topic invites — and their answers

Q: Why is the p99 latency more useful than the average? A: Averages hide the tail. A few very slow requests can affect many users (especially when a page makes many calls), while the average still looks fine.

Q: What is dependency confusion? A: An attacker publishes a public package with the same name as your internal one (and a higher version), and the build tool picks the public one. Prevent it with a repository manager that resolves internal namespaces only from internal repositories.

Q: What is SLSA? A: Supply-chain Levels for Software Artifacts: a framework of increasing guarantees about how artefacts are built (scripted builds, provenance, hardened isolated builders), so consumers can verify where and how software was produced.

Q: What is a golden path? A: A supported, opinionated default way to do a common task (create a service, add a database, deploy), with best practices built in. Teams may deviate, but the path is the easiest option.