SAP Basis supports the technical administration and operation of SAP systems which include system monitoring, user and authorization administration, transport management, performance troubleshooting, and system maintenance.
This guide covers SAP Basis interview questions for freshers, intermediate candidates, and experienced professionals. It also includes scenario-based questions on performance issues, system upgrades, SAP HANA, high availability, and security.
The answers explain key concepts, relevant transaction codes, and practical troubleshooting approaches, with references to official SAP documentation where applicable.
Develop practical skills in SAP HANA installation, configuration, monitoring, and database administration.
The following questions will test your basic knowledge of SAP Basis:
SAP Basis is the technical foundation that supports SAP applications by managing system administration, database connectivity, operating system integration and overall system performance. It makes sure that SAP solutions, such as ERP and S/4HANA, operate efficiently and reliably.
The main components of SAP Basis are as follows:
Transport System in SAP can refer to two very different concepts which depend on whether you mean software change management (moving code and configuration between systems) or physical supply chain logistics (moving goods).
A client is a self-contained unit within an SAP system with its own master data, configuration and users. Common clients are
In SAP, ABAP and Java stacks are two different technology environments used to run SAP applications. They are different on the basis of their programming languages, architecture, development tools and the types of applications they support.
| Features | ABAP Stack | Java Stack |
| Full Form | Advanced Business Application Programming | Based on the Java programming language |
| Programming Language | ABAP | Java |
| Main Purpose | Used to develop and run SAP business applications and processes. | Used to develop and run Java-based enterprise applications on SAP platforms. |
| Architecture | Uses the ABAP application server environment. | Uses the SAP Java application server environment. |
| Database Access | Primarily accesses data through the ABAP database interface and Open SQL. | Typically accesses databases using Java database technologies and SAP-supported interfaces. |
| Development Tools | ABAP Development Tools (ADT) in Eclipse and SAP GUI-based tools. | Java Development Tools in Eclipse and SAP-specific Java development tools. |
| Common Applications | SAP ERP, SAP S/4HANA, reports, enhancements and business logic. | SAP Enterprise Portal and certain Java-based SAP applications and services. |
| System Administration | Managed using tools such as SAP GUI, transaction codes and ABAP administration tools. | Managed using Java administration tools and SAP NetWeaver Administrator, which depends on the version. |
| Common Monitoring | Transactions such as SM50, SM66 and ST22. | Java monitoring and administration tools, depending on the SAP system version. |
| Example | Creating an ABAP report to generate a sales report. | Developing a Java-based enterprise application or portal service. |
An SAP Landscape is the arrangement, infrastructure and interconnectivity of SAP servers and software systems used by an organization to manage, develop, test and run their business operations safely.
It has three systems:
A transport request is a container that holds changes made in a system. Each request has a unique ID, such as DEVK900123. There are two main types:
A developer releases the request in SE09 or SE10. A Basis admin then imports it into the target system through STMS.
SM50 shows the work process overview of one application server. SM66 shows the work processes of all application servers in one global view. Basis admins use them to find long-running or stuck processes and to cancel them when needed.
The dispatcher is the traffic manager of an application server. It receives user requests and places them in a queue. It then sends each request to a free work process. It also takes care of communication with the message server.
SAP uses these work process types:
The gateway handles external communication and runs as a separate process.
These questions help a recruiter check if you can work on your own and handle moderate tasks:
Online and background jobs are two types of job processing used in systems such as SAP. The main difference is how they are executed, whether they require user interaction, and how long they can run.
| Basis | Online (Dialog) Jobs | Background Jobs |
| Execution | Run in real time when triggered by a user. | Run automatically at a scheduled time or in the background. |
| User Interaction | Require active user interaction. | Do not require continuous user interaction. |
| Runtime | Generally limited to a maximum of 10 minutes, depending on system configuration. | Can run for hours, depending on system configuration and available resources. |
| Purpose | Used for quick tasks that require immediate results. | Used for long-running, resource-intensive, or repetitive tasks. |
| Examples | Viewing a report, entering data, or executing a transaction. | Processing large amounts of data, generating reports, or performing scheduled batch processing. |
SAP memory management controls how work processes use memory. A work process first uses roll memory. It then uses extended memory. When that runs out, it moves to heap (private) memory. Heap memory ties a work process to one user, so it can hurt performance. Basis admins check memory use in ST02 and tune parameters such as em/initial_size_MB.
SM37 is the job overview transaction. It lists background jobs and their status, such as Scheduled, Released, Ready, Active, Finished and Canceled. You can open the job log, check the spool output and find why a job failed.
A system refresh copies production data into a non-production system, usually Quality. Testers then work with real-looking data. After the copy, Basis admins run post-processing steps:
A profile is a file that holds system parameters. SAP uses three kinds:
You maintain profiles in RZ10 and view or change dynamic parameters in RZ11.
A system copy is the process of copying an existing SAP system to another system. Homogeneous and heterogeneous system copies differ mainly in the operating system and database platform used by the source and target systems.
| Basis | Homogeneous System Copy | Heterogeneous System Copy |
| Definition | The source and target systems use the same operating system and database platform. | The source and target systems differ in their operating system, database platform, or both. |
| Operating System | Remains the same. | May change. |
| Database | Remains the same database type. | May change to a different database type. |
| Complexity | Relatively straightforward. | More complex and requires additional migration steps. |
| Tools / Method | Typically uses standard SAP system copy procedures and database backup/restore methods, as applicable. | May require SAP migration tools and procedures, such as Software Provisioning Manager (SWPM) and database migration options. |
| Example | Copying an SAP system from Linux with SAP HANA to another server using Linux and SAP HANA. | Moving an SAP system from Windows with SQL Server to Linux with SAP HANA. |
SAP Cloud ALM is SAP's cloud-based tool for application lifecycle management. I would first connect the system as a managed service. Then I would turn on health monitoring, job and automation monitoring and integration and exception monitoring. I would set alert thresholds and notifications so the team sees problems early. I would also review the dashboards daily for response time, availability and failed jobs.
SAP Router is a proxy program that controls network access between SAP systems and outside networks. It uses a route permission table (saprouttab) to allow or block connections. Companies use it mainly to give SAP Support a safe connection to their systems. It runs on port 3299 by default.
ST05 is the performance trace. It records SQL statements, enqueue calls, RFC calls and buffer access. The steps are simple. Activate the trace, run the slow action, deactivate the trace and read the result. It helps you find slow database statements.
SAP_ALL and SAP_NEW are authorization-related profiles used in SAP environments, but they serve different purposes.
| Feature | SAP_ALL | SAP_NEW |
| Purpose | Provides broad authorization access across the system, subject to applicable system behavior and restrictions. | Historically used to support authorization adjustments for new releases; its precise behavior depends on the SAP release and authorization concept. |
| Access implications | Grants extensive privileges and creates significant security risk if assigned unnecessarily. | Is not a substitute for reviewing and maintaining appropriate role authorizations. |
| Administration | Should be tightly controlled and assigned only when justified. | Should be handled according to the applicable SAP release documentation and authorization-maintenance procedures. |
Learn SAP NetWeaver architecture, system administration, configuration, and enterprise application management through practical training.
The following questions are for candidates who have 5+ years of SAP Basis experience:
SAP High Availability combines redundancy, clustering, and appropriate recovery mechanisms to reduce service interruptions. Depending on the architecture, it may include clustered central services, enqueue replication, database replication, and redundant application servers or infrastructure.
Recovery time and potential data loss depend on the failure scenario, replication configuration, and recovery design. A highly available architecture reduces risk but does not guarantee zero downtime or zero data loss in every circumstance.
Why this helps: It distinguishes the intended benefits of HA from outcomes that depend on implementation and failure conditions.
SAP HANA is an in-memory database. It keeps data in RAM and stores most data in columns instead of rows. This allows fast reads and strong compression. HANA can run transactions and analytics on the same data. Traditional databases keep data on disk and often need separate systems for reporting. HANA still saves data safely through savepoints and logs.
An upgrade moves a system to a newer release or support level. The usual steps are:
I always run the full process on a sandbox copy first.
SUM stands for Software Update Manager. It is the main tool for upgrades, enhancement package installs, support package stacks and system conversions. It can also move the database to SAP HANA with the Database Migration Option (DMO). SUM works in phases: extraction, checks, preprocessing, execution (downtime) and postprocessing.
SAP Solution Manager is a central tool for monitoring, change control, technical operations and documentation. It also creates EarlyWatch Alert reports. Mainstream maintenance for Solution Manager 7.2 ends on 31 December 2027. SAP recommends SAP Cloud ALM as the successor, but it does not match every Solution Manager feature.
In SAP, SPAM and SAINT are tools used to install and manage software updates. The main difference is that SPAM is used for Support Packages, whereas SAINT is used for installing and upgrading add-on components.
| Basis | SPAM | SAINT |
| Full Form | Support Package Manager | SAP Add-On Installation Tool |
| Purpose | Used to apply Support Packages to an SAP system. | Used to install, upgrade, and manage SAP add-on components. |
| Main Function | Updates existing SAP software components with corrections and improvements. | Adds additional software components or updates existing add-ons. |
| Usage | Used for applying SAP Support Packages and relevant support package stacks. | Used for installing SAP add-ons such as industry solutions or additional applications. |
| Transaction Code | SPAM | SAINT |
| Example | Applying a Support Package to update an existing SAP software component. | Installing an SAP add-on component that provides additional functionality. |
I narrow down the layer first: application, database, operating system or network. Then I use these tools:
Once I find the cause, I fix it and watch the system again.
I always back up the old kernel directory before I start. If the system fails to start, I check these logs first: sapstart.log, dev_disp and dev_w0. Then I look for common causes such as wrong file permissions, a kernel that does not match the database library, or missing files. If I cannot fix it fast, I stop the system, restore the old kernel from my backup and restart. Finally, I confirm the version with disp+work -V and check the instances in SM51.
I start with the system log (SM21) and the ABAP dumps (ST22). I note the time, user, program and error type. Then I read the work process trace files (dev_w*) from the work directory for the same time. I also check job logs in SM37 and application logs in SLG1. If the same error repeats, I look for a pattern, such as a time of day, a user or a recent transport. I fix the cause, not only the symptom and I document the result.
I open STMS and review the import queue and transport logs to identify the failed step and return code. I check the relevant TMS RFC connections, import processes, prerequisites, and any errors reported in the logs.
Before importing dependent requests, I verify their dependencies and the required import sequence rather than relying solely on creation dates. I resolve the underlying issue, follow the applicable recovery procedure, and verify the import results before proceeding with subsequent requests.
Why this helps: It removes the unsupported assumption that transport creation order alone determines the correct import sequence.
Scenario-based questions check how you apply knowledge to real problems. Interviewers want to see your thinking process, so answer step by step.
I would first open ST03N to see where the response time goes: wait time, CPU time, database time or roll time. Next, I would check SM66 and ST06 to find the top CPU consumers. Then I would look for heavy background jobs in SM37 that run during peak hours. If the database is slow, I would check expensive statements in ST04. Fixes may include moving heavy jobs to off-peak hours, tuning SQL, adjusting work processes or adding an application server.
I would start with an SAP Readiness Check and the simplification item check. Then I would run a custom code check. Next, I would choose the approach, such as system conversion, new implementation or selective data transition. For a conversion, I would use SUM with DMO and tune it for low downtime. I would run several dry runs on a copy of production and record timings. After each run, I would validate data with reconciliation reports. I would also prepare a cutover plan and a rollback plan with a tested backup.
First, I would check memory use in SAP HANA Cockpit and the monitoring views, such as M_SERVICE_MEMORY. I would compare it with the global allocation limit. Then I would find the top memory users: large tables, heavy statements and out-of-memory trace files. If one statement is the cause, I would cancel it and work with the developer to fix it. I would also review delta merge activity and unload unused tables if needed. For a long-term fix, I would archive data or increase memory.
I would first confirm the scope of the outage and check the process list with sapcontrol. I would read sapstart.log and dev_disp for errors. I would also check the central services, because a down message server stops the whole system. In RISE with SAP, SAP manages much of the infrastructure, so I would raise a high priority incident right away and share my findings. I would keep business users updated and run a root cause review after recovery.
I would onboard each system and turn on health, job and automation and integration and exception monitoring. I would then set alert thresholds based on real business needs, not default values only. Next, I would set up notifications for critical alerts and send them to the right team. Every week, I would review alert history to find repeated issues and fix their root causes. Over time, this reduces noise and manual checks.
I would start with read-only checks. A Python script can read process status through sapcontrol, check failed jobs and scan logs for known errors. Ansible can run the same checks on many servers and handle operating system tasks. I would schedule the scripts with cron or a pipeline tool and send a summary to email or chat. I would store credentials in a secure vault and keep all scripts in version control. After the checks prove reliable, I would add safe fixes with approval.
I would stop and read the SUM error message and log files. Common causes are low disk space, a full database log, wrong passwords and transport tool errors. I would fix the cause and repeat the failed step, because SUM allows this. If the problem stays, I would check SAP Notes and open a support incident. Before downtime starts, SUM can reset the process. After downtime starts, I would restore the system from the backup I took before the upgrade.
I would check the replication state on both sites with hdbnsutil -sr_state and the replication status script. Then I would confirm which site has the latest data and make sure the old primary is not running, so two primaries cannot exist. I would read the name server trace files and check the network and cluster settings. After a successful takeover on the secondary, I would register the old primary as the new secondary. Finally, I would confirm that replication is active and test the failover plan again.
First, I would contain the risk. I would lock or change the exposed passwords and block suspicious connections. Then I would review RFC destinations in SM59 for stored credentials and check gateway security files. I would read the Security Audit Log (SM20) to see what the attacker did. Next, I would restrict RFC authorizations, apply open SAP security notes and remove unused destinations. For the long term, I would add monitoring and network segmentation and I would document the incident.
I would use AI to group similar incidents, summarize dumps and logs and suggest likely causes. I would give it read-only access first. For fixes, I would automate only low-risk actions, such as restarting a stuck job. Any change to Production would need human approval. I would test every action in a non-production system, log all steps and keep a rollback plan. I would also measure results, so the team knows if the automation really helps.
This blog has covered the most common SAP Basis interview questions and answers for freshers, intermediate candidates and experienced professionals. It also includes scenario-based questions on S/4HANA migration, SAP HANA, SAP Cloud ALM and security. Practice these answers in your own words and try the transactions on a real system if you can. That way, you will answer with confidence in your next SAP Basis interview.
Common topics include SAP architecture, work processes, client administration, transports, user and security administration, background jobs, performance tuning, SAP HANA, upgrades and system monitoring.
Yes. Most interviews for experienced roles include real problems, such as slow performance, failed upgrades and system outages. Interviewers want to see how you think and how you fix issues.
Start with SAP architecture, work processes, clients and transports. Learn the key transaction codes, such as SM50, SM37, ST22 and STMS. Then practice explaining each topic in simple words.
