PCF Field Validation
Which scenario follows best practices for user interface field-level validation?
A. Proposed changes to user passwords contain only alphanumeric characters.
B. Store different social media profile addresses, regardless of the social media site involved.
C. The city and state populate automatically whenever a US user enters their ZIP code.
D. The interest rate field is 0 whenever a down payment is greater than EUR 5000.
Answer Option (Which option is correct) A. Proposed changes to user passwords contain only alphanumeric characters.
Explanation:
Field-level validation is appropriate for checking the format of an individual input. A regex tests the entered value and an input mask guides its structure. Validation differs from populating related fields, converting input, or performing unrelated business updates.
Verification note: The exact option selection could not be independently verified from accessible official documentation. Relevant official topic links are provided, but some exact configuration or training rules require the product Configuration Guide or Cloud Standards behind sign-in. The source key is retained.
Why the other options are incorrect:
B. Store different social media profile addresses, regardless of the social media site involved:
Storing multiple social profiles is a data-model requirement. It is not a restriction on one input format. The example does not state a field-level validation check.
C. The city and state populate automatically whenever a US user enters their ZIP code:
Populating city and state is derived-field behavior. It changes values based on another field. Validation instead determines whether an entered value is acceptable.
D. The interest rate field is 0 whenever a down payment is greater than EUR 5000:
Setting an interest rate is business calculation or defaulting. The rule depends on a down-payment amount. It is not the single-field character-format example selected here.
References:
Guidewire product documentation - Configuration Guide access
An insurer would like to include the Law Firm Specialty as part of the Law Firm's name whenever the name is displayed in a single widget. Which configurations follow best practices to meet this requirement?
A. Modify the Law Firm entity's displayname property to include the law firm's specialty.
B. Implement a getter method on the entity to return a formatted name that includes the law firm's specialty.
C. Place a Text Input widget in the ListView's Row container for the law firm's specialty.
D. Configure the entity name for the Law Firm entity to include law firm's specialty.
E. Add a custom field to the entity to store a concatenated display string.
F. Use a dynamic field to generate the display string to include the law firm's specialty.
G. Place a Text Cell widget in the ListView's Row container for the law firm's specialty.
Answer Option (Which option is correct) D. Configure the entity name for the Law Firm entity to include law firm's specialty.
Explanation:
Configure the entity name to combine the identifying fields that users need to see. This gives a consistent label wherever the entity is rendered by widgets that use its name. A setter changes state, a display key supplies localized text, and Post On Change refreshes widgets rather than defining the entity name.
Verification note: The exact option selection could not be independently verified from accessible official documentation. Relevant official topic links are provided, but some exact configuration or training rules require the product Configuration Guide or Cloud Standards behind sign-in. The source key is retained.
Why the other options are incorrect:
A. Modify the Law Firm entity's displayname property to include the law firm's specialty:
This proposes modifying a displayname property. The source instead names entity-name configuration. The terminology needs the exact configuration guide to distinguish them.
B. Implement a getter method on the entity to return a formatted name that includes the law firm's specialty:
A getter can return a formatted value. Widgets would need to use that getter explicitly. The question asks for the standard entity label everywhere.
C. Place a Text Input widget in the ListView's Row container for the law firm's specialty:
A TextInput adds another field to a particular view. It does not define the label in every single-widget display. The reuse requirement is broader than that view.
E. Add a custom field to the entity to store a concatenated display string:
A stored concatenated field duplicates existing data. It needs synchronization when the underlying name or specialty changes. A derived entity name avoids that extra stored state.
F. Use a dynamic field to generate the display string to include the law firm's specialty:
A dynamic value could be rendered in selected widgets. The option does not identify the standard entity-name configuration. Its scope is not sufficient to establish the requested global behavior.
G. Place a Text Cell widget in the ListView's Row container for the law firm's specialty:
A TextCell displays a separate list column. The requirement wants the specialty inside the same label. Adding a separate cell changes that presentation.
References:
Guidewire product documentation - Configuration Guide access
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)
A. DetailView
B. Popup
C. LocationGroup
D. ListView
E. InputSet
F. Worksheet
Answer Option (Which option is correct) A. DetailView
Answer Option (Which option is correct) D. ListView
Answer Option (Which option is correct) E. InputSet
Explanation:
DetailView, ListView, and InputSet are reusable presentation containers for fields or rows. They can be referenced from different pages to share a layout. Popups, Worksheets, and LocationGroups instead organize navigation or locations.
Verification note: The exact option selection could not be independently verified from accessible official documentation. Relevant official topic links are provided, but some exact configuration or training rules require the product Configuration Guide or Cloud Standards behind sign-in. The source key is retained.
Why the other options are incorrect:
B. Popup:
A Popup represents an interaction location. It is not one of the selected reusable field or row containers. Reusing a popup changes how the user navigates.
C. LocationGroup:
A LocationGroup organizes related locations. It does not share a field layout between pages. The requirement concerns repeated presentation components.
F. Worksheet:
A Worksheet opens work in a workspace location. It is different from the selected embedded layout containers. It does not directly centralize a column of fields.
References:
Guidewire product documentation - Configuration Guide access
Which GUnit test method adheres to the Guidewire naming standards?
A. whenAssigningActivityTest
B. claimSegmentationTest
C. testBulkInvoiceBatchJob
D. testThatQuoteIsGenerated
Answer Option (Which option is correct) C. testBulkInvoiceBatchJob
Explanation:
A GUnit test needs an appropriate test base class and a valid test lifecycle. Tests that execute Gosu database queries need a server-capable environment. Test method naming and shared setup should follow the conventions of the target Guidewire release.
Verification note: Both testBulkInvoiceBatchJob and testThatQuoteIsGenerated begin with test. The source does not provide a convention that unambiguously excludes the latter.
Why the other options are incorrect:
A. whenAssigningActivityTest:
The name ends in Test. It does not use the leading test pattern selected in the PDF. The course naming convention needs verification.
B. claimSegmentationTest:
This also places Test at the end. The source selects a leading test name. Whether the framework discovers it depends on the test convention.
D. testThatQuoteIsGenerated:
This name begins with test. It appears compatible with the same visible prefix as option C. The stem provides no rule that unambiguously excludes it.
References:
Guidewire-authored PolicyCenter 10.1.2 - GUnit Testing Guide
An insurer has a number of employees working remotely. Displaying the employee's name in a drop-down list must include the employee's location (e.g., John Smith - London, UK). How can a developer satisfy this requirement following best practices?
A. Define an entity name that concatenates the name fields and work locations
B. Create a displaykey that concatenates the name fields and work locations
C. Create a setter property in a Name enhancement class
D. Enable Post On Change for name fields to modify how the name is displayed
Answer Option (Which option is correct) A. Define an entity name that concatenates the name fields and work locations
Explanation:
Configure the entity name to combine the identifying fields that users need to see. This gives a consistent label wherever the entity is rendered by widgets that use its name. A setter changes state, a display key supplies localized text, and Post On Change refreshes widgets rather than defining the entity name.
Verification note: The exact option selection could not be independently verified from accessible official documentation. Relevant official topic links are provided, but some exact configuration or training rules require the product Configuration Guide or Cloud Standards behind sign-in. The source key is retained.
Why the other options are incorrect:
B. Create a displaykey that concatenates the name fields and work locations:
A display key contains localized text. It does not itself define the dynamic name of each employee. The label must read that employee name and location.
C. Create a setter property in a Name enhancement class:
A setter mutates an assigned property. It does not calculate the display label on read. The requirement is derived presentation.
D. Enable Post On Change for name fields to modify how the name is displayed:
Post On Change refreshes dependent widgets. It does not define the standard label for employee references. The name configuration must provide that combined value.
References:
Guidewire product documentation - Configuration Guide access
An insurer requires specific fields for a new Adjuster contact, which is a specific type of User contact. Which actions follow best practices for adding these Adjuster-specific fields? (Select two)
A. Add the new fields to the Adjuster subtype entity.
B. Define the Adjuster fields directly in the base User entity.
C. Create an Adjuster subtype entity.
D. Create a new entity AdjusterDetails_Ext and link it via foreign key to User.
Answer Option (Which option is correct) A. Add the new fields to the Adjuster subtype entity.
Answer Option (Which option is correct) C. Create an Adjuster subtype entity.
Explanation:
A specialized contact should be represented as a subtype of the closest applicable existing entity. The subtype inherits the common fields and adds only the fields specific to that contact kind. A scalar flag or a separately linked entity does not provide the same inheritance relationship.
Why the other options are incorrect:
B. Define the Adjuster fields directly in the base User entity:
Adding adjuster fields to User affects all user subtypes. The requirement applies to adjusters specifically. A dedicated subtype keeps unrelated users unaffected.
D. Create a new entity AdjusterDetails_Ext and link it via foreign key to User:
A linked details entity introduces a separate relationship. It does not make the adjuster a user subtype. The requested specialization is expressed through inheritance.
References:
Guidewire - Custom entity and subtype data model examples
Which two statements are true regarding the Guidewire Cloud Assurance process? (Select two)
A. Cloud Assurance does not apply to customer projects migrating self-managed implementations into Guidewire Cloud Platform.
B. Items in the Optimization Backlog must be resolved before deployment to the Cloud.
C. Cloud Assurance applies to both new Guidewire Cloud implementations and customer projects migrating self-managed implementations into Guidewire Cloud Platform.
D. Cloud Assurance applies to new Guidewire Self-managed implementations.
E. The Optimization Backlog includes Guidewire suggestions for improvement.
Answer Option (Which option is correct) C. Cloud Assurance applies to both new Guidewire Cloud implementations and customer projects migrating self-managed implementations into Guidewire Cloud Platform.
Answer Option (Which option is correct) E. The Optimization Backlog includes Guidewire suggestions for improvement.
Explanation:
The source describes Cloud Assurance as applying to new cloud implementations and projects moving to Guidewire Cloud. Recommendations in an optimization backlog are distinct from mandatory deployment blockers. Self-managed work should not automatically be treated as having the same cloud-assurance scope.
Verification note: The exact option selection could not be independently verified from accessible official documentation. Relevant official topic links are provided, but some exact configuration or training rules require the product Configuration Guide or Cloud Standards behind sign-in. The source key is retained.
Why the other options are incorrect:
A. Cloud Assurance does not apply to customer projects migrating self-managed implementations into Guidewire Cloud Platform:
The source includes migrations from self-managed implementations. This option explicitly excludes them. The project scope conflicts with the source description.
B. Items in the Optimization Backlog must be resolved before deployment to the Cloud:
An optimization backlog can contain improvement recommendations. That does not establish that every item blocks deployment. Mandatory findings need to be distinguished from recommendations.
D. Cloud Assurance applies to new Guidewire Self-managed implementations:
A new self-managed implementation is not inherently a cloud deployment. The question concerns Cloud Assurance scope. The exact assurance policy must govern that classification.
References:
Guidewire - Automated Cloud Assurance and inspection sources
Guidewire Cloud Standards - Sign-in required
Given the following Gosu method definition: function calculateDiscount( amount : Decimal ) : amount { if ( amount > 1000 ) { return amount * 0.10 } else { return amount * 0.05 } } Identify the two errors in this Gosu method definition.
A. The variable name amount is not descriptive.
B. The comparison amount > 1000 is missing parentheses.
C. The return type amount is incorrect.
D. The method name calculateDiscount does not follow camel case.
E. The variable amount is not initialized.
F. The return type should be Decimal.
Answer Option (Which option is correct) C. The return type amount is incorrect.
Answer Option (Which option is correct) F. The return type should be Decimal.
Explanation:
Gosu declarations must use valid parameter and return types, meaningful names, and the expected naming conventions. Function names use lower camel case. A declared return type is a type such as Decimal, not the name of the incoming value.
Why the other options are incorrect:
A. The variable name amount is not descriptive:
The parameter amount describes the input quantity. It is initialized by the caller. Its name is not the visible return-type error.
B. The comparison amount > 1000 is missing parentheses:
The comparison already has parentheses. There is no missing parenthesis at that location. The malformed return type is elsewhere.
D. The method name calculateDiscount does not follow camel case:
calculateDiscount already uses lower camel case. Its first word starts with a lowercase letter. Renaming it would not fix the type declaration.
E. The variable amount is not initialized:
A method parameter receives its value from the caller. It does not need a separate local initialization. The return type must still be declared as a type.
References:
Guidewire-authored PolicyCenter 10.1.2 - Gosu naming and declarations
Gosu language project - Operators, loops, functions, and properties
An insurance carrier plans to launch a new product for various types of Recreational Vehicles (RVs)-such as motorhomes, boats, motorcycles, and jet skis. When collecting information to quote a policy, all RVs share some common details (like purchase date, price, year, make, and model), but each type also has its own unique properties. According to best practices, what should be done to configure the User Interface so that only the relevant RV details are shown when creating a policy quote? Select Two
A. Create a separate page for each type of RV.
B. Create a Modal Input Set for each RV type.
C. Create separate inline Input Sets for each RV type and set the visibility on each Input Set
D. Create a Detail View that includes the properties that are common to all of the RV types.
E. Place an Input Set Ref on the Detail View and configure the RV type as the Mode.
F. Define a Location Group to allow the user to choose the page for each RV type.
Answer Option (Which option is correct) D. Create a Detail View that includes the properties that are common to all of the RV types.
Answer Option (Which option is correct) E. Place an Input Set Ref on the Detail View and configure the RV type as the Mode.
Explanation:
Keep fields shared by all subtypes in a common DetailView and use modal InputSets for subtype-specific details. The InputSet reference selects its mode from the relevant type or line of business. This avoids duplicating the common layout and scattering visibility logic across many individual widgets.
Verification note: The selected DetailView and modal reference imply subtype-specific modal InputSets, while option B separately proposes creating those sets. The requested pair needs course-context review.
Why the other options are incorrect:
A. Create a separate page for each type of RV:
Separate pages duplicate navigation and common field structure. The requirement can share one detail view. Only subtype-specific fields need to vary.
B. Create a Modal Input Set for each RV type:
Modal InputSets are relevant to the proposed design. The selected reference depends on suitable modal targets. The source does not explain why creating those targets is excluded.
C. Create separate inline Input Sets for each RV type and set the visibility on each Input Set:
Inline sets with visibility checks scatter the type-selection logic. A modal reference centralizes that selection. The listed design is less reusable for additional RV types.
F. Define a Location Group to allow the user to choose the page for each RV type:
A LocationGroup groups pages rather than subtype fields. It creates a navigation choice. The requirement concerns which fields appear within the quote view.
References:
Guidewire product documentation - Configuration Guide access
A ListView shows contacts related to a Claim. When a user clicks the contact name in a text cell, the UI should open a Worksheet showing details of that contact. The elementName property in the row iterator is currentContact. Which is the correct approach?
A. Set the Action property on the atomic widget to include ContactWS(currentContact)
B. Set the actionAvailable property on the atomic widget to ContactWS.push(currentContact)
C. Set the Action property on the atomic widget to ContactWS.goInWorksheet(currentContact)
D. Set the Action property on the atomic widget to ContactWS.goInWorkspace(currentContact)
Answer Option (Which option is correct) D. Set the Action property on the atomic widget to ContactWS.goInWorkspace(currentContact)
Explanation:
A navigation operation belongs on the clickable widget action, with the iterator element passed as the selected record. The source uses goInWorkspace for the Worksheet and push for the Popup. actionAvailable controls whether an action is available; it is not the place to perform the navigation.
Verification note: The exact option selection could not be independently verified from accessible official documentation. Relevant official topic links are provided, but some exact configuration or training rules require the product Configuration Guide or Cloud Standards behind sign-in. The source key is retained.
Why the other options are incorrect:
A. Set the Action property on the atomic widget to include ContactWS(currentContact):
This does not use the Worksheet navigation method selected by the source. A bare location call may not open the desired workspace. The target API must be checked for the course version.
B. Set the actionAvailable property on the atomic widget to ContactWS.push(currentContact):
actionAvailable is an enablement expression. It should not execute navigation as a side effect. The action receives the selected contact.
C. Set the Action property on the atomic widget to ContactWS.goInWorksheet(currentContact):
The source selects goInWorkspace rather than goInWorksheet. Those method names are not interchangeable without API evidence. Verify the actual Worksheet methods before importing this answer.
References:
Guidewire product documentation - Configuration Guide access
In the Extensions folder, there is a typelist file named BusinessType.ttx containing three typecodes: Insurer, Broker, and Agency. The business analysts have requested an additional typecode: Reinsurer. How should this typecode be added?
A. Create a reinsurer_Ext typecode in BusinessType.ttx
B. Create a reinsurer typecode in BusinessType.ttx
C. Create a .ttx extension file and add a reinsurer_Ext typecode to it
D. Create a Reinsurer_Ext typelist with a reinsurer typecode
Answer Option (Which option is correct) B. Create a reinsurer typecode in BusinessType.ttx
Explanation:
An existing typelist is extended through its .ttx file, creating that extension file when necessary. A new standalone typelist uses .tti instead. Updating the delivered .tti file or generated Java code is not the extension mechanism.
Verification note: The selected custom typecode has no _Ext suffix, unlike related naming guidance in Q12 and Q29. Retained rather than silently renaming it.
Why the other options are incorrect:
A. Create a reinsurer_Ext typecode in BusinessType.ttx:
This proposal uses the existing extension and a custom suffix. That is consistent with naming guidance in other questions. The PDF does not provide enough context to exclude it confidently.
C. Create a .ttx extension file and add a reinsurer_Ext typecode to it:
The question says a ttx extension already exists. Creating another extension is not the described starting state. The naming difference still needs review.
D. Create a Reinsurer_Ext typelist with a reinsurer typecode:
A new typelist does not add Reinsurer to BusinessType. It creates a separate classification. The existing list should contain the requested option.
References:
Guidewire - Typelist definition file kinds
Guidewire Cloud Standards - Sign-in required
A developer needs to create a new entity for renters that contains a field for the employment status. EmploymentStatusType is an existing typelist. How can the entity and new field be created to fulfill the requirement and follow best practices?
A. Create Renter_Ext.eti under Extensions -> Entity with a typekey EmploymentStatus.
B. Add Renter.etx under Metadata -> Entity with a column EmploymentStatus_Ext.
C. Add Renter.eti under Extensions -> Entity with a column EmploymentStatus_Ext.
D. Create EmploymentStatusType.ttx under Extensions -> Typelist with a type code Renter.
Answer Option (Which option is correct) A. Create Renter_Ext.eti under Extensions -> Entity with a typekey EmploymentStatus.
Explanation:
Create the new Renter_Ext entity in an .eti file and model employment status as a typekey that uses the existing EmploymentStatusType typelist. A plain column does not establish that typelist-backed choice. Extending the typelist is unnecessary merely to reference it from a new entity.
Why the other options are incorrect:
B. Add Renter.etx under Metadata -> Entity with a column EmploymentStatus_Ext:
Renter does not yet exist in the scenario. An etx cannot substitute for the new entity definition. A column also does not reference the employment typelist.
C. Add Renter.eti under Extensions -> Entity with a column EmploymentStatus_Ext:
This creates a nonsuffixed entity name. It also uses a generic column for a typelist value. The requested model needs a custom entity and a typekey.
D. Create EmploymentStatusType.ttx under Extensions -> Typelist with a type code Renter:
Adding a typecode called Renter changes the employment list. It does not create the renter entity. The existing EmploymentStatusType only needs to be referenced.
References:
Guidewire - Custom entity and subtype data model examples
| Page 4 out of 13 Pages |
| 2345 |
| InsuranceSuite-Developer Practice Test Home |
Real-World Scenario Mastery: Our InsuranceSuite-Developer practice exam don't just test definitions. They present you with the same complex, scenario-based problems you'll encounter on the actual exam.
Strategic Weakness Identification: Each practice session reveals exactly where you stand. Discover which domains need more attention, before Associate Certification - InsuranceSuite Developer - Mammoth Proctored Exam exam day arrives.
Confidence Through Familiarity: There's no substitute for knowing what to expect. When you've worked through our comprehensive InsuranceSuite-Developer practice exam questions pool covering all topics, the real exam feels like just another practice session.
Copyright © All Rights Reserved