Last updated on February 25, 2026
Google App Engine Cheat Sheet
- A highly scalable fully managed serverless platform for developing and hosting web applications.
Features
- A fully managed environment to allow you to concentrate on deploying your application.
- Custom runtimes allow you to bring any library and framework to App Engine by supplying a Docker container.
- Application versioning is available to easily host different versions of your application and create development, test, staging, and production environments.
- Allows you to split traffic between different application versions to perform A/B testing.
- Application security: Use the App Engine firewall to define access rules. Managed SSL/TLS certificates are provided by default on your custom domain at no extra cost.
- Monitoring and diagnostics: Monitor application health and performance with Cloud Monitoring and Cloud Logging. Quickly diagnose and fix bugs with Error Reporting.
- Service ecosystem: Integrate with a growing ecosystem of Google Cloud services, including a suite of excellent cloud developer tools.
- A single Google Cloud project can contain one App Engine application. However, this application can host multiple services, each with its own versions.
App Engine Standard Environment
-
- Is based on container instances running on Google’s infrastructure.
- Containers are preconfigured with one of the several available runtimes.
- Supports applications written on Node.js, Java, Ruby, C#, Go, Python, PHP.
App Engine Flexible Environment
-
- Enables you to manage the underlying compute infrastructure.
- Supports applications written on Node.js, Java, Ruby, C#, Go, Python, PHP as well as custom runtimes.
Types of Scaling
You can specify what type of scaling you want to implement on your App Engine
- Basic
- Creates instances when your application receives requests.
- Each instance will be shut down when the application becomes idle.
- Automatic Scaling
- Creates instance based on request rate, response latencies, or other application metrics that you specify.
- Manual Scaling
- Allows you to manually specify the number of instances that continuously run regardless of the load level.
Pricing
Pricing is different for apps in the standard environment and the flexible environment. Estimate your costs using the Google Cloud Pricing Calculator. App Engine pricing is based on usage, with components like standard environment instances, flexible environment instances, and APIs.
App Engine Standard Environment
-
- Apps in the standard environment have a free quota for App Engine resources. Any use of App Engine resources beyond the free quota incurs charges as described in this section.
App Engine Flexible Environment
-
- App Engine does not provide free quota in the flexible environment.
- Apps running in the flexible environment are deployed to virtual machine types that you specify. These virtual machine resources are billed on a per-second basis with a 1-minute minimum usage cost.
Validate Your Knowledge
Question 1
Your company is planning to launch a web application to App Engine. It is crucial that your application can dynamically scale up and down based on the request rate. Moreover, you want to ensure that you have at least 3 unoccupied VMs at all times.
How should you configure your App Engine to support these scaling requirements?
- Configure Basic Scaling setting with
min_instances set to 3. - Configure Basic Scaling setting with
max_instances set to 3. - Set Automatic Scaling settings with
min_idle_instances set to 3. - Set Manual Scaling settings to 3 instances.
Correct Answer: 3
Automatic scaling creates instances based on request rate, response latencies, and other application metrics. You can specify thresholds for each of these metrics, as well as a minimum number of instances to keep running at all times.
App Engine calculates the number of instances necessary to serve your current application traffic based on scaling settings such as target_cpu_utilization and target_throughput_utilization. Setting the min_idle_instances element specifies the number of instances to run in addition to this calculated number. For example, if App Engine calculates that 5 instances are necessary to serve traffic, and min_idle_instances is set to 2, App Engine will run 7 instances (5, calculated based on traffic, plus 2 additional per min_idle_instances).
Note that you are charged for the number of instances specified whether they are receiving traffic or not. This setting only applies to the version that receives most of the traffic. Keep the following in mind:
– A low minimum helps keep your running costs down during idle periods but means that fewer instances might be immediately available to respond to a sudden load spike.
– A high minimum allows you to prime the application for rapid spikes in request load. App Engine keeps the minimum number of instances running to serve incoming requests. You are charged for the number of instances specified, whether or not they are handling requests.
If you set a minimum number of idle instances, pending latency will have less effect on your application’s performance.
Hence, the correct answer is: Set Automatic Scaling settings with min_idle_instances set to 3.
The option that says: Set Manual Scaling settings to 3 instances is incorrect because it only allows you to specify the number of instances to run regardless of the load level. This will not dynamically scale your compute resources based on the request rate.
The option that says: Configure Basic Scaling setting with min_instances set to 3 is incorrect because the Basic Scaling setting simply shuts down instances if the application becomes idle and does not scale based on request rate. This is useful for applications that are intermittent and is driven by user activity, but not for this scenario.
The option that says: Configure Basic Scaling setting with max_instances set to 3 is incorrect because this type of scaling just shuts down idle instances and is more suitable only when working with applications that are driven by user activity.Â
References:
https://cloud.google.com/appengine/docs/standard/python/how-instances-are-managed
https://cloud.google.com/appengine/docs/standard/python/config/appref
Note: This question was extracted from our Google Certified Associate Cloud Engineer Practice Exams.
Question 2
You have an App Engine application built by your team that is running in your development environment. The application has successfully passed the necessary regression tests and you need to build a new project for your production environment.
What should you do?
- Utilize the
gcloudtool to build a new project namedproduction. Deploy your team’s application to the newly created project. - Utilize the
gcloudtool to build the new project namedproduction. Copy the deployed application to the new project. - Create a new project named
production using the Cloud Console. Set up a Deployment Manager configuration file that replicates the current App Engine deployment into the newly created project. - Deploy your application again using the
gcloudtool and supply the project parameter namedproduction to create the new project.
Correct Answer: 1
Each Cloud project can contain only a single App Engine application and once created, you cannot change the location of your App Engine application.
You can select or create a new Google Cloud project and App Engine application to create and manage a collection of settings, credentials, and your app’s metadata. You can use gcloud app deploy command to deploy both code and configuration to the App Engine server.
Hence, the correct answer is: Utilize the gcloud tool to build a new project named production. Deploy your team’s application to the newly created project.
The option that says: Create a new project named production using the Cloud Console. Set up a Deployment Manager configuration file that replicates the current App Engine deployment into the newly created project is incorrect because the Deployment Manager is not capable of replicating an App Engine deployment.
The option that says: Deploy your application again using the gcloud tool and supply the project parameter named production to create the new project is incorrect because specifying the project parameter during deployment of the application in the App Engine does not automatically create a new project. You still need to create the project before deploying the application.
The option that says: Utilize the gcloud tool to build the new project named production. Copy the deployed application to the new project is incorrect because you cannot just copy an application and put it in the new project. You need to use the gcloud app deploy command to deploy your application to App Engine.
References:
https://cloud.google.com/appengine/docs/standard/python/console
https://cloud.google.com/sdk/gcloud/reference/app/deploy
Note: This question was extracted from our Google Certified Associate Cloud Engineer Practice Exams.
For more Google Cloud practice exam questions with detailed explanations, check out the Tutorials Dojo Portal:
Google App Engine Cheat Sheet References:
https://cloud.google.com/appengine/
https://cloud.google.com/appengine/docs
📣 Save 20% OFF on AI & ML Mock Exams, Video Courses and eBooks – AWS, Azure, Google Clouds, and GitHub Reviewers!
Learn AWS with our PlayCloud Hands-On Labs
$2.99 AWS and Azure Exam Study Guide eBooks
New AWS Generative AI Developer Professional Course AIP-C01
Learn GCP By Doing! Try Our GCP PlayCloud
Learn Azure with our Azure PlayCloud
FREE AI and AWS Digital Courses
FREE AWS, Azure, GCP Practice Test Samplers
Subscribe to our YouTube Channel
Follow Us On Linkedin
Written by: Jon Bonso
