C is correct, need "ifnotpresent"when uploads to container registry

C is the best choice. You can create a k8s cluster with just one node and use a different namespaces for staging and production. In staging, you will test the changes

B because Kubernetes will be overkill and A is not reliable

A is wrong as after the restart the script will be rerun and fetch the code directly from the repo (even if production). The load of the massive number of dependencies will take a lot of timee, and the application version will be fuzzy.

C is correct, B (instance template cannote be updated once created.

C - Correct

The correct answer is C. Because it is the only option that RELIABLY tests the app in staging before it is applied to production. Remember that one of the requirements in the question is to reliably deploy the app.

You don't need GKE for 0.1 CPU, only A meet hte needs

For 0.1 CPU I will never use GKE, considering the associated cost with control plane and not even one option in the question mentioning micro instances for the node pool

When we read the question - "0.1 CPU cores and 128 MB of memory" to operate in production. You want to monitor and "maximize machine utilization"... Answer A should be a fit based on the question details. Would GKE for tiny application be overkill?

python app on compute engine is a disastrous architecture. C is the correct architecture which tests the app before putting to prod

You should use GKE, because your can scale up and down based on your demand. Also you can specifiy the resource size like 0.1 CPU and 128 MB of memory per Pod. Secondly, Kubernetes Deployment with the imagePullPolicy set to “IfNotPresent” in the staging namespace, and then promote it to production namespace after testing. is best practice.

f1 micro managed instance group fits all the requirements, with capability to run upto 2 instances per per for given requirement GKE cluster would be an overkill, with control plane nodes/cost not even being considered. n1-standard-1 instance would require 10 application instances/pod to be running (assuming 0 ds) and would still be leaving 75% memory unused

C without doubts

C – 1. Create GKE cluster with n1-standard-1 type machine. 2. Build a docker image from production branch with all the dependencies and tag it with version #. 3. Create a Kubernetes Deployment with the imagePullPolicy set to “IfNotPresent” in the staging namespace, and then promote it to production namespace after testing. Pretty interesting questions, where all options physically work, though C corresponds mostly to all requirements. First of all why GKE, but not GCE? Because, GKE can better utilize resources (pods autoscaling on the same node), and also it has advanced dashboard for resource utilization. Also, GKE abstracts you from VM/OS – focus just on app. Then C or D? C - follows Kubernetes best practices (uses normal image version #, instead of marking as "latest"), and also image is deployed automatically by node agent (kubelet), after test is passed in staging env (Google Best practice). In D version is marked as latest , which would sophisticate roll-back process. In Addition with “Always” policy you need to restart pods manually to deploy new version. upvoted 7 times

C. Perform the following: 1. Create a Google Kubernetes Engine (GKE) cluster with n1-standard-1 type machines. 2. Build a Docker image from the production branch with all of the dependencies, and tag it with the version number. 3. Create a Kubernetes Deployment with the imagePullPolicy set to 'IfNotPresent' in the staging namespace, and then promote it to the production namespace after testing. This option provides the best solution for monitoring and maximizing machine utilization and reliably deploying new versions of the application. Using a GKE cluster allows you to take advantage of Kubernetes' features for scaling, rolling updates, and self-healing. Additionally, building a Docker image with all dependencies ensures a consistent environment, and promoting from the staging namespace to the production namespace after testing ensures that new releases are reliable.

-> B This option is the best solution because it satisfies the requirements mentioned in the question. A managed instance group with n1-standard-1 type machines is a good choice for a Python web application with many dependencies that require 0.1 CPU cores and 128 MB of memory to operate in production. Building a Compute Engine image with all the dependencies and automatically starting the Python app simplifies the deployment process, and allows for consistent and reliable deployment of new versions. Rebuilding the Compute Engine image and updating the instance template to deploy new production releases ensures that the latest version is always deployed. Additionally, monitoring can be done using Stackdriver Monitoring to maximize machine utilization.