fix: Expose publicNetworkAccess property to allow enabling/disabling public network access for MongoDB cluster.

[jeevankuduvaravindran]

Description

Expose publicNetworkAccess property to allow disabling public network access for MongoDB cluster. This property is available on mongo cluster API version 'Microsoft.DocumentDB/mongoClusters@2025-07-01-preview' and isnt yet surfaced on AVM module. This will allow the users to enable or disable public network access to mongo cluster. Added relevant documentation to readme.
Fixes #5901

Pipeline Reference

Pipeline

Type of Change

• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation
• Update to CI Environment or utilities (Non-module affecting changes)

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings
• I have updated the module's CHANGELOG.md file with an entry for the next version

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[microsoft-github-policy-service]

Important

If this is a module-related PR, being submitted by the sole owner of the module, the AVM core team must review and approve it (as module owners can't approve their own PRs).

To indicate this PR needs the core team''s attention, apply the "Needs: Core Team 🧞" label!

The core team will only review and approve PRs that have this label applied!

[jeevankuduvaravindran]

@microsoft-github-policy-service agree

[jeevankuduvaravindran]

@jeevankuduvaravindran please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

[AlexanderSehr]

0.4.2 is already published and has its entry right below this one. Please move line 19 up to line 10, the 'Changes' of version 0.4.3

[AlexanderSehr]

Did you run the Set-AVMModule script for this contribution, as per the Contribution Guide?
If not, please do so so that all generated files are updated correctly. No manual changes should be required for the readme (nor compiled JSON files).

[AlexanderSehr]

Suggested change

	@description('Optional. Controls public network access to the cluster. Allowed values: "Enabled", "Disabled".')
	@description('Optional. Controls public network access to the cluster.')

The allowed values are anyways communicated via Linter :)

[AlexanderSehr]

Great contribution @jeevankuduvaravindran 💪
@sinedied, I took the liberty of taking a quick look already but as the module's owner I'd appreciate if you could give the update a review yourself.

That said, @jeevankuduvaravindran please make sure to setup your fork as per the contribution guide, run the test workflow for this module and attach a pipeline badge to this PR. It is very important that we validate that all static & deployments tests pass before this PR goes in. Fixed any errors on Upstream main is a lot harder.

Also on that note, I'd highly recommend to create contributions never from your main branch as it locks you out of any other changes. Also as soon as you set up your fork's test environment, you'll find that there are automatic triggers on main (which are the ones that would publish your update in Upstream main once the PR is merged). Please make sure your diable your actions/workflows before pushing any changes to your fork's main branch. Otherwise a lot of workflows will start running in your fork you did not plan for 😉 This may help 💪