Design a Secure Ingestion Pipeline

Two forces pull in opposite directions here, and naming both in the first two minutes is what sets up a strong round. The files are huge and the networks are awful, so the transfer has to be resumable and it has to avoid dragging gigabytes through your own servers. That half of the problem has a well-known shape: hand the client a pre-signed URL and let it upload straight to object storage. Most candidates get there fast. That is not where the round is won.

Okta grades the other half, and it is easy to under-serve. This is an identity and security company. So "secure ingestion" is not a decoration on the prompt. The interviewer is testing whether you treat the network edge as hostile. Is every request authenticated and authorized? Can a leaked URL hurt you? Can one customer trick your service into acting on another customer's data? A clean storage design that ignores the edge does not pass, no matter how elegant the multipart flow is. Treat the edge as hostile.

The Okta angle

This round has a signature failure mode, and you should know it before you draw a single box. A strong engineer can set up the data model, nail the non-functional requirements, and reach the textbook answer, pre-signed S3 URLs plus multipart for resumability, and still be rejected. The reason is that they stayed at the storage layer while the interviewer kept pushing on the edge. When an Okta interviewer asks "how do you secure the URL?" and keeps asking after you have said TTL and size limits, that is not a hint that your answer is wrong. It is a breadcrumb telling you the round has moved to API gateway policy, WAF filtering, JWT sub-claim validation, and blast-radius reduction. Follow the breadcrumb. Okta's own posture, "Always secure. Always on.", is the rubric: they want an engineer who reaches for Zero-Trust by reflex, not one who has to be dragged there.