ERPClimb logoERPClimb

SAP Architect S/4HANA Clean Core Interview Questions

In SAP Architect rounds, s/4hana clean core questions are where configuration knowledge meets day-to-day behaviour — what a setting does, and what breaks in a live system when it is wrong.

Clean Core is SAP's principle that customer extensions should not modify SAP standard objects and should live on stable, released extensibility layers so upgrades and cloud migrations remain low-risk. Consultants must know the extensibility options (KUX, developer extensibility, side-by-side on BTP), released APIs, and how to detect and remediate custom code that violates Clean Core.

This page carries 9 reviewed SAP Architect s/4hana clean core interview questions, each with a complete written answer and no sign-in required. The set breaks down into 2 foundational, 3 mid-level and 4 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

Rehearse these out loud rather than reading them. If you can explain each answer in your own words, including one realistic way it goes wrong on a project, you are covering what a normal SAP Architect round on s/4hana clean core expects.

Read the full guide: SAP S/4HANA Technical Interview Questions

9 S/4HANA Clean Core questions with answers

easyS/4HANA Clean Core

1. What is S/4HANA Clean Core?

S/4HANA Clean Core is the principle of keeping the SAP standard untouched and placing customer-specific logic on stable extensibility layers instead of modifying core objects. First, I would check whether the requirement can be met with standard processes or released extension options, because that reduces upgrade effort and technical risk. The value is that patches, upgrades and cloud migrations stay predictable, with fewer regressions and less remediation work. A strong candidate also mentions that Clean Core is not about avoiding customisation completely, but about using the right extension approach so innovation can happen without destabilising the core system.
easyS/4HANA Clean Core

2. What are the three extensibility options?

First, I would distinguish the three extensibility options by where the change is made and how much control it needs. Key user extensibility is done inside Fiori and is best for small, business-driven adaptations without deep code changes. Developer extensibility is in-stack and typically uses ABAP RAP with released APIs, so it suits more complex enhancements while still staying on the core. Side-by-side extensibility runs on BTP and is the right choice for larger applications or when you want to keep custom logic outside the core. A strong candidate also adds that the choice depends on scope, upgrade safety, and how tightly the extension must integrate with the standard system.
mediumS/4HANA Clean Core

3. Enhancement broke after upgrade. Clean Core lens?

First I would identify exactly where the enhancement sits: if it is on a released object, it is generally a safer dependency; if it is on a private include, it is much more likely to break after an upgrade because that layer is not meant to be stable. That helps me judge whether the issue is a one-off regression or a design risk. The remediation is to replace the customisation with a released BAdI or a CDS extension wherever possible, so the logic follows the Clean Core approach and survives future upgrades better. A strong candidate also says the change should be recorded in the Clean Core registry, so ownership, impact, and technical debt are visible and can be governed properly.
mediumS/4HANA Clean Core

4. What are released APIs?

First check whether SAP has explicitly released the API for customer use, because that release contract is what makes it safe for implementation and upgrades. Released APIs are interfaces such as BAPIs, CDS views, and BAdIs that SAP marks as stable, so their behaviour is expected to remain consistent across releases. The key point is that you should build only on released objects when you need long-term supportability and upgrade safety. A strong candidate also adds that released does not mean every technical detail is fixed, but the public contract is; therefore you should avoid depending on unreleased internals or assumptions outside the documented scope.
mediumS/4HANA Clean Core

5. Customer wants a new field on sales order. Approach?

First check whether the sales order business object already supports a customer extension, because that is the safest and most future-proof option. If a KUX field extension is available, use it so the field becomes part of the standard extensibility concept without changing the core object. This matters because it preserves upgrade stability and reduces regression risk. If the standard object does not support that, use developer extensibility with a released BAdI or CDS extension, depending on the requirement and integration layer. A strong candidate also calls out that direct changes to VBAK should be avoided, since they are not upgrade-safe and can create support issues. They would confirm where the field is needed, how it should be validated, and whether it must appear in UI, persistence, and interfaces.
hardS/4HANA Clean Core

6. Customer has 200 user exits and wants S/4 conversion. Plan?

First I would run ATC with cloudification checks to get a complete inventory of the 200 user exits and understand which ones are still active, which are obsolete, and which are only used for temporary workarounds. Then I would categorise them by business criticality and convert the ones with released replacement enhancements to released BAdIs where possible. For exits that cannot be replaced immediately, I would wrap the logic in service classes and keep the implementation at enhancement points so the custom code is isolated and easier to retire later. Obsolete exits should be deleted rather than carried into the conversion. Before the S/4 conversion, I would add regression tests around the affected processes so the business impact is controlled and the cutover risk is reduced. A strong candidate also highlights sequencing: remediate the highest-risk exits first, validate dependencies, and use the assessment to drive the conversion plan.
hardS/4HANA Clean Core

7. How do you build a Clean Core governance model?

Start by defining, for each system, which extension types are permitted and which are not, so teams know the boundary between standard and custom. Then register every custom object with its extensibility type, which gives you traceability and makes exceptions visible. The next control is automated quality enforcement: run ATC in the pipeline and use severity gates so non-compliant changes do not progress. Review any deviations in a change advisory board to make an explicit business decision on risk and exception handling. A strong candidate also publishes a Clean Core score per team to create transparency, support prioritisation, and drive consistent governance across delivery streams.
hardS/4HANA Clean Core

8. New custom code introduced without Clean Core review. Response?

First, stop the change from progressing and escalate it through the change advisory board so the risk is visible to business and technical stakeholders. Then run ATC to measure the impact, identify any Clean Core violations, and determine whether the code can be adapted rather than released as-is. The next step is to retro-fit the solution to a released extensibility pattern, keeping custom logic outside the core where possible. A strong candidate also adds preventive controls by enforcing pipeline gates so future pull requests cannot merge without ATC clearance. This turns the issue into both a remediation and governance action, reducing repeat violations.
hardS/4HANA Clean Core

9. A customer wants to modify a standard S/4HANA transaction. How do you keep the core clean?

Prefer released public APIs (see the Extensibility Cockpit / released objects list). Use in-app extensibility (Key User tools) for fields, logic (BAdIs), and custom analytical queries. For heavier logic use developer extensibility with released ABAP APIs in an eligible package. For anything not available or requiring extra infrastructure (integration, UI), move it side-by-side on BTP (RAP + SAP Build) and call standard via released OData/SOAP. Do not modify SAP repository objects; document every extension for upgrade impact.

Related lesson

What Clean Core Means and Why

Related topics

Cross-Module Integration and Non-Functional ArchitectureABAP CoreOData GatewayCDS ViewsDebuggingRAP BasicsInternal TablesOpen SQL

Next practice step

Practice with Interview AITake a mock test