Saviynt Certified IGA Professional Exam (L100) SAVIGA-C01 Exam Questions

Page: 1 / 14
Total 60 questions
Question 1

Which of the following Jobs is responsible for configuring a dashboard in a Campaign?



Answer : B

The Job responsible for configuring a dashboard (among other configurations) in a Saviynt Campaign is B. Create or Schedule Attestation Job. Here's a detailed explanation:

Saviynt's Campaigns: Campaigns in Saviynt are used for access certification, allowing reviewers (Certifiers) to review and approve or revoke user access.

Create or Schedule Attestation Job: This job is the core mechanism for creating and configuring various aspects of a campaign, including:

Campaign Scope: Defining which users, entitlements, or resources are included in the campaign.

Certifier Selection: Specifying who will be the reviewers for the campaign.

Scheduling: Setting the start and end dates for the campaign.

Notifications: Configuring email notifications for Certifiers and other stakeholders.

Dashboard Configuration: Defining the information and layout displayed on the campaign dashboard for Certifiers. This includes selecting which data points, charts, and filters are visible.

Why Other Options Are Incorrect:

A . Campaign Export Job: This job is used to export campaign data, not to configure the campaign itself.

C . Campaign Import Job: This job is used to import data into a campaign, typically from an external source.

D . Upgrade Job: This job is related to upgrading the Saviynt platform, not to campaign configuration.

In summary: The 'Create or Schedule Attestation Job' is the central job for setting up and configuring all aspects of a Saviynt campaign, including the dashboard that provides Certifiers with a summarized view of the certification data.


Question 2

Access privileges for any specific Analytical Control can be assigned using SAV Roles. Which of the following tasks can be performed, by default, by users belonging to an SAV Role?



Answer : B

When access privileges for a specific Analytical Control are assigned using SAV Roles in Saviynt, users belonging to that role can, by default, perform the following tasks: B. View Control, Run Control, and View Analytic History of the Control. Here's a breakdown:

Saviynt's Role-Based Access Control (RBAC): Saviynt uses RBAC to manage access to various features and functionalities, including Analytical Controls.

Analytical Controls: These are pre-defined or custom-built analytics reports or dashboards.

Default Permissions: When a user is granted access to an Analytical Control via an SAV Role, they typically receive a set of default permissions:

View Control: Allows the user to view the configuration and definition of the Analytical Control (e.g., the query, parameters, visualization).

Run Control: Allows the user to execute the Analytical Control and generate results.

View Analytic History: Allows the user to see the history of previous executions of the Analytical Control, including the results and timestamps.

Why These Permissions Are Important:

Transparency: Users can understand how the analytics are defined and generated.

Usability: Users can run the analytics and obtain insights.

Auditing: Users can review past results for trend analysis or investigation.

Other Options:

A . Only view the configurations of the Control: This is too restrictive; users need to be able to run the control to get value from it.

C . Only view the Analytic History of the Control: This is also too limited; users should be able to run the control and view its configuration as well.

D . View Control and Run Control: While closer, it's missing the 'View Analytic History' permission, which is important for auditing and analysis.

MISCELLANEOUS


Question 3

In the process of setting up Single Sign-On using SAML 2.0, the "SP Entity ID" acts as a unique identifier for the Saviynt SP. If "SP Entity ID" is set to the value of SaviyntSP, which of the following will be the correct Single Sign-On URL to log in to EIC?



Answer : C

In Saviynt's SAML 2.0 based Single Sign-On (SSO) configuration, the 'SP Entity ID' uniquely identifies Saviynt as the Service Provider (SP) to the Identity Provider (IdP). The correct SSO URL structure incorporates this 'SP Entity ID' within a specific path.

Saviynt's URL Structure: Saviynt's SSO URLs follow a pattern to ensure proper routing and authentication. The /ECM/saml/SSO/alias/ portion is crucial for directing SAML-based login attempts.

Why the other options are incorrect:

A . https://myorg.saviyntcloud.com/ECM/saml/SSO/SaviyntSP: This URL is missing the crucial 'alias' segment in the path, making it invalid for SAML SSO.

B . https://myorg.saviyntcloud.com/SaviyntSP: This URL doesn't include the necessary components for SAML-based authentication within Saviynt.

Saviynt IGA Reference:

Saviynt Documentation: Saviynt's official documentation on configuring SAML SSO provides details on the correct URL structure and the significance of the 'SP Entity ID.'

Saviynt Support: Saviynt's support resources and knowledge base articles often address issues related to SSO configuration, reinforcing the correct URL format


Question 4

What is the maximum file attachment limit for a request?



Answer : C

The maximum file attachment limit for a request in Saviynt is typically 10. Here's an explanation:

Saviynt's Access Request System (ARS): The ARS allows users to attach files to access requests to provide supporting documentation or justification.

Attachment Limits: To prevent excessive storage usage and potential performance issues, Saviynt imposes limits on the number and size of attachments allowed per request.

Default Limit: The default maximum number of attachments allowed per request in Saviynt is generally 10.

Configuration: While 10 is the common default, it's worth noting that this limit might be configurable within the ARS settings in some Saviynt deployments. However, significantly increasing this limit could impact performance.

File Size Limit: In addition to the number of attachments, there's also usually a limit on the individual file size and the total size of all attachments combined. This is also generally configurable. These file size limits are important for maintain system stability and performance.

Error Handling: If a user attempts to exceed the attachment limit, Saviynt will typically display an error message, preventing them from submitting the request until the number of attachments is reduced.


Question 5

Which of the following Rules should always be used in conjunction with the Organization object?



Answer : B

The type of Rule that should always be used in conjunction with the Organization object in Saviynt is the B. User Update Rule. Here's the explanation:

Saviynt's Organization Object: The Organization object in Saviynt represents the organizational structure or hierarchy (e.g., departments, locations, cost centers). It's often used to define relationships between users and organizational units.

User Update Rule: This type of rule is designed to automatically update user attributes based on changes in other user attributes or related objects.

Using Organization with User Update Rule: The User Update Rule is frequently used with the Organization object to automate user management based on organizational changes.

Example: You can create a User Update Rule that automatically assigns users to specific roles or groups based on their department (defined in the Organization object). If a user is moved to a different department, the rule will trigger and update their roles or group memberships accordingly.

Dynamic User Management: This combination enables dynamic user management, ensuring that user attributes and access rights are automatically adjusted as users move within the organization.

Other Options:

A . Technical Rule: Technical Rules are more general-purpose and can be used for various tasks, but they are not specifically tied to the Organization object.

C . Scan Rule: Scan Rules are used for data analysis and identifying potential issues, not for updating user attributes based on organizational structure.

D . Request Rule: Request Rules are related to access request workflows, not to automatic user updates.

In essence: The User Update Rule, when used in conjunction with the Organization object, provides a powerful way to automate user management in Saviynt, ensuring that user attributes and access rights are dynamically updated based on changes in the organizational structure.


Question 6

The following USER_IMPORT_MAPPING attribute is set up in Workday RAAS connection:

USER_IMPORT_MAPPING

{

"ImportType": "RAAS",

"ResponsePath": "wd:Report_Data.wd:Report_Entry",

"ImportMapping": {

"USERNAME": "wd:User_Name~#~string",

"SYSTEMUSERNAME": "wd:User_Name~#~string",

"FIRSTNAME": "wd:First_Name~#~string",

"CITY": "wd:Location.wd:Descriptor~#~string"

}

}

As per the above mapping, USERNAME is the user attribute defined in Workday, and User_Name is the attribute defined in EIC.



Answer : B

The statement is False. In the provided USER_IMPORT_MAPPING, USERNAME is the user attribute defined in EIC (Enterprise Identity Cloud), and wd:User_Name is the attribute defined in Workday. Here's a breakdown:

Saviynt's USER_IMPORT_MAPPING: This configuration within a connection (in this case, Workday RAAS) defines how data from the connected system (Workday) should be mapped to attributes within Saviynt's EIC.

ImportMapping: This section specifies the mapping between source attributes (Workday) and target attributes (EIC).

USERNAME: In the provided mapping, USERNAME (without the wd: prefix) is the target attribute, meaning it's an attribute within Saviynt's EIC.

wd:User_Name: The wd: prefix typically indicates a Workday attribute. Therefore, wd:User_Name is the source attribute from Workday.

~#~string: This likely indicates the data type of the attribute (string in this case).

Correct Interpretation: The mapping is saying: 'Take the value of the wd:User_Name attribute from Workday and map it to the USERNAME attribute in EIC.'

In essence: The USER_IMPORT_MAPPING defines how data from Workday is translated into Saviynt's internal data model, and in this case, USERNAME belongs to Saviynt (EIC), while wd:User_Name belongs to Workday.


Question 7

Which of the following options support Authentication Mechanisms in Saviynt?



Answer : D

Saviynt primarily leverages SAML 2.0 as its core authentication mechanism. SAML (Security Assertion Markup Language) is an open standard for exchanging authentication and authorization data between parties, in this case, between users and Saviynt. It allows for secure, single sign-on experiences.

While Saviynt can interact with databases, REST APIs, and LDAP directories for various purposes like identity data aggregation or provisioning, these are not its primary authentication methods.

Databases: Saviynt can connect to databases to pull identity information, but the platform itself doesn't authenticate users directly against a database.

REST: REST APIs are used for programmatic interaction with Saviynt, not typically for initial user authentication.

LDAP: While LDAP can be a source of identity data, Saviynt's core authentication relies on SAML for its standardized and secure approach.

Key Saviynt IGA references supporting this:

Saviynt Documentation: The official Saviynt documentation consistently refers to SAML as the primary authentication mechanism.

Saviynt Connectors: Saviynt provides pre-built connectors for various identity providers (IdPs) that support SAML, further emphasizing its reliance on this standard.

Saviynt Training Materials: Saviynt's training courses and certifications highlight SAML's role in the platform's authentication framework.


Page:    1 / 14   
Total 60 questions