This is not a definitions quiz. Each question below is a real production scenario for the Cloud Application Programming Model (CAP). Interviewers use these to see how you diagnose, decide, and fix under pressure.
Draft and Data Scenarios
Scenario 1. Draft activation fails in production but works in development. How do you debug it?
First reproduce with production-like data, since draft failures are usually data-dependent: a validation or determination behaving differently on real data. Check the application logs for the failed determination or authorization error. Then isolate whether it is data, config, or a code path that only triggers at scale.
Scenario 2. A deep insert of an order with 500 line items times out. What do you do?
Break the payload into chunked creates or switch to a dedicated action that processes items in batches. Check for N+1 query patterns in custom handlers firing per item. For bulk scenarios, a batch-oriented action beats one giant deep insert.
Scenario 3. Users report seeing records that belong to another department. Where do you look?
Inspect the @restrict annotations and any custom where conditions in the service — a missing or overly broad restriction is the usual cause. Verify the JWT scopes actually reaching the service via the request context. Then test with a low-privilege user, not an admin.
Authorization bugs are found by testing as the weakest user, not the strongest. Admins see everything, so admin testing proves nothing.
Multi-Tenancy Scenarios
Scenario 4. After onboarding a new tenant to your SaaS app, the tenant sees another tenant's data. What went wrong?
The tenant isolation is broken: likely a missing tenant discriminator in queries or a shared HANA container (schema) instead of per-tenant separation. Verify the subscription callback correctly provisions tenant-specific artifacts. Then audit every query path for tenant filtering, because one leak means the model is wrong.
Scenario 5. A schema migration locks the database during a tenant onboarding wave. How do you handle it?
Run migrations during off-peak windows and make them backward compatible so old code keeps working. For large tenants, use online or phased migration strategies instead of blocking DDL. Coordinate onboarding so migrations do not collide with peak usage.
Scenario 6. One tenant's heavy reporting slows down all other tenants. What is your fix?
Isolate the workload: move heavy analytics to a separate service or read replica, and add query limits and timeouts per request. Review the generated SQL for missing indexes on the hot paths. Noisy-neighbor problems are architecture problems, not tuning problems.
Events and Integration Scenarios
Scenario 7. Your CAP service emits order events, and downstream systems process some orders twice. How do you fix it?
Make consumers idempotent: keyed on the event's business key so replays are harmless. Use the outbox pattern so event emission is transactional with the database write. At-least-once delivery means duplicates are normal — design for them.
Scenario 8. An event storm from a bulk update overwhelms the message broker. What do you change?
Aggregate events at the business level instead of emitting one per row — a single "bulk update completed" event often suffices. Add throttling or batching in the producer. Review whether every change really needs an event, or just the final state.
Scenario 9. A background job fails with expired XSUAA tokens halfway through a long run. How do you handle auth?
Use the client-credentials flow with token refresh for service-to-service jobs instead of a user token. Request tokens with the minimum scopes the job needs. Long jobs should refresh or re-acquire tokens rather than holding one.
Events are a contract, not a log. Version them, keep them idempotent, and never assume the consumer processes each one exactly once.
Performance and Operations Scenarios
Scenario 10. A Fiori list report on your CAP service takes 20 seconds to load. Walk through your diagnosis.
Start with $top/$skip behavior and whether the UI requests only needed fields via $select. Check the generated SQL for missing indexes and full-table scans. Then look at custom handlers for synchronous remote calls per row — that pattern alone explains most slow lists.
Scenario 11. A CSV upload of 100,000 rows times out in the browser. How do you redesign it?
Move to asynchronous processing: accept the file, return a job ID, and process in the background with progress polling. Validate in streaming fashion instead of loading everything into memory. Synchronous uploads do not scale past trivial sizes.
Scenario 12. Production deployment fails at the HANA deployer step. What do you check?
Read the deployer log for the exact failing artifact — usually a CDS table change incompatible with existing data. Verify the target container has the right privileges and space. Test the migration against a production copy in a lower landscape first.
Scenario 13. Audit requires a full change history on financial entities, but the model has none. What is the cleanest approach?
Add temporal (history) tracking via CAP's managed aspect extensions or database-level history tables rather than hand-rolled audit columns. Keep audit writes out of the transactional hot path where possible. Design it once in the model so every entity inherits it.
Scenario 14. Test data keeps polluting the shared development database. How do you fix the workflow?
Give each developer an isolated HDI container or use ephemeral in-memory SQLite for unit tests. Seed data via repeatable CSV or script fixtures, not manual inserts. Shared mutable dev databases are a process failure, not a tooling one.
Senior CAP interviews are won on judgment: knowing which layer owns the fix — model, handler, database, or process — before touching code.
Interviewing soon? Drop your toughest question in the comments.