SAP Basis interview questions

A Basis interview tests whether you can keep an SAP landscape running and change it without breaking it. It moves through transport management, system copies, performance, patching and upgrades, the vendor-operated cloud, the security boundary and a live incident, and this guide takes each in turn with the questions it produces and what a good answer shows.

What does a Basis interview cover?

The Basis role is the system layer, so the interview is about systems rather than processes. Most interviews touch every block below; the weight shifts with the seat. An in-house team asks more about the landscape it already has and the incidents it remembers; an integrator asks about installations, migrations and upgrades in volume; a managed-service provider asks about monitoring, patching cadence and how you work a queue. Unlike a functional interview, there is rarely a business scenario; there is almost always a broken system to talk through.

Which questions test landscape and transport thinking?

"Describe a landscape you ran and why it had the tiers it had." "A project needs its own development track beside the one that maintains production. How do you set up the routes, and how does a fix made for production reach the project?" "A transport was imported into production before the one it depended on. What happened, what do you do now, and what stops it happening again?" The questions look technical but they are about judgment. A good answer explains why the tiers exist — isolation of change from use — rather than reciting a standard picture, names the retrofit problem when two tracks run in parallel, and treats the transport management system's import queue as a discipline shared with developers and functional consultants rather than a button Basis presses. Someone who has only ever imported what they were told to import tends to describe the tool; someone who has been burned describes the sequencing rules.

What do system copy and refresh questions look for?

"The project wants the quality system refreshed from production before the next test cycle. Walk me through it." This is the question that separates people who have done the work from people who have read about it. The copy itself is procedure; the reasoning is in what has to be preserved before and reset after. A copied production system still believes it is production: its connections to other systems, its background jobs, its printers and its interfaces will happily talk to the real world unless they are cut. Users and authorisations from the target system usually need to survive the copy, the test team's data may need to be reloaded, and the business wants to know exactly which day's data they are now testing against. Good answers have a checklist shape — what to export before, what to disable during, what to reimport and verify after — and include the sentence "and then I tell everyone it is done and what changed". Interviewers also like to ask what you would refuse to copy, and why a refresh in the middle of a test wave is a bad idea.

How are performance and monitoring probed?

"Users say the system is slow. Where do you look first?" The bad answer is a tool name. The good answer is a sequence: is it everyone or one person, one transaction or all of them, since when, and what changed — then the layers in order, from the work processes, their types and the memory they share on the application side to locks, expensive statements and the database beneath, to the network and the front end. Follow-ups test the mechanisms: what a work process does when it waits, why a long-running dialog step is different from a long-running background job, what buffering means and when it hurts, how you tell a database problem from an application problem. Monitoring questions ask how you would know before the users told you: what you alert on, what you look at every morning, and which threshold you learned to lower after an incident.

What about upgrades and the cloud operations shift?

Upgrade questions are about sequence and risk, and so are the smaller ones about kernel patches and support-package stacks that arrive between upgrades. "Plan an upgrade for me: what happens before, during and after?" Good answers cover the pre-checks and the custom-code analysis, the sandbox run that tells you the real duration, the order across the landscape, the downtime negotiation with the business, the rehearsal, and the regression test that Basis does not own but must schedule around. Increasingly the second half of the question is about the vendor-operated model: when the vendor or a hyperscaler runs the infrastructure and the patching, what is left for Basis? The candidates who have thought about it describe the shift from hands-on-the-server to service management — raising and tracking requests, owning the landscape design and the integration and identity layers, validating what the operator did, and keeping the parts the operator does not touch. Being able to say what you would still do, and what you would stop doing, is the whole point of the question.

Where does security end and Basis begin?

In small organisations one person does both; in larger ones the authorisations specialist owns roles and the Basis administrator owns the system. Interviewers ask about the boundary to see whether you understand why it exists: the person who can change the system should not also be the person who decides who may. Expect questions on the system-level controls that are Basis by nature — password and login parameters, the powerful standard users and how they are locked down, the RFC connections between systems and the users they run under, audit logging — and on what you would do if asked to grant yourself a wide role "just for the migration weekend".

How does the live incident walkthrough go?

Somewhere in the interview you will get the scenario: production is down, or nobody can log in, or the interface queue has stopped, or a background job that feeds the warehouse has not run. The interviewer plays the business and drips information as you ask for it. What is scored is the shape of your response. Establish scope before touching anything. Check what changed most recently. Communicate early and in plain words. Restore service before finding root cause, and know the difference. Take notes for the post-incident review. The people who do well narrate aloud — what they are checking and why — and say "I would escalate now" when they reach the edge of what they know. Silence and heroics both score badly, because the job is done in a team under pressure and the narration is the evidence that you can do it there.

What should a Basis candidate rehearse?

• Reconstruct your landscapes. For each one you ran, be able to draw it, say why it was shaped that way, and tell one story of something that went wrong in it.
• Rehearse the refresh and the upgrade as checklists, out loud, including the communication steps. They are the two most common walkthroughs.
• Re-read the mechanisms behind your monitoring habits — what each metric actually measures — so the follow-up question does not catch you repeating a rule without its reason.
• Form a view on the cloud operations shift and what your own role becomes in it; interviewers reward candidates who are moving with it rather than waiting.
• Know the general pattern in the umbrella interview guide — process depth, judgment, scars, translation — and notice that Basis interviews weigh scars most heavily of all.