See the response by Karl Auer if you are taking this action if you suspect a system has been compromised. Ansible is not a "defense" program, nor is it a good tool to watch for and report changes to any system file. See "TripWire" and other tools mentioned.
But, I assume you're looking for the ability to ensure that your 500 servers have the proper configuration settings - such as ensure they are using the proper configuration files (e.g. sssd.conf settings for LDAP, or sshd.conf for SSH, etc).
You have some choices: the copy: or template: modules, or the lineinfile: module
Since most configuration files need to have a few lines changed, my preference is to use Ansible to push down the entire configuration file so you know exactly what is in there.
If you truly only have one line to change in the file, the lineinfile: module would work but it won't catch changes to other lines in the file. This might be a benefit to you if you're not the only one maintaining the file but it leaves you open to problems if the teams that are maintaining it don't communicate or test their changes well.
The template: module is my preferred method. You keep a copy of the file along side the playbook, and when Ansible runs it compares the file on the destination with the copy in the playbook and only copies it over if there is a difference. (I believe it uses a sha1sum of the file to save comparing long files, but I can't find that in the code to verify.)
The nice thing with templates is you can put in plain text files that are identical on all machines, or you can put in Ansible variables into the template files and use Jinja2 scripting to expand sections based on other Ansible variables.
For example, we use this heavily when we're configuring our RedHat systems to connect into our LDAP infrastructure. The sssd.conf file is a template, but within the template are configurations to use the correct LDAP servers (primary and secondary) for the machine to use. Each of our datacenters has a primary and secondary LDAP server, so even if I run the same playbook on a server in each datacenter, the variables that Ansible pulls in are unique each datacenter (machine) and the file is consistent each run for that machine but are maintained in one location company wide.
You could, though if you're that concerned then you'd want to setup TripWire and alert you when things change. Ansible can reset them if you determine it was a novice admin or honest mistake, but Ansible can't protect you from someone who's got in and setup a backdoor on the system.
Though Ansible can help you _recover_ by rebuilding a new system once you've found the back door and updated your hardening playbook to close it.
Hope that helps!