Здесь могут быть 2 проблемы.
1-
При локальном тестировании приложения оно могло подключиться и пройти аутентификацию, поскольку файл application.properties был правильнонастроен с указанием пути к закрытому ключу в свойстве «..credentials.location». Когда App Engine развернут, подключается не приложение, а сам экземпляр App Engine , который обслуживает приложение. Что я подозреваю, что происходит в этом случае, App Engine не сказано, куда идти, чтобы получить надлежащие учетные данные, которые находятся в файле Spring Boot «application.properties».
В этом уроке , aаналогичная интеграция выполняется, когда приложение Spring Boot, работающее на App Engine, подключается к экземпляру Cloud SQL. Метод, используемый для указания App Engine на учетные данные, выполняется с помощью Spring Profiles , содержащего учетные данные , а также конфигурации файла « app.yaml »где профили активируются с помощью переменной среды «spring_profiles_active».
В качестве альтернативы, аутентификация может быть выполнена в Cloud SDK, как объяснено в шаге 5 примера, на который вы ссылались . Вот команда , используемая для получения учетных данных с помощью этого метода, а - это пример реализации из полного учебника.
2-
Пускатели Spring Boot используют Tomcat в качестве контейнеров сервлетов по умолчанию . App Engine использует Jetty в качестве контейнеров сервлетов . При развертывании App Engine, если зависимости Tomcat не игнорируются, они будут конфликтовать с Jetty. Это может произойти, если при выполнении развертывания App Engine возникла ошибка «osbweb.embedded.tomcat.TomcatStarter: Ошибка запуска контекста Tomcat».
Вот официальная документация Spring 1036 * накак исключить эти зависимости, и вот пример реализации в полном учебнике, который объединяет те же компоненты.