Workday-Prism-Analytics事前に試験練習テストで使おう（最新52問題) [Q25-Q50]

Workday-Prism-Analytics事前に試験練習テストで使おう（最新52問題)

有効なWorkday-Prism-Analytics試験解答PDF一年無料更新

質問 # 25
The final derived dataset in a Prism pipeline is complete and ready to publish. What should be done prior to publishing?

A. Create a table without the Enable for Analysis checkbox selected.
B. Add a Group By stage to the final derived dataset to add summary calculations.
C. Edit the Dataset API Name to reflect in the name of the Prism data source.
D. Create a derived dataset with the PDS suffix.

正解：C

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, before publishing a derived dataset as a Prism data source (PDS), it's important to ensure that the dataset is properly configured for downstream use. According to the official Workday Prism Analytics study path documents, one key step to take prior to publishing is to edit the Dataset API Name to reflect in the name of the Prism data source (option D). The Dataset API Name determines the name of the published Prism data source, which is used in reporting, discovery boards, and integrations. Setting a meaningful and descriptive API name (e.g., "Expense_Reports_by_Location") ensures that the data source is easily identifiable and aligns with naming conventions, improving usability and manageability in the Workday ecosystem. This step is a best practice to avoid confusion and ensure clarity for report writers and analysts.
The other options are not required or relevant:
* A. Add a Group By stage to the final derived dataset to add summary calculations: Adding a Group By stage is not mandatory unless the use case specifically requires summarizations, which is not indicated here.
* B. Create a table without the Enable for Analysis checkbox selected: Creating a new table is unnecessary, as the dataset is already complete, and the "Enable for Analysis" checkbox is relevant for real-time updates, not a requirement for publishing a derived dataset.
* C. Create a derived dataset with the PDS suffix: Creating a new dataset is not needed, as the final derived dataset is already prepared, and adding a "PDS" suffix is not a required step for publishing.
Editing the Dataset API Name ensures the Prism data source has a clear and meaningful name, facilitating its use in reporting and analytics.
References:
Workday Prism Analytics Study Path Documents, Section: Publishing and Visualizing Data, Topic: Best Practices for Publishing Prism Data Sources Workday Prism Analytics Training Guide, Module: Publishing and Visualizing Data, Subtopic: Configuring Dataset API Names Before Publishing

質問 # 26
You want to use a custom report containing prompts as a source connection for a table. What must you ensure to make this possible?

A. The custom report prompts have default values assigned on the report definition.
B. The prompts are marked as required.
C. The prompts are mapped at the data change task level.
D. The report is built on an indexed data source.

正解：A

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, when using a custom report with prompts as a source connection for a table, the custom report must be configured to ensure compatibility with the Prism data ingestion process. According to the official Workday Prism Analytics study path documents, the key requirement is that the custom report prompts have default values assigned in the report definition. This is necessary because Prism Analytics does not support interactive prompting during data ingestion. Default values ensure that the report can run automatically without requiring user input, allowing the Data Change task to retrieve the data consistently and load it into the target table.
The other options are not correct in this context:
* A. The report is built on an indexed data source: While indexed data sources can enhance performance for certain reports, they are not a requirement for using a custom report as a source for a Prism table.
* B. The prompts are mapped at the data change task level: Prompts are not mapped in the Data Change task; instead, the task relies on the report's default values to execute the data retrieval.
* D. The prompts are marked as required: Marking prompts as required does not address the need for automatic execution; default values are still needed to avoid manual intervention.
By assigning default values to prompts in the custom report definition, the report can be seamlessly integrated as a source connection for Prism Analytics, ensuring reliable data loading into the table.
References:
Workday Prism Analytics Study Path Documents, Section: Integrating Prism with Workday Reports, Topic:
Using Custom Reports as Data Sources
Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Configuring Custom Reports for Prism Integration

質問 # 27
The Prism use case is to classify workers based on their pay. You must create a field that evaluates worker pay and returns a value that represents various pay ranges. How would you add this field for inclusion on the Prism data source?

A. Build an Evaluate Expression calculated field on your final Prism business object to evaluate workers against their pay.
B. Build a CASE calculated field function on the TBL directly to ease later transformation.
C. Add the additional field to your raw data before you ingest into Prism.
D. Create a derived dataset and build a CASE calculated field to classify workers against their pay.

正解：D

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, classifying workers into pay ranges based on their pay requires creating a new field that evaluates the pay values and assigns them to defined ranges (e.g., "Low," "Medium," "High").
According to the official Workday Prism Analytics study path documents, the recommended approach is to create a derived dataset (DDS) and build a CASE calculated field to classify workers against their pay (option B). The CASE function in a calculated field allows users to define conditional logic (e.g., CASE WHEN pay
< 50000 THEN "Low" WHEN pay < 100000 THEN "Medium" ELSE "High" END), which is ideal for creating pay range classifications. This calculated field is added within a deriveddataset, which can then be published as a Prism data source, making the new field available for reporting and analytics.
The other options are not optimal:
* A. Add the additional field to your raw data before you ingest into Prism: Modifying raw data outside Prism is unnecessary and less flexible, as Prism's transformation capabilities (like CASE) are designed for such tasks.
* C. Build a CASE calculated field function on the TBL directly to ease later transformation: Calculated fields cannot be created directly on a table (TBL) in Prism Analytics; they must be defined in a derived dataset.
* D. Build an Evaluate Expression calculated field on your final Prism business object to evaluate workers against their pay: Prism Analytics does not use "Prism business objects" for calculated fields, and "Evaluate Expression" is not a standard function; this option is not applicable.
Using a CASE calculated field in a derived dataset provides a flexible and maintainable way to classify workers by pay ranges, ensuring the field is included in the final Prism data source.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Creating Calculated Fields with CASE Functions Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Classifying Data Using Calculated Fields in Derived Datasets

質問 # 28
You are adding a Join stage and choose Join type of Left Outer Join, causing Workday to search for a matching row in the imported pipeline. What happens if no matching rows exist?

A. A duplicate row will be generated.
B. Included fields from the imported pipeline will have NULL values.
C. Included fields from both pipelines will have NULL values.
D. The row will be omitted.

正解：B

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, a Left Outer Join in a Join stage includes all rows from the primary pipeline (the left pipeline) and attempts to match them with rows from the imported pipeline (the right pipeline) based on the join condition. According to the official Workday Prism Analytics study path documents, if no matching rows exist in the imported pipeline for a given row in the primary pipeline, the row from the primary pipeline is still included in the output, but the fields from the imported pipeline will have NULL values. This behavior ensures that all data from the primary pipeline is retained, while the absence of a match in the imported pipeline is represented by NULLs for the corresponding fields.
The other options are incorrect:
* A. A duplicate row will be generated: A Left Outer Join does not generate duplicate rows; duplicates would occur only if multiple matches exist in the imported pipeline, which is not the case here.
* B. The row will be omitted: In a Left Outer Join, rows from the primary pipeline are never omitted, even if no match is found; this behavior is specific to an Inner Join.
* D. Included fields from both pipelines will have NULL values: Only the fields from the imported pipeline will have NULL values; the fields from the primary pipeline retain their original values.
This behavior of Left Outer Join ensures that all records from the primary pipeline are preserved, with NULLs indicating the absence of matching data from the imported pipeline.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Join Types and Their Behaviors in Prism Analytics Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Configuring Join Stages in Derived Datasets

質問 # 29
You had to change the imported pipeline in a Join stage and your View Dataset Lineage report shows a Stage Alert regarding the disconnected pipeline. How can you fix this and make the alert disappear?

A. Publish the derived dataset.
B. Change the imported pipeline to a different one.
C. Add a Manage Fields stage and re-attach the pipeline.
D. Delete the disconnected pipeline.

正解：D

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, a Stage Alert in the View Dataset Lineage report indicates an issue with the dataset's transformation pipeline, such as a disconnected pipeline resulting from changing the imported pipeline in a Join stage. According to the official Workday Prism Analytics study path documents, a disconnected pipeline occurs when a pipeline (e.g., a table or dataset) is no longer referenced by any transformation stage, often after modifying the Join stage to use a different imported pipeline. To resolve this alert, the recommended action is to delete the disconnected pipeline (option D). By removing the disconnected pipeline from the dataset, the lineage is updated to reflect only the active pipelines, and the Stage Alert will disappear, indicating that the dataset's configuration is now valid.
The other options are not appropriate:
* A. Add a Manage Fields stage and re-attach the pipeline: A Manage Fields stage modifies field properties and cannot re-attach a disconnected pipeline to the Join stage.
* B. Publish the derived dataset: Publishing the dataset does not resolve the issue of a disconnected pipeline; the alert will persist until the pipeline is addressed.
* C. Change the imported pipeline to a different one: This does not address the disconnected pipeline; it only changes the Join stage's configuration again, potentially causing further issues.
Deleting the disconnected pipeline ensures the dataset's lineage is clean and free of errors, resolving the Stage Alert in the View Dataset Lineage report.
References:
Workday Prism Analytics Study Path Documents, Section: Datasets and Data Sources, Topic:
Troubleshooting Stage Alerts in Dataset Lineage
Workday Prism Analytics Training Guide, Module: Datasets and Data Sources, Subtopic: Managing Pipeline Connections in Derived Datasets

質問 # 30
While viewing your lineage, you realize you have forgotten to add a description to some of your derived datasets. From the lineage, you double-click on a dataset to view the dataset details. What is the next step to add the missing descriptions?

A. Select the pencil icon next to the Import stage to update the description.
B. Select Add Field from the dataset details to create a description.
C. Select Related Actions next to the dataset name and Edit Transformations.
D. Select the pencil icon next to the dataset name and Edit Transformations.

正解：C

解説：
To add or update the description of a derived dataset in Workday Prism Analytics, you should access the Edit Dataset Transformations task. This can be done by selecting the Related Actions next to the dataset name and choosing Edit Transformations. This method allows you to modify various aspects of the dataset, including its description.
This process is outlined in the Workday Prism Analytics User Guide, which states:
"If you have permission to edit a dataset, you can access the Edit Dataset Transformations task using these methods:
* Right-click the dataset name on the Data Catalog report and select Edit Transformations.
* Select Edit Transformations from the Quick Actions on the View Dataset Details report.
* Access the Edit Dataset task and select the dataset name that you want to edit." Once in the Edit Dataset Transformations task, you can update the dataset's description by clicking on the configuration icon (often represented as a gear or pencil icon) and editing the description field.
Reference: Workday Prism Analytics User Guide, "Concept: Dataset Workspace" section

質問 # 31
A Prism data writer has two pipelines of data that need to be joined together:
* The primary pipeline includes point of sale data by sales agent.
* The secondary pipeline includes performance rating by sales agent.
The requirement is to keep all of the point of sale data from the primary pipeline and blend in performance rating data for the agents from the secondary pipeline where it exists. What Join type should be used to blend the data together?

A. Full Outer Join
B. Left Outer Join
C. Right Outer Join
D. Inner Join

正解：B

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, the requirement to keep all data from the primary pipeline (point of sale data by sales agent) and blend in matching data from the secondary pipeline (performance rating by sales agent) where it exists indicates the need for a specific type of join. According to the official Workday Prism Analytics study path documents, a Left Outer Join (option C) is the appropriate join type for this scenario. A Left Outer Join includes all rows from the primary pipeline and matches them with rows from the secondary pipeline based on the join condition (e.g., sales agent ID). If no match is found in the secondary pipeline, the fields from the secondary pipeline will have NULL values, but the primary pipeline's data is fully retained, meeting the requirement to keep all point of sale data while blending in performance ratings where available.
The other options do not meet the requirement:
* A. Inner Join: An Inner Join only includes rows where matches exist in both pipelines, which would exclude point of sale data for sales agents without performance ratings, violating the requirement to keep all primary pipeline data.
* B. Right Outer Join: A Right Outer Join includes all rows from the secondary pipeline and matching rows from the primary pipeline, which prioritizes the secondary pipeline and may exclude some point of sale data, not meeting the requirement.
* D. Full Outer Join: A Full Outer Join includes all rows from both pipelines, with NULLs for non- matching rows, but this is broader than the requirement, which only needs all data from the primary pipeline, not necessarily all data from the secondary pipeline.
A Left Outer Join ensures that all point of sale data is retained while blending in performance ratings where they exist, aligning with the stated requirement.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Join Types and Their Applications in Prism Analytics Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Blending Data Using Join Stages

質問 # 32
You are loading data into a table using the Data Change task. The field type in the source file is Numeric and the table field type is Text. What can you do to load the data?

A. Use a different source file, as the field types are incompatible.
B. Change the field type in the parsing stage from Numeric to Text.
C. Map the Numeric field to the table Text field.
D. Change the connection type for the data change task.

正解：C

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, the Data Change task is used to load data from a source file into a table, and it supports flexible field type mapping to accommodate differences between source and target field types.
According to the official Workday Prism Analytics study path documents, when the source file has a Numeric field type and the target table has a Text field type, you can map the Numeric field to the Text field in the Data Change task. Workday Prism Analytics automatically handles the conversion of Numeric values to Text during the data loading process, as Text fields can store Numeric values as strings without data loss.
The other options are not necessary or appropriate:
* A. Use a different source file, as the field types are incompatible: The field types are not incompatible; Prism supports mapping Numeric to Text, making a new source file unnecessary.
* C. Change the field type in the parsing stage from Numeric to Text: The parsing stage defines how the source file is interpreted, but changing the source field type is not required since the mapping handles the conversion.
* D. Change the connection type for the data change task: The connection type (e.g., file upload or Workday report) is unrelated to field type compatibility and does not address the issue.
By mapping the Numeric field to the Text field in the Data Change task, the data can be successfully loaded, leveraging Prism's built-in type conversion capabilities to ensure compatibility.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Field Type Mapping in Data Change Tasks Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Handling Field Type Conversions in Data Loading

質問 # 33
You want to configure access to a published Prism data source to use it in reporting and discovery boards.
What action must you take?

A. Share the imported Workday report to provide users with access to the published Prism data source.
B. Edit the data source security and select a domain.
C. Share the dataset with appropriate users.
D. Schedule the recurring publish process.

正解：B

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, configuring access to a published Prism data source for use in reporting and discovery boards requires managing its security settings. According to the official Workday Prism Analytics study path documents, the necessary action is to edit the data source security and select a domain (option A).
After a dataset is published as a Prism data source, access is controlled through security domains. By editing the data source security and assigning it to an appropriate security domain (e.g., a domain that grants access to specific user groups like report writers or analysts), you ensure that authorized users can access the data source for reporting and discovery boards. This aligns with Workday's configurable security framework, ensuring that only users with the appropriate permissions can view or use the data source.
The other options are incorrect:
* B. Share the dataset with appropriate users: Sharing the dataset itself does not grant access to the published Prism data source; access to the data source is controlled through its security settings, not the dataset's sharing settings.
* C. Share the imported Workday report to provide users with access to the published Prism data source:
Sharing an imported Workday report does not affect access to the Prism data source; the data source's security must be configured directly.
* D. Schedule the recurring publish process: Scheduling a recurring publish process ensures the data source is updated regularly, but it does not configure access for reporting or discovery boards.
Editing the data source security and selecting a domain is the critical step to enable access for reporting and discovery boards.
References:
Workday Prism Analytics Study Path Documents, Section: Security and Governance in Prism, Topic:
Configuring Access to Prism Data Sources
Workday Prism Analytics Training Guide, Module: Security and Governance in Prism, Subtopic: Managing Data Source Security for Reporting

質問 # 34
You want to convert each instance of a multi-instance field and convert it to a single-instance field. What transformation stage can you use to do this?

A. Group By
B. Manage Fields
C. Unpivot
D. Explode

正解：D

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, a multi-instance field contains multiple values for a single record (e.g., a list of skills for a worker). To convert each instance of a multi-instance field into a single-instance field, you need a transformation that expands the data into multiple rows, with each row containing one instance. According to the official Workday Prism Analytics study path documents, the Explode stage (option B) is the transformation stage designed for this purpose. The Explode stage takes a multi-instance field and creates a new row for each instance, transforming the multi-instance field into a single-instance field in the output. For example, if a worker has three skills in a multi-instance field, the Explode stage will create three rows, each with a single skill value in a single-instance field.
The other options are incorrect:
* A. Unpivot: Unpivot transforms columns into rows (e.g., converting wide data to long format), but it does not handle multi-instance fields, which are a specific Workday data type.
* C. Manage Fields: The Manage Fields stage modifies field properties (e.g., type, name) but cannot expand a multi-instance field into multiple rows.
* D. Group By: The Group By stage aggregates data (e.g., summing values by a key) but does not convert multi-instance fields into single-instance fields.
The Explode stage is the correct transformation to achieve the conversion of a multi-instance field into a single-instance field by expanding the data into multiple rows.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Handling Multi-Instance Fields with Explode Stages Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Converting Multi-Instance Fields to Single-Instance Fields

質問 # 35
You accidentally delete a Prism calculated field that is used in other Prism calculated fields or conditions.
What is a possible outcome?

A. The system will automatically adjust any dependencies accordingly.
B. Any calculated field referencing the deleted field defaults to zero.
C. Errors will result in any stage or calculated field that references the field.
D. The system will automatically reverse the deletion because the field is referenced elsewhere.

正解：C

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, calculated fields are often interdependent, with one calculated field referencing another in its expression or being used in conditions within a dataset's transformation stages. According to the official Workday Prism Analytics study path documents, if a calculated field is deleted while other calculated fields or conditions depend on it, the system does not automatically handle the dependency. Instead, this deletion will cause errors in any stage or calculated field that references the deleted field. These errors occur because the dependent calculations or conditions can no longer resolve the reference to the deleted field, leading to failures in the dataset's transformation pipeline or when the dataset is processed or published.
The other options are incorrect:
A: The system will automatically reverse the deletion because the field is referenced elsewhere: Prism Analytics does not have an automatic reversal mechanism for deletions; users must manually restore the field if needed.
B: Any calculated field referencing the deleted field defaults to zero: The system does not default to zero; it will instead throw an error due to the unresolved reference.
D: The system will automatically adjust any dependencies accordingly: Prism does not automatically adjust dependencies; the user must manually update the dependent fields or conditions to resolve the issue.
The resulting errors highlight the importance of carefully managing dependencies when deleting calculated fields, ensuring that all references are updated or removed to avoid disruptions in the dataset's transformation logic.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Managing Calculated Fields and Dependencies Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Impact of Deleting Calculated Fields on Dataset Transformations

質問 # 36
A report that uses a Prism data source that you created has a brand new requirement that Expense Partner by Location should only see expense reports for workers for the locations they support. Given that you have the Location Hierarchy (instance) field in your dataset used for publishing, how can you adjust to meet the requirement?

A. Run the Edit Data Source Security task to update row-level security and then republish the PDS.
B. Run the Edit Data Source Security task to update row-level security.
C. Run the Edit Data Source Security task to update the Securing Entities and then republish the PDS.
D. Run the Edit Data Source Security task to update the Securing Entities.

正解：A

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, restricting access to specific rows in a Prism data source (PDS) based on afield like Location Hierarchy for users such as Expense Partners requires implementing row-level security.
According to the official Workday Prism Analytics study path documents, to meet the requirement that Expense Partners only see expense reports for the locations they support, you should run the Edit Data Source Security task to update row-level security and then republish the PDS (option B).
The Location Hierarchy (instance) field in the dataset can be used to define row-level security rules, ensuring that each Expense Partner only sees data for their assigned locations. The Edit Data Source Security task allows you to configure row-level security by mapping the Location Hierarchy field to the user's security profile (e.g., their assigned locations). After updating the security settings, republishing the Prism data source is necessary to apply the changes, ensuring the updated security rules take effect in the reports that use the data source.
The other options are incorrect:
* A. Run the Edit Data Source Security task to update the Securing Entities and then republish the PDS:
Securing Entities are used to control overall access to the data source (e.g., via security domains), not to restrict data at the row level based on a field like Location Hierarchy.
* C. Run the Edit Data Source Security task to update row-level security: While updating row-level security is correct, the changes will not take effect in reports until the data source is republished, making this option incomplete.
* D. Run the Edit Data Source Security task to update the Securing Entities: As with option A, updating Securing Entities does not address row-level security for location-based restrictions.
Updating row-level security and republishing the PDS ensures that Expense Partners only see the relevant expense reports, meeting the requirement while maintaining security governance.
References:
Workday Prism Analytics Study Path Documents, Section: Security and Governance in Prism, Topic:
Implementing Row-Level Security in Prism Data Sources
Workday Prism Analytics Training Guide, Module: Security and Governance in Prism, Subtopic: Configuring Row-Level Security for Location-Based Access

質問 # 37
You want your derived dataset to only show rows that meet the following criteria: Agent ID is not null AND Location is Dallas OR Location is Montreal. How can you achieve this?

A. By adding a Manage Fields stage.
B. By using Advanced Filter conditions.
C. By creating a Custom Example.
D. By using Simple Filter conditions.

正解：B

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, filtering a derived dataset to meet specific criteria involving multiple conditions with mixed logical operators (AND, OR) requires careful configuration. The criteria here are: Agent ID is not null AND (Location is Dallas OR Location is Montreal). According to the official Workday Prism Analytics study path documents, this can be achieved by using Advanced Filter conditions (option C).
A Simple Filter in Prism Analytics allows for basic conditions with a single operator ("If All" for AND, "If Any" for OR), but it cannot handle nested logic like AND combined with OR in a single filter. For example, a Simple Filter with "If All" would require all conditions to be true (Agent ID is not null AND Location is Dallas AND Location is Montreal), which is too restrictive. A Simple Filter with "If Any" would include rows where any condition is true (Agent ID is not null OR Location is Dallas OR Location is Montreal), which is too broad. The Advanced Filter, however, allows for complex expressions with nested logic, such as ISNOTNULL(Agent_ID) AND (Location = "Dallas" OR Location = "Montreal"), ensuring the correct rows are included.
The other options are incorrect:
* A. By adding a Manage Fields stage: The Manage Fields stage modifies field properties (e.g., type, visibility) but does not filter rows based on conditions.
* B. By using Simple Filter conditions: As explained, a Simple Filter cannot handle the combination of AND and OR logic required for this criteria.
* D. By creating a Custom Example: Custom Examples are used to provide sample data for testing, not to filter rows in a dataset.
Using Advanced Filter conditions allows for the precise application of the required logic to filter the dataset accurately.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Filtering Data in Derived Datasets Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Using Advanced Filters for Complex Conditions

質問 # 38
When joining datasets, what items must match?

A. The field names for the Match Row fields.
B. The level of detail in each dataset.
C. The field types for the Match Row fields.
D. The number of rows in each dataset.

正解：C

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, joining datasets requires that the fields used in the join condition (Match Row fields) are compatible to ensure accurate matching. According to the official Workday Prism Analytics study path documents, the field types for the Match Row fields must match (option A). For example, if the join condition is based on an Employee ID field, the field type (e.g., Text or Numeric) must be the same in both datasets. Mismatched field types (e.g., Text in one dataset and Numeric in another) can lead to join failures or incorrect results, as Prism cannot reliably compare values of different types. This often requires using a Manage Fields stage to align field types before the join.
The other options are incorrect:
* B. The number of rows in each dataset: The number of rows does not need to match; joins can handle datasets of different sizes, depending on the join type (e.g., Left Outer Join).
* C. The level of detail in each dataset: The level of detail (granularity) does not need to match; joins can combine datasets with different levels of detail as long as the Match Row fields are compatible.
* D. The field names for the Match Row fields: The field names do not need to be identical; the join condition maps fields between datasets, so different names can be used as long as the types and values are compatible.
Ensuring that the field types of the Match Row fields are the same is critical for a successful join operation in Prism Analytics.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic:
Requirements for Joining Datasets in Prism Analytics
Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Configuring Join Conditions for Datasets

質問 # 39
For a Prism use case, you have two datasets: one contains daily sales data, and the other contains monthly budget allocations. Before performing a join between these datasets, what transformation stage should you apply to the sales data to ensure it matches the granularity of the budget data?

A. Union
B. Filter
C. Group By
D. Manage Fields

正解：C

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, joining datasets with different levels of granularity requires aligning their granularity to ensure a meaningful match. The sales data is at a daily level (one row per day), while the budget data is at a monthly level (one row per month). According to the official Workday Prism Analytics study path documents, to match the granularity of the monthly budget data, you should apply a Group By stage to the sales data (option B). The Group By stage aggregates the daily sales data into monthly totals (e.g., summing sales amounts by month), reducing the granularity from daily to monthly. This allows the sales data to be joined with the monthly budget data on a common key, such as the month.
For example, a Group By stage could group the sales data by a derived month field (e.g., using a function like EXTRACT(YEAR_MONTH, sale_date)) and aggregate the sales amounts using a function like SUM (sales_amount). The resulting dataset would have one row per month, matching the budget data's granularity.
The other options are incorrect:
* A. Union: A Union stage appends rows from one dataset to another but does not change granularity; it cannot aggregate daily data into monthly data.
* C. Manage Fields: The Manage Fields stage modifies field properties (e.g., type, name) but does not aggregate data to change granularity.
* D. Filter: A Filter stage removes rows based on conditions but does not aggregate data to align granularity levels.
The Group By stage is the appropriate transformation to align the sales data's granularity with the monthly budget data for a successful join.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Aligning Granularity for Joins in Prism Analytics Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Using Group By Stages for Data Aggregation

質問 # 40
Using three different source files, you want to load rows of data into an empty table through a Data Change task. What needs to be the same about the three source files?

A. Size
B. Source
C. Naming convention
D. Schema

正解：D

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, a Data Change task is used to load or update data into a table, which can involve importing data from multiple source files. According to the official Workday Prism Analytics study path documents, when loading rows from multiple source files into an empty table, the source files must share the same schema. The schema defines the structure of the data, including the column names, data types, and their order, which ensures that the data from all source files can be consistently mapped and loaded into the target table without errors.
The schema is critical because the Data Change task relies on a predefined table structure to process the incoming data. If the schemas of the source files differ (e.g., different column names or data types), the task will fail due to inconsistencies in data mapping. The other options are not required to be the same:
* Source: The source files can originate from different systems or locations (e.g., Workday, external systems, or file uploads) as long as the schema aligns.
* Naming convention: The names of the source files do not need to follow a specific convention for the Data Change task to process them.
* Size: The size of the source files (e.g., number of rows or file size) can vary, as the task processes the data based on the schema, not the volume.
Thus, the requirement for the source files to have the same schema ensures seamless data loading into the table, maintaining data integrity and consistency during the transformation process.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Data Change Tasks and Schema Requirements Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Loading Data into Tables Using Data Change Tasks

質問 # 41
You apply an Explode stage to your derived dataset that contains information on your worker benefit elections. What happens in the resulting stage?

A. The number of rows exponentially increases and the original multi-instance field gets dropped.
B. The number of rows stays the same and the original multi-instance field does not get dropped.
C. The number of columns exponentially increases and the original multi-instance field gets dropped.
D. The number of columns stays the same and the original multi-instance field doesn't get dropped.

正解：A

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, an Explode stage is used to transform a multi-instance field into multiple rows, creating a single-instance field for each instance. According to the official Workday Prism Analyticsstudy path documents, when an Explode stage is applied to a derived dataset containing worker benefit elections (a multi-instance field, e.g., a list of elected benefits per worker), the following occurs: the number of rows exponentially increases, and the original multi-instance field gets dropped (option D).
For example, if a worker has three benefit elections in a multi-instance field, the Explode stage will create three rows-one for each election-while the original multi-instance field (e.g., "Benefit Elections") is replaced by a single-instance field containing one election per row. The number of rows increases based on the number of instances in the multi-instance field (e.g., a dataset with 100 workers, each with 3 elections on average, would grow from 100 rows to 300 rows). The term "exponentially" in the question reflects this potential for significant row growth, though the increase is technically linear per record based on the number of instances.
The other options are incorrect:
* A. The number of columns stays the same and the original multi-instance field doesn't get dropped: The original multi-instance field is dropped and replaced by a single-instance field; the column count may change slightly due to this replacement.
* B. The number of columns exponentially increases and the original multi-instance field gets dropped:
The Explode stage does not increase the number of columns exponentially; it primarily affects rows, with minimal impact on columns.
* C. The number of rows stays the same and the original multi-instance field does not get dropped: The number of rows increases due to the explosion of multi-instance data, and the original field is dropped.
The Explode stage's behavior of increasing rows and dropping the original multi-instance field aligns with its purpose of normalizing multi-instance data into a row-based structure.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Using the Explode Stage in Derived Datasets Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Handling Multi- Instance Fields with Explode Stages

質問 # 42
You are a new Prism customer and you want to ensure the correct set of fields is brought into a derived dataset. When should you apply a Manage Fields stage?

A. At the end of the Primary Pipeline of a published dataset.
B. At the beginning of the Primary Pipeline of the derived dataset.
C. At the beginning of the primary pipeline of the Base Dataset.
D. After the dataset is published.

正解：B

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, a Manage Fields stage is used to control the fields in a dataset by renaming, hiding, or changing field types, among other actions. According to the official Workday Prism Analytics study path documents, to ensure the correct set of fields is brought into a derived dataset (DDS), the Manage Fields stage should be applied at the beginning of the Primary Pipeline of the derived dataset (option C).
Placing the Manage Fields stage early in the pipeline-right after the initial import stage (Stage 1)-allows you to define the field structure upfront, ensuring that subsequent transformationstages (e.g., Join, Filter, Calculate Field) operate on the desired set of fields. This approach helps maintain consistency and avoids unnecessary processing of fields that are not needed in later stages.
The other options are not optimal:
* A. After the dataset is published: You cannot add transformation stages like Manage Fields after a dataset is published; transformations must be applied during the dataset's creation or editing.
* B. At the end of the Primary Pipeline of a published dataset: Similar to option A, you cannot modify a published dataset's pipeline, and placing Manage Fields at the end would not prevent unnecessary fields from being processed in earlier stages.
* D. At the beginning of the primary pipeline of the Base Dataset: A Base Dataset does not have a transformation pipeline; it is a direct import of a table, so Manage Fields stages can only be applied in a Derived Dataset.
Applying the Manage Fields stage at the beginning of the derived dataset's Primary Pipeline ensures efficient data preparation and transformation.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Using Manage Fields in Derived Datasets Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Best Practices for Field Management in Pipelines

質問 # 43
A Prism administrator wants to hide a field that contains employee salary information but still allow the Prism data writers to view average salaries for employees by cost center. What is the reason for hiding this field?

A. To use computed values instead of base values.
B. To protect sensitive data.
C. To hide Prism-calculated fields used for interim processing.
D. To hide unpopulated or sparse data fields.

正解：B

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, hiding a field is a common practice to control access to sensitive information while still allowing necessary analytics to be performed. According to the official Workday Prism Analytics study path documents, the primary reason for hiding a field like employee salary information is to protect sensitive data. Employee salary is considered personally identifiable information (PII) or sensitive data, and hiding the field ensures that individual salary details are not exposed to unauthorized users or in published data sources. However, by hiding the field, Prism data writers can still use it in calculations-such as computing the average salary by cost center-because hidden fields remain accessible for transformation and aggregation purposes within the dataset but are not visible in the final output or to end users of the published data source.
The other options do not align with the scenario:
* B. To hide Prism-calculated fields used for interim processing: The salary field is a base field, not a calculated field used for interim processing, so this reason does not apply.
* C. To hide unpopulated or sparse data fields: There is no indication that the salary field is unpopulated or sparse; the concern is about its sensitivity, not its data quality.
* D. To use computed values instead of base values: Hiding the field does not inherently involve replacing it with computed values; the goal is to restrict visibility while still allowing computations like averages.
Hiding the salary field protects sensitive data while enabling aggregated analytics, aligning with Prism's security and governance capabilities.
References:
Workday Prism Analytics Study Path Documents, Section: Security and Governance in Prism, Topic:
Managing Field Visibility for Data Protection
Workday Prism Analytics Training Guide, Module: Security and Governance in Prism, Subtopic: Handling Sensitive Data in Datasets

質問 # 44
What security domain enables the ability to create a dataset?

A. Prism Datasets: Publish
B. Prism: Tables Create
C. Prism: Manage Data Source
D. Prism Datasets: Create

正解：D

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, the ability to create a dataset is governed by specific security domains within the Prism Analytics functional area. According to the official Workday Prism Analytics study path documents, the security domain that explicitly enables users to create datasets is the "Prism Datasets: Create" domain.
This domain grants users the necessary permissions to initiate the creation of both base and derived datasets within the Prism Analytics Data Catalog.
The process of creating a dataset involves defining the metadata and processing logic to manipulate data, which can include Workday or external (non-Workday) data sources. The "Prism Datasets: Create" domain ensures that only authorized users, such as Prism data analysts or administrators, can perform this task, aligning with Workday's configurable security framework. Other domains, such as "Prism Datasets: Publish," are responsible for publishing datasets to make them available as Prism Data Sources for reporting, while
"Prism: Manage Data Source" pertains to managing the data sources themselves, not creating datasets.
Similarly, "Prism: Tables Create" is related to creating tables, which is a distinct entity from datasets in Prism Analytics.
This distinction is critical, as datasets and tables serve different purposes in the data management workflow.
Datasets include metadata and a subset of example rows, while tables contain metadata and all data rows. The
"Prism Datasets: Create" domain is specifically designed to control access to dataset creation, ensuring secure and governed data preparation.
References:
Workday Prism Analytics Study Path Documents, Section: Security and Governance in Prism Analytics, Topic: Security Domains and Permissions Workday Prism Analytics Training Guide, Module: Datasets and Data Sources, Subtopic: Creating Datasets and Associated Security

質問 # 45
A Prism data writer has to create an intermediary Prism calculated field A, used only to achieve a final result in Prism calculated field B and they only need to publish out field B. What should they do?

A. Add a Manage Fields stage to the DDS and hide field B.
B. Delete field A from their DDS and just leave field B.
C. Mark field A as intermediate calculation.
D. Add a Manage Fields stage to the DDS and hide field A.

正解：D

解説：
Comprehensive and Detailed Explanation From Exact Extract:
In Workday Prism Analytics, when a data writer creates an intermediary calculated field (e.g., field A) solely to derive a final calculated field (e.g., field B) in a Derived Dataset (DDS), they may want to exclude the intermediary field from the published output to keep the dataset clean and focused. According to the official Workday Prism Analytics study path documents, the recommended approach is to add a Manage Fields stage to the DDS and hide field A. The Manage Fields stage allows users to control the visibility of fields in the dataset, enabling them to hide fields that are not needed in the final output while retaining their calculations for internal use within the dataset's transformation logic. By hiding field A, field B can still leverage field A's calculations, and only field B will be visible in the published dataset or data source.
The other options are not suitable:
A: Mark field A as intermediate calculation: There is no specific feature in Prism Analytics to "mark" a field as an intermediate calculation; this is not a supported action.
C: Add a Manage Fields stage to the DDS and hide field B: Hiding field B would defeat the purpose, as field B is the intended output to be published.
D: Delete field A from their DDS and just leave field B: Deleting field A would break the calculation of field B, as field B depends on field A, making this option infeasible.
Using the Manage Fields stage to hide field A ensures that the dataset remains functional while presenting only the necessary fields in the final output, aligning with best practices for data transformation and publishing.
References:
Workday Prism Analytics Study Path Documents, Section: Data Prep and Transformation, Topic: Managing Fields in Derived Datasets Workday Prism Analytics Training Guide, Module: Data Prep and Transformation, Subtopic: Configuring Field Visibility in Datasets

質問 # 46
......

Workday Pro Prism Analytics Exam無料更新認定サンプル問題：https://www.jpntest.com/shiken/Workday-Prism-Analytics-mondaishu

試験本場前にトレンドなWorkday Workday-Prism-AnalyticsのPDF問題集を試そう：https://drive.google.com/open?id=1RfJduqyqtBtBAOjbCZAzrQaQAEGN-VN7