SAP S/4HANA Technical Interview Questions

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.

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.

First I would verify where ATC is flagging unreleased SAP objects and whether the custom code is still actively used and business-critical. That matters because not every finding needs immediate change, but every one needs a decision. Next I would look for a released alternative such as an API, CDS view, BAdI or other supported pattern, and assess whether the code can be refactored without changing the business outcome. If a replacement is feasible, I would remediate and then retest the impacted processes. If no safe replacement exists, I would document the exception, the technical and business risk, and the regression testing plan, and agree the deviation with the relevant stakeholders. A strong candidate also adds that they would prioritise remediation based on criticality and keep the code base aligned with supported SAP standards to reduce upgrade risk.

First check whether the requirement can be met completely through configuration. In Clean Core thinking, that should be the default choice because it stays within standard SAP, is upgrade-safe, and is easier to support and maintain over time. If configuration fully satisfies the business need, there is no reason to add custom logic. Only when standard configuration cannot deliver the required outcome should you consider a custom enhancement. A strong candidate would also say the decision should be based on business fit, long-term maintainability, and keeping the core as standard as possible, rather than customising early.

Clean Core means keeping the S/4HANA standard core as close to SAP-delivered standard as possible, so upgrades, support packages, and innovation adoption remain predictable and low-risk. The first thing to check is whether the requirement can be met without changing the standard code, for example through configuration, key-user extensibility, released BAdIs, released APIs, CDS/RAP extensions, or a side-by-side extension where that is more suitable. The reason is simple: direct modifications increase effort, testing, and upgrade risk. A strong candidate also explains that Clean Core is not “no extension”, but the disciplined use of the right extension option in the right place.

I would begin with usage analysis and ATC/custom code checks to get a clear picture of what is actually used and what is technically at risk in the S/4HANA conversion. Then I would classify each object as keep, retire, remediate, replace or redesign, so the team can focus effort where it matters most. The next step is to prioritise business-critical findings and address those first, because they have the highest impact on the conversion and on go-live risk. Where code uses risky or obsolete patterns, I would replace them with released APIs or BAdIs rather than apply quick fixes. I would also remove unused code to reduce volume and future maintenance, and then regression test the critical business processes to confirm the cleanup has not changed the expected outcomes. A strong candidate also explains that this should be treated as an iterative workstream, not a one-time check, with functional and technical sign-off before transport.

After go-live, I would treat Clean Core as an ongoing governance discipline, not a one-time design choice. First I would define clear extension guidelines so teams know what is allowed, what must stay standard, and which changes need review. I would then require architecture review for risky customisations, especially anything that could increase upgrade effort or tighten coupling to the core. The next control is automated checking: run ATC checks in the CI or transport process so issues are caught early, not after production impact. I would also maintain extension decision records to show why each deviation exists and whether it is still justified. Finally, I would track exceptions and review custom code before upgrades so unused or replaceable logic can be retired. A strong candidate would add that this needs regular governance cadence, ownership, and clear accountability across delivery and support.

I would first challenge the decision and ask whether configuration, key-user extensibility, released BAdI, released API or RAP/CDS extension can meet the requirement. If no released option exists and implicit enhancement is unavoidable in on-premise, I would require documentation, guard conditions, switch control, minimal code and regression testing.

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.

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.

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.

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.

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.

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.

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.