SAP S/4HANA Technical Interview Questions

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.

Identify the highest Clean Core risks by dependency type: direct SAP modifications, implicit source enhancements, unreleased APIs and direct writes to standard tables create more upgrade exposure than custom-code volume alone. Deep explanation: Clean Core risk is primarily about how custom code depends on SAP internals. A direct modification to an SAP-owned object is high risk because upgrades can overwrite or conflict with the changed source. Implicit enhancements are less invasive than modifications but can still depend on private variables and source positions that SAP may change. Unreleased classes, function modules or CDS objects are another major risk. They may work technically but carry no stable compatibility contract for external custom consumption. Direct INSERT, UPDATE or DELETE on standard application tables is especially dangerous because it bypasses validations, change documents, locks and dependent updates. Risk assessment should therefore record dependency type, productive usage, business criticality and change frequency. A heavily used object on released APIs may be safer than a tiny rarely touched enhancement in an internal standard include. Remediation options include standard configuration, released BAdIs, released APIs, RAP or ABAP Cloud extension points, or side-by-side BTP architecture. Where no supported alternative exists, document the exception and regression-test it explicitly during upgrades rather than pretending the risk is absent. Recommended practices: • Classify dependencies, not just objects. • Eliminate direct standard-table writes. • Prefer released contracts. • Document unavoidable exceptions. • Regression-test high-risk areas every upgrade. Common mistakes to challenge: • Measuring Clean Core by number of Z objects. • Treating implicit enhancement as upgrade-safe by definition. • Using unreleased APIs because they are visible in ADT. • Writing standard tables directly. • Leaving unavoidable risks undocumented. Interview angle: Explain which custom-code patterns create the greatest Clean Core risk and why released contracts matter more than object count.

Use released business APIs and CDS contracts instead of direct dependencies on SAP internal tables for new clean-core development, especially for updates where direct writes bypass application integrity. Deep explanation: Direct table access couples custom code to SAP's persistence implementation. For reads, that can break when S/4HANA changes the storage model or moves semantics behind compatibility views or new business entities. For writes, direct INSERT, UPDATE or DELETE is far more dangerous because it bypasses authorization, locks, validation, change documents and dependent updates. Released APIs, released CDS entities, BAdIs and RAP contracts provide a supported compatibility boundary. SAP can change internals while preserving the public contract according to the release model. This does not mean every historic SELECT from an SAP table must be rewritten immediately. Brownfield remediation should consider usage, risk and whether a released alternative exists. New ABAP Cloud development, however, intentionally restricts access to released objects. For business-object updates, always prefer the owning application API. A custom field physically stored on a standard table does not make direct table UPDATE a valid business operation. When no released contract exists, document the gap and choose a governed extension or integration approach instead of silently creating an unsupported dependency. Recommended practices: • Use released APIs for business operations. • Prefer released CDS for new read models. • Never directly update standard application tables. • Prioritize brownfield remediation by risk. • Document gaps where no released contract exists. Common mistakes to challenge: • Writing standard application tables directly. • Assuming a table read is a stable API. • Replacing all legacy reads without prioritizing risk. • Wrapping an unreleased internal FM and calling it clean core. • Ignoring authorization and locks when bypassing the application layer. Interview angle: Explain why released contracts are more upgrade-stable than direct table access and why writes are especially risky.

Choose among key-user, developer and side-by-side extensibility by coupling, lifecycle and complexity, using the least invasive released option that satisfies the business requirement. Deep explanation: S/4HANA extensibility is not one technology. Key-user extensibility is designed for controlled in-app changes such as custom fields, UI adaptations and supported simple logic where the application exposes those capabilities. Developer extensibility covers more complex in-core extensions using ABAP Cloud, released APIs, CDS entities, RAP and released BAdIs. It is appropriate when custom behavior must participate closely in the S/4 transaction or business-object lifecycle. Side-by-side extensibility on SAP BTP fits capabilities that benefit from an independent lifecycle, external technology stack, partner access, event-driven processing, analytics or AI. It should integrate through released APIs or events rather than internal database access. The right choice depends on timing and coupling. A save-time compliance validation may belong in-core, while a supplier-risk dashboard combining external data is a natural side-by-side candidate. Avoid using a more invasive option simply because the team knows it better. Start with the least coupled supported mechanism and escalate only when the requirement needs it. Recommended practices: • Start with the least invasive supported option. • Match extension type to transaction coupling. • Prefer released APIs and BAdIs. • Give side-by-side apps independent ownership and monitoring. • Review extensibility choices during architecture governance. Common mistakes to challenge: • Treating BTP as automatically cleaner regardless of API dependencies. • Using custom ABAP when key-user extensibility is sufficient. • Moving tight save-time logic to remote services without latency analysis. • Consuming unreleased APIs. • Choosing technology before understanding coupling. Interview angle: Compare key-user, developer and side-by-side extensibility and give an example for each.

Sustain Clean Core after go-live with an extension inventory, released-API checks, ATC quality gates, named owners, exception records and periodic review of upgrade-sensitive dependencies. Deep explanation: Clean Core is a continuing governance model, not a one-time conversion activity. Even a clean S/4HANA landscape can drift back toward tightly coupled custom code if new projects introduce direct table dependencies, unreleased APIs or undocumented source-level enhancements. Maintain an extension inventory that records the custom object, business purpose, technical owner, business owner, extension type, consumed SAP APIs, ATC status, risk level and review date. This makes upgrade planning evidence-based instead of rediscovering custom logic during every release cycle. Use ATC and released-object checks as quality gates for new development. Findings should be reviewed according to severity and deployment model. Where a non-released dependency is temporarily unavoidable, create a formal exception with justification, owner, mitigation and review or expiry date rather than silently suppressing the finding. Architecture review should focus on dependency quality. A small enhancement that reads internal SAP persistence can be more upgrade-sensitive than a larger side-by-side application that consumes released APIs and events. Measure governance outcomes such as new high-risk dependencies, overdue exceptions, unused custom objects and remediation progress. The goal is sustainable changeability, not a vanity metric such as zero Z objects. Recommended practices: • Maintain one extension inventory. • Put released-API checks into delivery governance. • Assign business and technical owners. • Time-limit exceptions. • Review high-risk dependencies before each upgrade cycle. Common mistakes to challenge: • Treating Clean Core as a project milestone only. • Tracking custom objects without ownership. • Suppressing ATC findings permanently. • Measuring only custom-object count. • Having no review date for exceptions. Interview angle: Explain how you keep a landscape clean after go-live. A strong answer should include inventory, ATC gates, ownership, exceptions and periodic review.

Classify custom code by actual usage, business criticality and dependency risk so S/4HANA modernization targets the objects that truly need retirement, remediation, replacement, redesign or side-by-side relocation. Deep explanation: A clean-core program should treat custom code as a portfolio, not a flat backlog. The first step is to prove whether an object is still used. Unused programs, obsolete interfaces and dead enhancements should normally be retired rather than remediated. For used objects, separate business value from technical risk. A frequently used report built only on released APIs may be low risk, while a small implicit enhancement reading internal SAP tables can be high risk because it depends on implementation details. A useful classification model is KEEP, REMEDIATE, RETIRE, REPLACE, REDESIGN or SIDE-BY-SIDE. KEEP means the object is still valid and sufficiently upgrade-stable. REMEDIATE addresses specific incompatibilities or unreleased dependencies. REPLACE uses standard S/4 capability. REDESIGN applies when the requirement remains but the existing architecture is no longer suitable. SIDE-BY-SIDE is appropriate when the capability benefits from loose coupling and an independent lifecycle. Combine ATC findings with runtime usage, owner input and business criticality. Do not make decisions from static code counts alone. Every decision should record rationale, owner and target release so modernization remains auditable. Recommended practices: • Prove productive usage first. • Combine business value and technical risk. • Use a small explicit decision taxonomy. • Record owner and rationale. • Prioritize unsupported dependencies and high-change areas. Common mistakes to challenge: • Remediating unused code. • Ranking objects only by ATC finding count. • Treating all Z objects as equally risky. • Replacing stable code without business value. • Recording decisions without owners or rationale. Interview angle: Explain how you classify custom code for S/4HANA rather than simply rewriting everything.

Choose side-by-side BTP extension when the capability benefits from an independent lifecycle and loose coupling, integrating through released APIs or events rather than recreating tight save-time dependencies outside S/4HANA. Deep explanation: Side-by-side extension moves custom capabilities out of the S/4HANA core onto SAP BTP or another approved cloud runtime. It is a strong fit for portals, workflow, analytics, AI enrichment, partner applications and services that can operate through released APIs or business events. The key decision is coupling. A capability that must synchronously block a document save in milliseconds may be better implemented with a released in-core BAdI or ABAP Cloud extension. Moving that check to BTP can add network latency and make core transaction availability depend on an external service. Conversely, processes that can react asynchronously or tolerate independent scaling benefit from side-by-side architecture. Events can decouple producers and consumers, while released OData, SOAP or other APIs provide controlled reads and commands. Side-by-side is not automatically clean core. A BTP app that calls unreleased RFCs or reads internal SAP tables through a custom tunnel still creates upgrade-sensitive dependency. The cleanliness comes from released contracts and clear ownership. Design monitoring, authentication, retry, idempotency and data residency alongside the functional architecture. Recommended practices: • Choose side-by-side for loose coupling and independent lifecycle. • Keep critical save-time logic close to the transaction when needed. • Use released APIs and events. • Design observability and retry from day one. • Assign clear product and integration ownership. Common mistakes to challenge: • Moving tightly coupled save logic out of core unnecessarily. • Calling unreleased backend interfaces from BTP. • Ignoring retry and idempotency. • Creating synchronous dependency on a remote service for every item. • Having no end-to-end monitoring ownership. Interview angle: Explain when side-by-side BTP is preferable to in-core extensibility and why released interfaces are central to clean-core architecture.

Use a consistent Clean Core decision sequence—standard, key-user extensibility, released on-stack extension, released API or side-by-side BTP—before accepting tightly coupled custom code as a governed exception. Deep explanation: Clean Core decisions should begin with the business requirement, not with a preferred technology. The first question is whether standard S/4HANA configuration or process design already solves the need. If not, evaluate the least coupled supported extension option that can still meet the required transaction timing and user experience. Key-user extensibility suits bounded field, UI and logic extensions where the application exposes supported tools. Developer extensibility with ABAP Cloud and released BAdIs or APIs is appropriate when custom ABAP must execute on stack but should remain within a stable release contract. Side-by-side BTP extensions are valuable when the capability needs an independent lifecycle, broader technology stack or asynchronous integration boundary. Timing matters. A validation that must block sales-order save may require an on-stack released BAdI; moving it to a remote BTP application simply to look cleaner can make the process less reliable. If no supported option satisfies the requirement, record the exception with owner, rationale, risk, expected lifetime and review date. Clean Core is a governance discipline, not a ban on every tightly coupled extension. Revisit decisions after upgrades because SAP may release new APIs or extensibility options. Recommended practices: • Start from business timing and semantics. • Prefer the least coupled supported option. • Verify released status. • Record exceptions formally. • Reassess old exceptions as SAP capabilities evolve. Common mistakes to challenge: • Jumping to implicit enhancement first. • Using BTP for logic that must execute synchronously inside the transaction. • Ignoring standard configuration. • Treating technically visible APIs as released contracts. • Accepting exceptions without ownership or review. Interview angle: Explain Clean Core as a decision framework and give an example where on-stack extension is better than side-by-side BTP.

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 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.

Understand Clean Core as an upgrade-stability discipline: keep S/4HANA standard as intact as practical, use released extension contracts, govern exceptions and move decoupled capabilities to side-by-side platforms where appropriate. Deep explanation: Clean Core does not mean "no custom code." It means custom extensions should avoid unnecessary modifications and dependencies on internal SAP implementation so the ERP core can be upgraded and evolved with less regression risk. The preferred approach is to start with standard configuration and fit-to-standard process design, then use supported extensibility in increasing degrees of coupling: key-user extensibility, on-stack developer extensibility with ABAP Cloud and released APIs/BAdIs, or side-by-side BTP extensions when the capability needs an independent lifecycle, technology stack or integration boundary. The architectural test is dependency quality. A custom class that directly reads an internal SAP table can be more upgrade-sensitive than a larger extension built entirely on released contracts. Likewise, moving code to BTP does not make it clean if it scrapes internal tables through unsupported interfaces. Governance matters after go-live. ATC, released API checks, extension inventories, owners and exception reviews help prevent the landscape from drifting back toward high-risk custom code. Clean Core should be applied pragmatically to business value. Not every stable classic extension should be rewritten immediately; prioritize unsupported, heavily coupled and strategically changing areas. Recommended practices: • Start with standard before extension. • Prefer released contracts. • Use ATC and dependency inventories. • Prioritize high-risk/high-change code. • Govern exceptions with owner and expiry/review. Common mistakes to challenge: • Defining Clean Core as zero customization. • Moving unsupported logic to BTP and calling it clean. • Rewriting every legacy object regardless of usage. • Ignoring governance after migration. • Measuring success only by custom-object count. Interview angle: Explain Clean Core in terms of upgrade-stable dependencies, released APIs and extensibility options, not as a blanket ban on custom code.

Use ATC as a portfolio and transport governance tool for S/4HANA and ABAP Cloud readiness, prioritizing unreleased dependencies and incompatibilities by real productive usage and business criticality. Deep explanation: ATC is one of the central controls for modernizing custom ABAP. SAP explicitly recommends using the ABAP Test Cockpit to support adoption of ABAP Cloud and to enforce cloud-ready development. Depending on the check variant, ATC can identify syntax issues, use of unreleased APIs, obsolete objects, S/4HANA incompatibilities, security findings and other quality defects. The important architecture practice is to treat ATC findings as a dependency portfolio, not a flat defect count. Run the governed variant across the custom codebase, then enrich findings with runtime usage and business criticality. Retire unused objects first, group repeated findings by common dependency and fix the architectural root cause rather than suppressing hundreds of individual lines. For ABAP Cloud governance, SAP provides cloud-development ATC variants and recommends integrating blocking checks into transport release according to the organization's policy. Exceptions should be temporary, owned and justified; otherwise the same unsupported dependency remains hidden until the next upgrade. A cloudification program should therefore combine ATC, usage evidence, released-API discovery and regression testing. Passing ATC is necessary for the selected quality gate but is not proof that the business process is functionally correct. Recommended practices: • Use one governed check variant. • Combine ATC with productive usage. • Fix shared root dependencies first. • Make high-priority checks part of transport quality gates. • Time-limit and review exceptions. Common mistakes to challenge: • Treating each ATC finding as equal effort. • Suppressing findings without owner and expiry. • Comparing counts from different ATC variants. • Fixing syntax while retaining the same unreleased architecture. • Running ATC only immediately before go-live. Interview angle: Explain how ATC supports S/4HANA and ABAP Cloud modernization, how you prioritize findings, and why exceptions are governance decisions rather than technical fixes.

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.