SAP Architect CDS Views Interview Questions

In SAP Architect rounds, cds views 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.

Master ABAP CDS Views with view entities, annotations, associations, joins, parameters, DCL authorization, analytical views, OData exposure and real S/4HANA performance design.

This page carries 13 reviewed SAP Architect cds views interview questions, each with a complete written answer and no sign-in required. The set breaks down into 3 foundational, 5 mid-level and 5 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 cds views expects.

13 CDS Views questions with answers

easyCDS Views

1. What is a CDS view?

A CDS view is a Core Data Services data model defined in DDL, typically in ADT, and designed as a HANA-first approach to expose reusable business data. The first thing to check is that it is not just a simple database view: it generates a database view and related dictionary artefacts, so it sits higher in the modelling layer. It is used because it provides a structured, semantically rich way to model data close to the database while keeping it consumable by applications. A strong candidate adds that CDS supports annotations for OData, analytics, UI and authorisation, which makes it suitable for modern SAP development and service exposure.
easyCDS Views

2. What is an association in CDS?

An association in CDS is a declarative navigation from one view or entity to another, defined with a statement such as association [card] to X on <condition>. The first thing to check is the relationship and the ON condition, because that defines how the target can be reached. It is useful because the join is lazy: it is only generated when a path expression actually consumes the association, which helps keep the model clean and avoids unnecessary joins. A strong candidate also mentions that associations improve semantic modelling and make reuse easier, since consumers can navigate to related data without hard-coding the join logic in every view.
mediumCDS Views

3. Data appears wrong in a consumption CDS view. Approach?

First check each layer independently in ADT, starting with the underlying basic or interface view before the consumption view, so you can isolate where the wrong data is introduced. Then review joins and associations for cardinality or filter issues, and verify aggregation types plus unit and currency handling, because these often change the displayed result even when the source data is correct. After that, inspect the generated SQL in ST05 to confirm what actually runs at database level and whether the CDS definition matches the runtime result. A strong candidate also compares the preview result with the business expectation and checks whether the issue is caused by a missing join condition, incorrect grouping, or inconsistent master data.
mediumCDS Views

4. How do you expose a CDS view as OData?

First check the system release, because the exposure method depends on whether you are on S/4HANA with RAP available or on an older stack. On S/4HANA, annotate the CDS view with the relevant @ObjectModel.query: true and @UI annotations, then create a service definition and service binding in RAP to publish it as an OData service for Fiori. This is the preferred approach because it keeps the model, service, and UI metadata aligned and reduces manual coding. On older systems, use ODATA_V2_UI to reference the CDS view and expose it through classic OData V2 handling. A strong candidate also mentions checking the service activation and testing the endpoint before handing it to the UI team.
easyCDS Views

5. What is the difference between CDS view entity and classic CDS view?

First check the definition type. A classic CDS view is created with define view and typically needs a generated SQL view name, because the runtime object is based on that separate SQL view. A CDS view entity is created with define view entity and does not require a separate SQL view name, so the model is more direct and streamlined. For that reason, on supported releases, view entities are generally preferred for new development. A strong candidate would add that the choice affects how the object is managed and evolved, and that entities are the modern CDS option when starting fresh, while classic views may still be encountered in existing solutions.
hardCDS Views

6. How do you secure data exposed by CDS Views?

First I would check whether the CDS view exposes data that needs row-level protection and whether an authorization check is already enabled on the view. If access must be restricted, I would create the relevant DCL roles so the view returns only the records a user is allowed to see. I would also review the selected fields and avoid exposing sensitive data unless it is really required. A strong candidate also validates the result with users who have different authorisations, so both the data scope and the field-level exposure are tested from an end-to-end security perspective.
mediumCDS Views

7. A CDS-based Fiori app shows duplicate rows. What would you check?

First I would check the CDS joins and associations to see whether any one-to-many relationship is being consumed as if it were one-to-one. Duplicate rows often come from a join that multiplies the result set, so I would review the cardinality, the key fields in the view, and whether the grouping logic is actually preventing repeated records. I would then compare the underlying data to confirm whether the duplicates are already present there or are introduced by the CDS layer. A strong candidate also checks the consumption view carefully, because exposing associations or joins incorrectly can cause record multiplication in the Fiori app even when the base data is clean.
mediumCDS Views

8. What is DCL?

First check whether the question is about CDS access control, because in SAP DCL usually means Data Control Language. It is the CDS artefact used to apply row-level authorisation to a view by linking the result set to authorisation objects. In practice, DCL is evaluated as filter conditions when the CDS view is queried, so users only see the records they are allowed to access. A strong candidate adds that this is part of securing CDS consumption cleanly at the data model level, rather than handling the restriction later in the application.
mediumCDS Views

9. How would you design CDS views for a Fiori list report?

I would design layered CDS views. A basic/interface view exposes reusable table-level fields, a composite view combines and prepares business data, and a consumption view adds UI annotations, selection fields, semantic annotations and authorization checks. I would avoid putting all logic and annotations into one giant CDS view.
hardCDS Views

10. A CDS view is slow in production. How would you analyze and improve it?

I would first identify the consumer and selection criteria, then analyze generated SQL, execution plan, data volume, joins, associations, filters and aggregation. I would reduce unnecessary fields and associations, add selective filters, correct cardinality, push aggregation to DB where suitable and split a monster view into layered reusable views if required.
hardCDS Views

11. Legacy report on SE11 views performs badly. Migrate to CDS?

Yes, but start by checking the existing SE11 views, the report logic, and where the bottleneck is before changing anything. If the report is doing row-by-row ABAP processing, move the data model to interface CDS views and use composite CDS views for the calculations and joins. This lets you push filtering and aggregation down to the database instead of handling large volumes in ABAP loops, which is usually the main performance gain. A strong candidate also validates the new result set against the old report, retests performance with realistic data, and only retires the SE11 views once no dependent programs or interfaces remain.
hardCDS Views

12. How would you structure a CDS model for a domain?

I would start by identifying the domain entities and then structure the CDS model in three clear layers. The interface layer exposes the raw tables and basic joins, so it stays close to the source and provides a stable foundation. On top of that, the composite layer adds the business logic, richer joins and associations needed to represent the domain consistently. Finally, the consumption layer is designed for the actual use case, such as UI or analytics, with the relevant annotations applied there. A strong point is to apply DCL at the interface level, so access control is enforced centrally and inherited by all consuming views. This keeps the model reusable, easier to govern, and simpler to extend without duplicating checks in every consumer.
hardCDS Views

13. CDS view is slow on HANA. What do you tune?

First check the SQL plan in SM/ST05 to see where HANA is spending time and whether the CDS is causing expensive joins, large intermediate result sets, or late filtering. Then simplify the view by removing unnecessary joins and pushing filters as early as possible, especially into associations so only relevant data is brought in. For complex logic that the optimizer cannot handle efficiently in CDS alone, a table function via AMDP can be a better option. If the view is part of an extraction or reporting pipeline, a persistent aggregate can help avoid repeated heavy calculations. A strong candidate also mentions validating the actual data volume and cardinality assumptions, because tuning only works if the design matches the access pattern.

Related lesson

CDS Basics and Associations

Related topics

Next practice step