it seems like a bad practice to just have it run as sudo, so I figured that this is a great chance to use sudoers. Using visudo I added a group, and gave it access to the file.
First, sudo and sudoers are practically the same thing. Second, that's not how sudoers works.
Sudo is just a tool to switch user accounts. This means that there's no such thing as "running as sudo". – if you use e.g. sudo myprogram to start a program as root, then it's just running as root.
It also means /etc/sudoers does not actually give access to files. The sudoers entries are not applied by the kernel, nor by anything else except the 'sudo' command itself. And the aliases listed within sudoers do not become system groups – they only act as macros within the same configuration file.
The only thing done by entries in /etc/sudoers is to allow the specified user account to run sudo this or sudo that – to run a whole program under some different user account (usually root but not necessarily).
Notice how most configuration examples do not list arbitrary files, they list paths to executables. For example, if your sudoers file has e.g. ALL = NOPASSWD: cat /path/to/file, then the user account will be able to run sudo cat /path/to/file and read its stdout... but it still won't be able to read the file directly.
ls -l shows the service is owned by root:
-rw-r--r-- 1 root root ...
It doesn't matter who owns the .service files, they just hold configuration for systemd. It also doesn't matter who owns the actual executables (unless the latter have the 'setuid' bit set, like rws – but in your case they do not).
For system services (those in '/etc/systemd/system'), the service manager always just uses the account specified in [Service] User=, and if it's not specified it'll use root.
But ps seems to say it's be executed by my user (not the system user I created).
It's possible that systemd is still using the previous configuration because it refused to load the new one – it couldn't verify that the my-fancy-group-name group actually exists. You only mention adding the group to /etc/sudoers, but that's the wrong location – system groups are only created via groupadd, or by adding them to /etc/group.
Note that systemd does not reload changes automatically. If your previous version of the .service file had User=my-user, this will stick until you run sudo systemctl daemon-reload followed by restarting the actual service – or until you reboot the system.
2) What is the best way for me to give the service access to the file?
Files have a group assigned to them using chgrp or chown. After you've actually created the group using 'groupadd', you can then chgrp the file to that group and give it read permissions:
groupadd my-fancy-group-name
chown :my-fancy-group-name /etc/ponies.conf
chmod g+w /etc/ponies.conf
The service's user account doesn't need to be a member of this group, since you already explicitly specified it in the service's Group= setting. However, if you actually want to add it as a permanent member, use gpasswd -a for that (which again edits /etc/group).
In case the file already has another group assigned and you don't want to change that, you can also use file ACLs. They work mostly the same way except there can be more than one user, and more than one group:
setfacl -m u:system-user-name:r <file>
-or-
setfacl -m g:my-fancy-group-name:r <file>
(Small side note that while ACLs are present, traditional "group" permissions get a different meaning, and to change the traditional permission bits you would need setfacl -m g::rx instead of chmod g=rx for example.)
/etc/systemd/system/my-service.servicesystemctl --userorsystemctl --system?systemctl. Traditionally, I've usedsudo systemctl startwhen I'm manually launching.