DRAG DROP
You administer an Azure Web Site named contosoweb that uses a production database.
You deploy changes to contosoweb from a deployment slot named contosoweb-staging.
You discover issues in contosoweb that are affecting customer data.
You need to resolve the issues in contosoweb while ensuring minimum downtime for users.
You swap contosoweb to contosoweb-staging.
Which four steps should you perform next in sequence? To answer, move the appropriate
actions from the list of actions to the answer area and arrange them in the correct order.
Answer: 
Explanation:
is the above answer is correct 😀
Correct
Anyone appeared for 70-534?
http://blog.amitapple.com/post/2014/11/azure-websites-slots/#.Vao02Xkw9eU
I think on can consider that after swapping contosoweb point to production data base
so the answer is correct. The production is always on the production database
this question is becoming tricky because now we can use the portal to decide wether a parameter or a connection string sticks to the slot
previously it was only possible from Powershell
So we could also discuss about a solution like:
6
5
1
I am going to agree with Fred. The question says “You swap contosoweb to contosoweb-staging. Which four steps should you perform next in sequence?”
I would believe that is you already swap the two, pointing contosoweb-staging to test would indicate that the customers would be using the “test” database in production.
If the deployment and staging slots are swap, wouldn’t the next step be to point contosoweb-staging to production?
I have:
Point contosoweb-staging
Fix
Swap
Point contosoweb
Point contosoweb-staging to the test database
Fix the issues in contosoweb-staging
point contosoweb-staging to the production database
Swap contosoweb-staging to contosoweb
“You discover issues in contosoweb that are affecting customer data. You swap contosoweb to contosoweb-staging”
Contosoweb is now contosoweb-staging. this means that staging is STILL connected to the production database, since swapping slots does not change such connections. That is why we point staging to the test database first, to prevent anymore damage to customer data
We then fix staging
We point staging back to the production database because again, swapping slots does not change DB connections
Swap staging back to contosoweb.
You cannot swap slots before you switch back to production because that would cause downtime as contosoweb would still be connected to the test DB.
SDS +1
To prevent anymore damage to customer data, we shouldn’t point the production instance (contosoweb-staging) to test database. Test database has test data. Why would production users want to see test data at all? That, in other words, is disruption.
The trick here is that the rollback has already been done… mentioned as (culprit causing all the confusion)- “You swap contosoweb to contosoweb-staging”. This means that the earlier (working) version is now Live (contosoweb-staging). And the Staging slot has the faulty version (contosoweb) that needs fixing.
Although the answer and SDS’ steps are the same and seem correct, I don’t agree to the explanation that SDS put in.
We are not (and should not be) doing this- “prevent anymore damage to customer data”.
While I have to go with the answer provided, my question still is- will we be able to fix the issue with test data? It could lead to the classic “works for me” excuse right?
SDS is right:
1) Point contosoweb-staging to the test database
2) Fix the issues in contosoweb-staging
3) point contosoweb-staging to the production database (point first, then swap)
4) Swap contosoweb-staging to contosoweb (so now any immediate traffic on prod is going to prod database)
Hi Rob,
Do you have latest Dumps 70-533.
Hey Jack…
Send your email.
Mine is [email protected]
Hi,
May I have the latest DUMO too?
Thanks.
my email:
[email protected]
Change of heart. I see the hook here (there’s always a hook in these questions): When you swap slots in a web app, the connection string get swapped with it. Their testing you to see if you know that. (https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/ under Settings that are swapped).
Since we just swapped prod back to stag (in order to fix), we need to…
1) Point prod to the prod database (as it is pointing to stag db)
2) Point stag to the stag database (as it is pointing to prod db)
3) Fix stag
4) Re-swap
(And then reset the connection string in each)
Thoughts?
I believe this answer is more correct than the other “correct” answer. However, a fifth step of pointing contosoweb to prod is needed to complete the re-deployment (because it was last pointing to test).
my understanding:
so, you need first point the staging to the test database.
the question says that you have swap contosoweb to constoweb-staging, so, unless you have “sticky” selected the connection strings will also be replaced.
fixing the issues are the next step.
then, before doing the swap, we need to change again the conn string (no sticky).
Finally, do the swap.
Only two steps are required if the connection strings are slot settings.
Fix the issue in contosoweb_staging.
Swap contosoweb-staging to contosoweb.
If they are not slot settings (which I do not think), we need following –
Point contosoweb to the production database.
point contosoweb-staging to the test database.
fix the issue in contosoweb-staging.
point contosoweb-staging to the production database.
swap contosoweb-staging to contosoweb.
again
point contosoweb-staging to the test database.
I strongly feel that the connection strings will be slot settings. Hence I go with first set of answers.