A developer is creating an enhancement class for the entity AuditMethod_Ext in PolicyCenter for an insurer, Succeed Insurance. Which package structure of the gosu class and function name follows best practice?
Correct Answer: B
Guidewire emphasizes a strict naming and packaging convention for custom Gosu classes and enhancements to ensure code clarity and to prevent "namespace collisions" during platform upgrades. For a customer like "Succeed Insurance," the best practice is to use a unique prefix for the package structure, typically derived from the company's initials and the specific application. In this case,"si.pc"(Succeed Insurance PolicyCenter) is the appropriate starting point for the package. Placing enhancements in a sub-package like"enhancements.entity"(Option B) logically organizes the code by its function, separating entity logic from other business rules or integration classes. This structure ensures that developers can easily locate custom logic added to both base entities and custom entities like AuditMethod_Ext. Regarding the function name, Guidewire best practices for enhancements dictate that custom methods added to an entity should include the_Extsuffix (e.g., determineAuditType_Ext()). This is crucial because if Guidewire later releases a product update that adds a method with the same name (determineAuditType) to the base entity, the customer's version will not conflict with the base version. Options C and D use the gw namespace, which is strictly reserved for Guidewire's internal "Out of the Box" code. Using the gw package for custom code can lead to severe compilation errors or unexpected behavior during upgrades, as the Guidewire platform assumes total ownership of that namespace. Therefore, utilizing the insurer's unique package prefix combined with the _Ext suffix on the method is the only approach that aligns with Guidewire's certification standards and long-term maintenance requirements.
Question 62
A query is known to return 500,000 rows. Which two are recommended to process all 500,000 rows efficiently? (Select two)
Correct Answer: B,C
Processing extremely large datasets-such as 500,000 rows-presents significant challenges for memory management and transaction stability in Guidewire. To handle this efficiently, developers must use the Gosu Query API correctly and choose the right execution context. The first best practice is the use of setPageSize() (Option B). When a query is executed, by default, the system might attempt to fetch a large number of rows into the application server ' s memory. By calling setPageSize (50) or setPageSize(100) on the query object, the developer instructs the database driver to fetch only a small " page " of records at a time. This keeps the memory footprint of the Gosu bundle low and prevents OutOfMemory errors, even though the developer can still iterate through the entire 500,000-row result set as if it were a single collection. The second best practice is to move such a heavy operation into a Batch Process (Option C). Executing a 500,000-row loop within a UI request or a standard rule would likely cause a web server timeout or block other threads. A Batch Process runs in the background, has its own dedicated work queue, and can be configured to " checkpoint " its progress. This means if the server restarts, the batch process can potentially resume where it left off. Options like sorting (Option E) can actually hinder performance on large sets if the database index is not optimized for that sort. " Chunking " (Option D) is conceptually similar to paging, but setPageSize() is the specific, built-in method provided by the Guidewire Query API to achieve this.
Question 63
An InsuranceSuite implementation project is preparing for deployment to the Guidewire Cloud Platform. Which two Cloud Delivery Standards must be met before deployment? (Select two)
Correct Answer: D,E
Moving to the Guidewire Cloud Platform (GWCP) introduces a set of mandatory " Cloud Delivery Standards " designed to ensure that customer implementations are secure, upgradeable, and performant. Two of the most critical pillars in these standards are Metadata Naming Conventions and Data Privacy/Security. First, naming conventions (Option D) are essential for maintaining the " Upgrade-Safe " nature of the cloud. In Guidewire Cloud, the base product is updated frequently. To prevent custom metadata (new entities or columns) from conflicting with future Guidewire base product releases, all extensions must use a unique customer suffix. While the standard example is _Ext, insurers often use their specific company initials, such as _Si for Succeed Insurance. This ensures that the custom data model remains distinct from the gw namespace. Second, the Observability and Security standards strictly forbid the logging of Personally Identifiable Information (PII) in plain text (Option E). In the cloud, logs are aggregated and viewed via tools like CloudWatch or Kibana. If sensitive data like Social Security Numbers, Credit Card numbers, or personal addresses are logged as clear text, it constitutes a major security risk and a violation of compliance standards like GDPR or SOC2. Guidewire ' s automated Quality Gates will often block a deployment if it detects potential PII leakage in the Gosu logging code. Options A and B are general development practices but not the primary delivery standards that block deployment. Option C is actually a security risk; hardcoding the " su " (Super User) in bundle management is generally discouraged in favor of more granular permission handling.
Question 64
Succeed Insurance has information that they want to display on multiple pages with the same layout. Which PCF container types can be used to meet this requirement? (Choose 3)
Correct Answer: A,D,E
One of the primary goals of PCF Configuration is modularity and reuse. Guidewire provides specific Container Widgets that allow developers to define a layout once and reference it in multiple locations throughout the application. * DetailView (DV): This is the standard container for displaying field-value pairs, typically organized in columns. A DV can be defined as a standalone PCF file and then referenced on multiple pages (like a Policy File screen and a Claim Summary screen) using a DetailViewRef. * ListView (LV): This container is used for tabular data or grids. Similar to DVs, LVs are often created as separate files so that the same table structure (with the same columns, sorting, and filtering) can be reused across different parts of the suite. * InputSet: This is a more granular container used specifically within DetailViews. An InputSet allows a developer to group a set of related widgets (like an address block or a set of contact fields). By using an InputSetRef, a developer can ensure that the " Address Layout " is identical on every screen that requires it, drastically reducing maintenance time. In contrast, Popups, LocationGroups, and Worksheets are classified as Locations, not containers. Locations define where a user is in the application (the URL or navigation state), whereas Containers (DV, LV, InputSet) define how the data is laid out inside those locations. Selecting these three containers allows for a " DRY " (Don ' t Repeat Yourself) development approach, which is a key best practice in InsuranceSuite Developer Fundamentals.
Question 65
Succeed Insurance would like a list of all Notes related to all Policies for an Account. Which approach follows best practices for retrieving this data more efficiently?
Correct Answer: B
In Guidewire InsuranceSuite, developers frequently need to " reach across " one-to-many relationships to collect data from nested arrays. In this scenario, the goal is to retrieve a flattened list of all Note entities associated with all Policy objects linked to a specific Account. According to Advanced Gosu best practices, the most efficient and idiomatic way to handle this is by using the Expansion Operator (*). As shown in Option B, the syntax account.Policies*.Notes performs what is known as " collection flattening. " When the expansion operator is applied to the Policies array, Gosu understands that it should look at every policy in that collection and access the Notes array for each. It then automatically flattens these multiple sub-collections into a single, comprehensive list of Note objects. Calling . toList() at the end ensures the result is captured in a standard, manipulatable collection format. This approach is vastly superior to nested for loops (Option C). Manual iteration through nested arrays is a primary cause of the " N+1 " query problem and " Bundle Bloat. " In nested loops, the system may perform a separate database fetch for every policy and then another for every note, loading every single entity into the current transaction bundle, which consumes excessive memory and CPU time. The expansion operator, however, is highly optimized within the Gosu Runtime to handle these traversals more gracefully. Option D is incorrect because it uses a second expansion operator to retrieve the DisplayName property, resulting in a list of Strings rather than a list of Note entities. Option A, while using the Query API, is logically disconnected from the root account object already in memory and represents a more complex search- based approach rather than a relationship-based retrieval. Therefore, the expansion operator is the verified standard for efficient, readable data collection in Gosu.
