A prospect's IdP will federate to your SaaS. Their security team insists workforce SSO must NOT require your app to ever hold or refresh a long-lived token, and that the IdP alone attests identity per browser session. Which protocol/flow fits, and why?
- A. SAML 2.0 Web Browser SSO, because the SP consumes a signed, short-lived assertion per session and holds no refresh token ✓
- B. OAuth 2.0 Authorization Code with refresh tokens, because it minimizes re-authentication
- C. OIDC Implicit flow, because the id_token is returned directly in the redirect fragment
- D. SCIM 2.0, because provisioning replaces the need for session-time authentication
Correct answer: A. SAML Web Browser SSO delivers a signed, short-lived assertion the SP validates per session without storing refresh tokens, matching the 'IdP attests each session, we hold nothing long-lived' constraint.
Your webhook receiver occasionally processes the same event twice, causing duplicate charges. The sender guarantees at-least-once delivery with a stable `event_id` per event but may retry with a NEW HTTP request. What is the correct fix on your side?
- A. Return HTTP 200 faster so the sender stops retrying
- B. Persist processed `event_id`s and make the handler idempotent by short-circuiting on a seen id within a transaction ✓
- C. Switch the endpoint from POST to PUT so retries are automatically idempotent
- D. Add exponential backoff on your own response so duplicates space out
Correct answer: B. At-least-once delivery means duplicates are inevitable, so the consumer must dedupe on the stable event_id inside a transaction to be idempotent.
A champion asks why your multi-tenant SaaS won't just 'give each customer their own database' for isolation. The most accurate trade-off to state is:
- A. Single-tenant always has lower per-customer cost due to shared hardware
- B. Multi-tenant with row-level tenant scoping keeps marginal cost sub-linear as tenants grow, while single-tenant isolates blast radius but scales cost and ops roughly linearly per tenant ✓
- C. Multi-tenant cannot meet any compliance requirement, so single-tenant is mandatory for SOC 2
- D. Single-tenant eliminates the need for RBAC because tenants are physically separated
Correct answer: B. Multi-tenancy amortizes infrastructure so cost stays sub-linear, whereas single-tenant improves isolation/blast-radius at the price of near-linear per-tenant cost and operational overhead.
A customer requires mutual TLS to your API. During testing their client gets `SSL_ERROR_TLS13_MISSING_CERTIFICATE` while your logs show the handshake completing to `Finished` on your side without ever requesting a client cert. Most likely cause?
- A. The server is not configured to send a CertificateRequest, so the client never presents its cert ✓
- B. The cipher suite negotiated is too weak for mTLS
- C. The client's private key is expired
- D. DNS resolution is returning the wrong SNI host
Correct answer: A. mTLS requires the server to send a CertificateRequest; if it never does, the client isn't prompted for a cert and true mutual authentication doesn't occur.
A prospect wants private connectivity from their AWS VPC to your service in your AWS account, with NO traffic traversing the public internet and NO inbound route from you into their VPC. Which pattern best fits?
- A. VPC peering between the two VPCs
- B. A site-to-site IPsec VPN over the internet
- C. AWS PrivateLink with an interface endpoint in their VPC pointing at your NLB-backed endpoint service ✓
- D. Public NAT gateway with IP allowlisting
Correct answer: C. PrivateLink exposes your service via an endpoint in their VPC over the AWS backbone, unidirectional and private, without peering's bidirectional route exposure or CIDR-overlap issues.
Under CAP, your inventory service must keep serving reads/writes on both sides of a network partition between two regions. A skeptical architect asks what you are necessarily giving up. Correct answer:
- A. Durability — writes may be lost on disk
- B. Consistency — clients on different partitions can read conflicting values until reconciliation ✓
- C. Partition tolerance — the system will simply reject the partition
- D. Latency — responses will always be slower
Correct answer: B. CAP says during a partition you choose A or C; choosing availability on both sides means giving up strong consistency, so replicas may diverge until they reconcile.
Your ELT loads raw JSON into a warehouse, then transforms with SQL. A prospect insists on ETL 'to keep the warehouse clean.' The strongest technical argument for ELT here is:
- A. ETL is always slower than ELT regardless of engine
- B. ELT lets the warehouse's columnar compute scale transforms elastically and preserves raw data for reprocessing when logic changes, decoupling load from transform ✓
- C. ELT avoids the need for any data modeling
- D. ETL cannot handle JSON at all
Correct answer: B. ELT keeps immutable raw data (enabling reprocessing when business logic changes) and pushes transforms into the warehouse's scalable columnar engine, decoupling ingestion from modeling.
An RFP mandates '99.99% uptime with RTO of 15 minutes and RPO of zero.' A prospect asks if your async cross-region replication can meet this. Honest technical answer:
- A. Yes, async replication always achieves RPO zero
- B. No — RPO zero requires synchronous replication (or equivalent); async replication has a replication lag window that can lose in-flight data on failover ✓
- C. Yes, because 99.99% uptime implies RPO zero automatically
- D. RPO and RTO are the same metric so meeting RTO 15m satisfies RPO zero
Correct answer: B. RPO zero means no data loss, which async replication cannot guarantee because its lag window loses unreplicated writes on failover; only synchronous replication (at latency cost) achieves it.
A prospect wants a RAG chatbot over their contracts but is worried about data privacy. Their real concern is that embeddings or prompts might leak to model training. The most technically precise reassurance/design is:
- A. Embeddings are irreversible hashes, so no private data is ever exposed
- B. Use a provider/deployment with contractual no-training-on-inputs plus tenant-isolated vector storage and retrieval-time access controls, since embeddings can leak semantic content and retrieved chunks enter the prompt ✓
- C. RAG never sends customer data to the LLM, only keywords
- D. Fine-tuning on their contracts is safer than RAG for privacy
Correct answer: B. Embeddings can leak semantic content and retrieved chunks are injected into prompts, so privacy depends on no-training guarantees, tenant isolation of the vector store, and retrieval-time authorization.
Given this rate-limit response, a naive client retries immediately in a tight loop:
`HTTP 429\nRetry-After: 30\nX-RateLimit-Remaining: 0`
What is the correct client behavior, and what does the naive loop cause?
- A. Retry immediately is fine because Remaining will reset instantly; no harm
- B. Honor Retry-After (wait 30s) with jitter; the tight loop wastes quota, worsens the limit window, and can trigger a longer ban ✓
- C. Switch to GET requests, which are exempt from rate limits
- D. Send the same request on 100 parallel connections to bypass the per-connection limit
Correct answer: B. A 429 with Retry-After tells the client to wait that long (ideally with jitter); hammering immediately burns quota and often extends the throttle or triggers escalation.