Fields, field configuration, and screen schemes
Custom fields are created globally and have a type (text, select, date, user picker, number and so on). A field can have multiple contexts, each scoping it to specific projects and issue types and, for option-based fields, holding its own option list. Contexts answer “who can use this field”; they do not control required-ness.
Field configurations control, per field, whether it is required, optional or hidden; a field configuration scheme maps issue types to field configurations within a project. Screens control which fields appear on the create, edit and view operations and in what order; a screen scheme maps those operations to screens, and an issue type screen scheme maps issue types to screen schemes. So there are three independent levers: context (availability and options), field configuration (required or hidden), and screen (visible and order).
Traps: assuming a required field can be left off the screen - a required field missing from the create screen breaks issue creation; assuming adding a field to a screen is enough - it must also exist in the field configuration and, in company-managed projects, the issue type must be in the field's context; assuming contexts make a field required; and forgetting that deleting a custom field destroys its data in every project with no undo.
Rule of thumb: when different issue types need different required fields, build separate field configurations and map them through a field configuration scheme rather than duplicating fields.