D) and E) are pointless in this context. C) is certainly a good practice. Now between A) and B) A) Blue green deployment is an application release model that gradually transfers user traffic from a previous version of an app or microservice to a nearly identical new release—both of which are running in production. c) In software, a canary process is usually the first instance that receives live production traffic about a new configuration update, either a binary or configuration rollout. The new release only goes to the canary at first. The fact that the canary handles real user traffic is key: if it breaks, real users get affected, so canarying should be the first step in your deployment process, as opposed to the last step in testing in production. " While both green-blue and canary releases are useful, B) suggests "replacing QA" with canary releases - which is not good. QA got the issue down by 80%. Hence A) and C)

A & C for me

A & C is the correct answer

A and C, the description given by JustJack21 is all you need.

A and C

D & F for me

A is the only answer. C is a general improvement but does not guarantee the reduction of rollbacks due to quality failures if programming errors remain. B, canary only makes sense in PRO. The statement is ambiguous. In any case, if what we want is to reduce the current situation, it does not seem convenient to remove what now helps.

B. Replace the QA environment with canary releases C. Fragment the monolithic platform into microservices As splitting monolithinc application in Microservices means that code and dependencies are bundled together and DEV, TEST, QA and PROD will have same docker image. Replacing QA environment with Canary will ensure testing the final code with sub-set of users before Go-Live. There is no RollBack and no downtime. Even if testing with sub-set users fails that previous PROD deployment will continue to serve traffic. However in case of Blue-Green deployment, you will have Current PROD code and new prod code, In case new code fails post deployment, it has to be rolled-back to working code. and the ask is to reduce or eliminate Rollback.

B. Replace the QA environment with canary releases C. Fragment the monolithic platform into microservices As splitting monolithinc application in Microservices means that code and dependencies are bundled together and DEV, TEST, QA and PROD will have same docker image. Also canary release will ensure testing the final code with sub-set of users before Go-Live. Which will reduce your rollbacks. (in Blue-Green deployment, we are actually making ourself ready for rollback in case things go wrong).

Use Blue-Green to reduce rollback. Check this blog (https://circleci.com/blog/canary-vs-blue-green-downtime/#:~:text=In%20blue%2Dgreen%20deployment%20you,first%2C%20before%20finishing%20the%20others.): Using your load balancers to direct traffic keeps your blue environment running seamlessly for production users while you test and deploy to your green environment. When your deployment and testing are successful, you can switch your load balancer to target your green environment with no perceptible change for your users. When testing in Green environment, you don't perform rollback if test failed in Green.

A to validate your deployment and C to ensure that errors do not cascade across the process

A&C is correct!

I am preparing for Google Professional Cloud Architect exam. I was able to access only limited questions here, if anyone has the entire questions please share them to my email address: [email protected] . Thank you in advance!

A & C , because canery is usefull while doing the testing and once satisfied then only roll out otherwise roll back.

A and C; I don't know what canary release is. Canary is also kind of deployment method, and what do you mean canary release. This methodology will help you accerlerate your deploying many many small new features. Blue/Green would drop old deployment and create new ones, and it costs much more than other deployments. I think all the stackholder would take care of it much seriously. Microservice is for seperating a whole function to many small ones. Every team just takes care of the small ones, I think it will help make much less deployment rollback.

A C for me

A & C are the best answers