Learn, Practice, and Improve with SAP C_SAC_2421 Practice Test Questions

Explanation:

In SAP Analytics Cloud (SAC), when creating models to analyze data in a story, you can create:

Standalone models – These are independent models created directly in SAC, usually based on imported data (e.g., CSV, Excel) or acquired from live connections. They are designed for analytical purposes and can feed stories, visualizations, and dashboards.

Analytic models – These models are used specifically for analytics and reporting. They can be created based on live connections to SAP HANA, BW, or other sources, allowing real-time insights in stories.

Why the other options are incorrect:

B. Embedded
– Embedded models are not a type you create; rather, this refers to models that are part of planning scenarios or other artifacts. This is not a standalone model type for analytics.

C. Planning
– Planning models are specifically designed for planning and budgeting, not primarily for data analysis in stories. While they can be visualized, they include planning features (input-ready data, versions, allocations), which is outside the scope of pure analytics.

Reference:
SAP Help: Model Types in SAP Analytics Cloud – Describes Standalone and Analytic models.
If you want, I can also make a quick table showing all SAC model types with their uses—it’s super handy for exam prep. Do you want me to do that?

Explanations:

B. Filtering data on a page
Input controls are interactive elements (like dropdowns, sliders, checkboxes, or radio buttons) that allow users to dynamically filter the data displayed in widgets (charts, tables, etc.) on a page. When a user selects a value in an input control, it filters all linked widgets based on that selection. This is a primary and fundamental use of input controls in SAP Analytics Cloud stories.

Reference:
SAP Help Portal – "Using Input Controls" – Input controls allow viewers to change variables, filters, and properties in a story to explore data.

D. Implementing row-level and column-level security in a table
While data security is primarily defined at the model level (via data access controls and team-based permissions), input controls can be used in a story to enforce a form of dynamic, user-driven security. For example:
A "Region" input control set to a user's region can filter a table to show only rows relevant to that user.
A "Measure" input control can limit which columns (measures) a user is allowed to view. This mimics row-level and column-level security within the context of the story, though it is not a replacement for model-level security.

Reference:
SAP Help Portal – "Securing Data in Stories" – Input controls can be used to restrict data displayed based on user selections, complementing model security.

Why the Other Options are Incorrect:

A. Changing dimensions or measures displayed in a table
This is not a standard function of an input control. Changing dimensions or measures in a table is typically done through the Builder Panel or by using Linked Analysis or Drill Down/Up features. While you could theoretically use an input control to switch between pre-configured views via stories, it is not a direct or typical use case for input controls.

C. Selecting an alternate data source
Input controls filter data within a single model or dataset. They cannot be used to switch the underlying data source of a widget. Changing data sources requires modifying the story's data configuration or using different widgets tied to different models.

Explanations:

A. Large calculation scope
Why it matters: Complex calculations (e.g., large aggregation scopes, advanced formulas, or calculated measures across big datasets) require heavy processing each time the story loads.
Impact: Increases query execution time and delays rendering of charts/tables.
Best practice: Optimize calculations by limiting scope, pre-calculating in the model, or using restricted measures.

B. Many story filters
Why it matters: Each filter adds an extra query condition, which multiplies the workload when multiple filters are applied simultaneously.
Impact: Slows down data retrieval and visualization refresh.
Best practice: Use fewer filters, collapse unused input controls, and apply filters at the model level when possible.

E. Many data sources
Why it matters: Stories pulling data from multiple sources (e.g., different models, live connections, or blended datasets) require multiple queries to be executed and synchronized.
Impact: Longer load times due to parallel queries and blending overhead.
Best practice: Reduce the number of data sources per story, or consolidate data into fewer models.

❌ Incorrect Options

C. Many hyperlinks
Hyperlinks (to external sites or documents) do not affect story performance. They are static references and don’t add query load.

D. Complex formatting
Formatting (fonts, colors, layouts) has minimal impact compared to heavy calculations or multiple filters. While excessive formatting may slightly affect rendering, it is not a primary cause of slow performance.

📖 Reference
SAP Help Portal – Best Practices for Performance Optimization in Story Design (help.sap.com in Bing)
SAP Help Portal – Optimize System Performance with the Analysis Tool

Explanation:

While you can connect to both On-premise and Cloud sources, these are considered the location of the data, not the connection type itself. The connection type defines whether data is moved into SAC or stays in the source.

1. Live Connection (Option A)
A Live Connection means that your data remains in the source system (e.g., SAP HANA, SAP BW, or SAP S/4HANA) and is never replicated into the SAP Analytics Cloud.

How it works: When you open a story, the browser sends a query directly to the source system. Only the metadata (the structure) is stored in SAC.

2. Import Connection (Option D)
An Import Connection (also known as Acquired Data) replicates the data from the source system into the SAP Analytics Cloud.
How it works:
Data is extracted from the source and stored in the SAC internal HANA database. You can schedule these imports to refresh periodically.

Why the other options are incorrect:

B. On-premise:
This refers to the physical location of your data (e.g., a server in your office). You can connect to an on-premise system using either a Live or an Import connection.

C. Cloud:
Similar to on-premise, this refers to where the source system lives (e.g., Google BigQuery or SAP S/4HANA Cloud). You choose a Live or Import connection to access that cloud data.

Explanation:

In SAP Analytics Cloud Value Driver Trees (VDTs), node relationships define how values flow between nodes (parent-child directional links) to simulate impact propagation.

A. Use a dimension hierarchy — This is the primary automatic method. When you select Auto-create from model, the system reads the model's account hierarchy (or other dimension hierarchies) and underlying calculation structure/formulas. It generates nodes and establishes relationships based on how accounts aggregate or depend on each other (e.g., Revenue → Gross Margin → Net Profit). This creates hierarchical parent-child links efficiently for planning models with structured P&L or similar logic.

B. Use a calculated member
— Calculated members (defined in the model) represent formula-based values. When included as nodes, their calculation logic determines dependencies and helps establish or influence relationships to other nodes (e.g., a calculated ratio or derived KPI links back to base drivers).

Why the other options are incorrect:

C. Use a story calculated measure
— These are created at the story level for visualization or ad-hoc analysis. They do not define or influence the structural node relationships inside the Value Driver Tree itself, which relies on model-level elements.

D. Use a model converted measure
— This is not valid terminology or a feature in SAP Analytics Cloud for VDTs. There is no "converted measure" mechanism to determine node links; relationships come from model hierarchies, formulas, or manual linking.

References:
SAP Help Portal: "Set Up Value Driver Trees for Planning" — Nodes and relationships can be auto-generated from the model's account hierarchy and calculation structure; manual linking is also possible via Relationships section.

Explanation:

In SAP Analytics Cloud (SAC), when you have a live data model, you cannot modify the structure of the model itself (like adding calculated dimensions directly in the model). Live models are read-only in terms of structure because they reflect the underlying source system (e.g., SAP HANA, BW).

To display a new dimension that combines Lastname, Firstname, you can create a calculated dimension at the story level. This lets you define a formula like:

[Lastname] + ', ' + [Firstname]
and use it in tables, charts, and visualizations without altering the source model.

Why the other options are incorrect:

A. Create the combined data in the source system – While technically possible, it’s not required and may not be feasible for all live data sources. The SAC story-level solution is simpler.

B. Create a calculated dimension in the data model – For live models, you cannot add calculated dimensions; this option is only valid for imported/standalone models.

D. Group the Firstname and Lastname in the data model – Grouping is for categorizing existing data, not for creating a concatenated display dimension.

Reference:
SAP Help: Calculated Dimensions in Stories – Explains how to create calculated dimensions at the story level for live data models.

Explanation:

Scripting in SAP Analytics Cloud stories is performed using JavaScript. This feature, known as "Advanced Designer Scripting" or "Story Scripting", allows you to create custom interactivity, automate tasks, manipulate widgets, control user access, and dynamically modify stories based on user actions. Scripts are written in a JavaScript-based API provided by SAP.

Key Use Cases:
Dynamically show/hide widgets based on conditions.
Modify filters, dimensions, or measures on the fly.
Create custom navigation between pages or stories.
Implement complex validation logic.

Reference:
SAP Help Portal – "Advanced Designer Scripting" – The scripting environment is based on JavaScript and provides a specific API for interacting with story elements.

Why the Other Options are Incorrect:

A. Python
– Python is not used for scripting within SAC stories. Python can be integrated with SAC for data science (Smart Predict) and data wrangling (in the data preparation area), but not for client-side story interactivity.

B. Wrangling Expression Language
– This language is used within SAC's data wrangling/preparation features (e.g., in the Modeler) for transforming data, not for scripting story behavior.

C. ABAP
– ABAP is SAP's proprietary backend programming language used primarily in on-premise SAP systems (like S/4HANA or BW). It is not used for front-end scripting in SAP Analytics Cloud.