chore(rds): inherit RemovalPolicy in auto-created DatabaseCluster ParameterGroup

[pahud]

Issue # (if applicable)

Closes #35273.

Reason for this change

When a DatabaseCluster is configured with custom parameters using the parameters property, the CDK automatically creates a ParameterGroup resource. However, this auto-created ParameterGroup was not inheriting the cluster's RemovalPolicy setting, causing CloudFormation stack deletion failures.

Problem: If a DatabaseCluster has removalPolicy: RemovalPolicy.RETAIN and uses the parameters property, the auto-created ParameterGroup would have the default deletion policy. When attempting to delete the CloudFormation stack, the deletion would fail with an error like "Parameter Group is still in use by database instances" because the cluster was retained but the parameter group was being deleted.

Impact: This prevents users from successfully deleting CloudFormation stacks containing RDS clusters with custom parameters and retention policies, requiring manual cleanup of parameter groups.

Description of changes

This change ensures that auto-created ParameterGroup resources inherit the parent DatabaseCluster's RemovalPolicy by adding a single line to the parameter group creation logic:

• Core Change: Added removalPolicy: helperRemovalPolicy(props.removalPolicy) to the auto-created ParameterGroup constructor in DatabaseCluster
• Pattern Consistency: Uses the existing helperRemovalPolicy() utility function, following the same pattern used for other auto-created resources like SubnetGroup
• Scope: Only affects auto-created parameter groups (when parameters prop is used without explicit parameterGroup)
• Backward Compatibility: No changes to existing explicit ParameterGroup behavior or public APIs

Design Decision: The implementation follows the established CDK pattern where helper resources inherit policies from their parent constructs. This ensures consistent behavior across all auto-created resources in the RDS module.

Alternative Considered: We could have made this configurable via a separate property, but that would complicate the API unnecessarily when the inheritance behavior is the expected and logical default.

Describe any new or updated permissions being added

N/A - This change only affects CloudFormation resource deletion policies, not IAM permissions.

Description of how you validated changes

Unit Tests: Added comprehensive test coverage for RemovalPolicy inheritance:

• Test case for RemovalPolicy.RETAIN → Parameter Group gets DeletionPolicy: Retain
• Test case for RemovalPolicy.SNAPSHOT → Parameter Group gets DeletionPolicy: Delete
• Test case for RemovalPolicy.DESTROY → Parameter Group gets DeletionPolicy: Delete
• All 228 existing cluster tests continue to pass, ensuring no regressions

Unit Testing: Unit tests verify that the generated CloudFormation templates include the correct DeletionPolicy and UpdateReplacePolicy attributes on auto-created AWS::RDS::DBClusterParameterGroup resources.

Regression Testing: Ran the complete RDS test suite to ensure existing functionality remains unchanged, including:

• Explicit parameter group behavior (unchanged)
• Other auto-created resource policies (SubnetGroup, etc.)
• All RemovalPolicy scenarios for clusters and instances

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license