SAP ABAP Cloud Developer (C_ABAPD) Practice Exam

Correct: B — RAP. RAP is the standard model for building cloud-ready transactional applications in ABAP Cloud, covering the data model, transactional behavior, and service exposure in one framework.

Why not the others: Dynpro (A), Web Dynpro (C), and BSP (D) are legacy UI technologies that fall outside the released ABAP Cloud language scope, so they are not available in this environment regardless of preference.

Correct: C — CDS view entities. CDS is the foundation for data modeling in ABAP Cloud, supporting calculated fields, associations to other entities, and the annotations that drive downstream behavior.

Why not the others: SE11 tables (A) define storage rather than a semantic model with calculated fields; HANA calculation views (B) sit outside the ABAP Cloud scope; and classic database views (D) are superseded by CDS.

Correct: D — A service definition and a service binding. The service definition declares which entities are exposed; the service binding sets the protocol (OData V2 or V4) and binding type, which is what makes the service consumable.

Why not the others: RFC with a SICF node (A) and a BAPI with SOAP (C) are classic integration approaches; and SEGW (B) is the legacy gateway builder, not part of ABAP Cloud development.

Correct: A — It is outside the released ABAP Cloud language scope. ABAP Cloud enforces a restricted scope that excludes many classic statements, so only released APIs and language elements compile — that restriction is what keeps extensions upgrade-safe.

Why not the others: a licence limitation (B), a missing import (C), and an authorization object (D) all imply the statement would work once configured; it will not, because the compiler rejects it by design.

Correct: B — EML. EML is the dedicated language for reading and modifying RAP business object instances, and it runs the object’s behavior — validations, determinations, and authorization checks — rather than going around it.

Why not the others: direct SQL (A) bypasses the business logic entirely; BDC (C) is legacy UI automation; and Object Services persistence (D) is not the RAP-native approach.

Correct: C — A watchpoint. A watchpoint is tied to a variable rather than a line of code: execution halts whenever that variable’s value changes, which is exactly the requirement here.

Why not the others: an exception breakpoint (A) triggers when a specified exception is raised; a conditional breakpoint (B) stops at a chosen location when a condition holds; and a statement breakpoint (D) stops at a particular statement — all location-bound rather than value-bound.

Correct: A — zcl_a=>b( ). Static methods belong to the class, so they are addressed through the class name with the static component selector => and need no instance.

Why not the others: the class name with -> (B) misuses the object selector on a class; requiring an instance (C) contradicts what static means; and a reference variable with => (D) mixes an instance reference with the static selector.

Correct: C — A key-user extensibility tool or a released extension point. Clean core means extending through interfaces SAP has released and committed to keeping stable, so the extension survives upgrades untouched.

Why not the others: modifying the standard source (A) is the modification anti-pattern clean core exists to eliminate and would break on upgrade; an SE11 append (B) is a classic technique outside the cloud extensibility model; and SPAU adjustment (D) is the ongoing cost of having modified in the first place, not a way to avoid it.

Correct: B — Aggregate in ABAP SQL with SUM and GROUP BY. Code pushdown means moving computation to the database: transfer only the aggregated result rather than hauling raw rows into the application server to loop over them.

Why not the others: a larger initial size (A), package-wise reads (C), and pre-sorting (D) all optimize around the real problem — they still move far more data than necessary into the application layer.

Correct: D — Draft handling with draft table mapping. Draft handling persists in-progress changes to a draft table before final activation, which is what lets a user leave an edit and come back to it.

Why not the others: optimistic locking (A) prevents concurrent-edit conflicts but stores nothing; late numbering (B) defers key assignment until save; and an unmanaged save sequence (C) changes who implements the save, not whether intermediate state survives.