Level 1 — Trainer Answer Guide: Crestwood Underwriting

Trainer Use Only

Do not share this page with candidates before or during the assessment.

The 12 issues and their correct answers are:

#	Location	Issue	Explanation	Fix
1	be_config.json	homePartyId is set to the placeholder urn:duns:000000000	Party matching, sanctions, and bureau submissions will operate against the wrong entity	Set to the client's real D&B DUNS number
2	be_config.json	AWS credentials (awsAccessKeyId, awsSecretAccessKey) are present in an S3 config file	Credentials committed to Git are compromised immediately. Environment-specific secrets must never appear in S3 config	Remove from be_config.json. Add the fields with placeholder values to dynamodb/{env}/data.json. Provide the actual credential values to DevOps via a secure channel — never commit real secrets to Git
3	be_config.json	Both roles have "permissions": ["ALL"]	Blanket permissions violate least-privilege. Users gain access to platform functions they should not have	Define explicit, role-appropriate permissions for each role
4	Business class listing	DUA-CH.json is present in the business-class directory	DUA-CH is a platform-reserved class for DUA processing only. Crestwood is Open Market only	Remove DUA-CH.json from the business-class directory
5	Repository root	master_submission_config.json and dec_submission_config.json are present	These are MGA/Binding Authority files that do not apply to an Open Market client. Orphaned files cause unexpected UI options to appear	Delete both files — they are not needed for Open Market
6	Repository root	dua/ directory with coverholder and bordereau config is present	Crestwood has no DUA business. The dua/ directory will cause DUA options to appear and bordereau pipelines to be registered	Delete the entire dua/ directory
7	actions/av/	Action file is named marine_open_market.json	Does not follow the {class-code}-{placement-type}-actions.json naming convention and references "marine" for an Aviation class	Rename to av-open-market-actions.json
8	initialPipeline	Sanctions check is the third step, after appetite and clearance	Sanctions must be the first or second step. Running it third means an uncleared entity could pass appetite and clearance before being screened	Move sanctions_check to be the first step in initialPipeline
9	initialPipeline — clearance step	Endpoint is hardcoded: "https://dev.crestwood.send.technology/clearance-check"	Hardcoded URLs only work in the environment they were written for. This will fail in UAT and Production	Use a platform variable: "${clientRestBaseUrl}/clearance-check"
10	subStatusPipelines vs statusMappings	STP_REFERRAL is defined in subStatusPipelines but has no corresponding entry in statusMappings	The workflow engine cannot resolve the referral status, causing submissions to become permanently stuck	Either add a STP_REFERRAL entry to statusMappings, or remove the referral entry from subStatusPipelines if no referral workflow is needed
11	completionPipeline	completionPipeline is set to null	Without a completion pipeline, there is no bind step. Submissions can never reach a bound status	Set completionPipeline to reference av_bind.json
12	av_bind.json	No validate_user_authority step before bind confirmation	Junior users can bind risks beyond their delegated authority with no enforcement	Add a validate_user_authority step as the first step in av_bind.json, before document generation