Using SaltStack's State Modules to Accept Newly Added Repo's Package Signing Key

Question

Problem

On a standalone minion, salt.states.pkgrepo.managed is being used to add a non standard software repo. The problem that's occurring, is that when a following sudo zypper update runs, the key has not been (auto) accepted by the system, preventing any packages from being updated or installed and thus the next state fails.

To reiterate with the exact state used mysuse.sls:

suse-gis-repo:
  pkgrepo.managed:
    - name: Application_Geo
    - humanname: Applications related to the earth (GIS, Mapping, geodesy, GPS, astronomy) (openSUSE_Leap_42.1)
    - baseurl: http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Leap_42.1/
    - gpgcheck: 1
    - gpgkey: http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Leap_42.1//repodata/repomd.xml.key

The problem is when the next phase of the state runs:

packages_uptodate:
  pkg.uptodate:
    - refresh: True

It fails because of required manual intervention shown below:

New repository or package signing key received:

Repository:       Application_Geo
Key Name:         Application:Geo OBS Project <Application:Geo@build.opensuse.org>
Key Fingerprint:  195E2111 06BC205D 2A9C2222 CC7F0748 9591C39B
Key Created:      Thu 16 Jul 2015 08:01:27 PM CEST
Key Expires:      Sat 23 Sep 2017 08:01:27 PM CEST
Rpm Name:         gpg-pubkey-9591c39b-55a7f177


Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r):

Attempts to Solve

1. Even if the last two lines of suse-gis-repo are commented out (ie. gpgchk & gpgkey), the problem described above still occurs.
2. zypper ar -G <URI> ensures the gpgkey is not checked but there is no option for this in the salt state.
3. One attempt to solve this problem, instead of using salt.states.pkgrepo.managed an attempt to use the corresponding execution module zypper.mod_repo was tried.

The example described in #3 is below:

package_autoaccept_key:
  module.run:
    - name: zypper.mod_repo
    - kwargs: {
          repo: 'Application_Geo',
          baseurl: 'http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Leap_42.1/',
          enabled: 'True',
          refresh: 'True',
          gpgcheck: 'True',
          gpgautoimport: 'True'
      }

With the error:

local:
----------
    ID: package_autoaccept_key
    Function: module.run
    Name: zypper.mod_repo
    Result: False
    Comment: Module function zypper.mod_repo is not available
    Started: 02:18:34.108787
    Duration: 543.087 ms
    Changes:

Summary for local
------------
Succeeded: 0
Failed:    1
------------

Questions

1. Is there a way to accept the key (always trust) autonomously, either via state or execution modules?

2. Are execution modules able to run on standalone minions via the module.run function?

3. If they are able to run on standalone minions, what is the best way to be sure the required module is present?

4. Is the approach of using module.run in a state a flawed approach to the said problem and if so why?