diff --git a/cluster/gce/windows/README-GCE-Windows-kube-up.md b/cluster/gce/windows/README-GCE-Windows-kube-up.md
index f28d80d5bce..54ed28ba130 100644
--- a/cluster/gce/windows/README-GCE-Windows-kube-up.md
+++ b/cluster/gce/windows/README-GCE-Windows-kube-up.md
@@ -20,11 +20,6 @@ Then, optionally clean/prepare your environment using these commands:
 # Remove files that interfere with get-kube / kube-up:
 rm -rf ./kubernetes/; rm -f kubernetes.tar.gz; rm -f ~/.kube/config
 
-# Set the default gcloud project for this shell. This is optional but convenient
-# if you're working with multiple projects and don't want to repeatedly switch
-# between gcloud config configurations.
-export CLOUDSDK_CORE_PROJECT=<your_project_name>
-
 # To run e2e test locally, make sure "Application Default Credentials" is set in any of the places:
 # References: https://cloud.google.com/sdk/docs/authorizing#authorizing_with_a_service_account
 #             https://cloud.google.com/sdk/gcloud/reference/auth/application-default/
@@ -37,8 +32,8 @@ export GOOGLE_APPLICATION_CREDENTIAL=[path_to_the_json_file]
 
 ### 1. Build Kubernetes
 
-NOTE: this step is only needed if you want to test local changes you made to
-the codebase.
+NOTE: this step is only needed if you want to test local changes you made to the
+codebase.
 
 The most straightforward approach to build those binaries is to run `make
 release`. However, that builds binaries for all supported platforms, and can be
@@ -54,7 +49,12 @@ KUBE_BUILD_PLATFORMS="linux/amd64 windows/amd64" make quick-release
 
 You can create a regular Kubernetes cluster or an end-to-end test cluster.
 
-Only end-to-end test clusters support running the Kubernetes e2e tests (as both [e2e cluster creation](https://github.com/kubernetes/kubernetes/blob/b632eaddbaad9dc1430d214d506b72750bbb9f69/hack/e2e-internal/e2e-up.sh#L24) and [e2e test scripts](https://github.com/kubernetes/kubernetes/blob/b632eaddbaad9dc1430d214d506b72750bbb9f69/hack/ginkgo-e2e.sh#L42) are setup based on `cluster/gce/config-test.sh`), also enables some debugging features such as SSH access on the Windows nodes.
+Only end-to-end test clusters support running the Kubernetes e2e tests (as both
+[e2e cluster creation](https://github.com/kubernetes/kubernetes/blob/b632eaddbaad9dc1430d214d506b72750bbb9f69/hack/e2e-internal/e2e-up.sh#L24)
+and
+[e2e test scripts](https://github.com/kubernetes/kubernetes/blob/b632eaddbaad9dc1430d214d506b72750bbb9f69/hack/ginkgo-e2e.sh#L42)
+are setup based on `cluster/gce/config-test.sh`), also enables some debugging
+features such as SSH access on the Windows nodes.
 
 Please make sure you set the environment variables properly following the
 instructions in the previous section.
@@ -78,38 +78,56 @@ Now bring up a cluster using one of the following two methods:
 
 #### 2a. Create a regular Kubernetes cluster
 
+Ensure your GCP authentication is current:
+
 ```bash
-# Invoke kube-up.sh with these environment variables:
-#   PROJECT: text name of your GCP project.
-#   WINDOWS_NODE_OS_DISTRIBUTION: the Windows version you want your nodes to
-#     run, e.g. win2019 or win1909.
-#   KUBE_UP_AUTOMATIC_CLEANUP (optional): cleans up existing cluster without
-#     prompting.
-PROJECT=${CLOUDSDK_CORE_PROJECT} WINDOWS_NODE_OS_DISTRIBUTION=win2019 \
-  KUBE_UP_AUTOMATIC_CLEANUP=true ./cluster/kube-up.sh
+gcloud auth application-default login
+gcloud auth login
 ```
 
+Invoke kube-up.sh with these environment variables:
+
+```bash
+# WINDOWS_NODE_OS_DISTRIBUTION: the Windows version you want your nodes to
+#   run, e.g. win2019 or win1909.
+# KUBE_UP_AUTOMATIC_CLEANUP (optional): cleans up existing cluster without
+#   prompting.
+WINDOWS_NODE_OS_DISTRIBUTION=win2019 KUBE_UP_AUTOMATIC_CLEANUP=true ./cluster/kube-up.sh
+```
+
+If your GCP project is configured with two-factor authentication, you may need
+to tap your security key shortly after running `kube-up`.
+
 To teardown the cluster run:
 
 ```bash
-PROJECT=${CLOUDSDK_CORE_PROJECT} ./cluster/kube-down.sh
+./cluster/kube-down.sh
 ```
 
+If you want to run more than one cluster simultaneously, you can use two
+separate GCP projects and:
+
+1.  Use a separate shell for each project / cluster.
+1.  Set the `CLOUDSDK_CORE_PROJECT` environment variable to the GCP project you
+    want to use in each shell. This variable will override your current gcloud
+    config.
+1.  Prefix your `kube-up.sh` and `kube-down.sh` commands with
+    `PROJECT=${CLOUDSDK_CORE_PROJECT}`
+
 #### 2b. Create a Kubernetes end-to-end (E2E) test cluster
 
 If you have built your own release binaries following step 1, run the following
 command:
 
 ```bash
-PROJECT=${CLOUDSDK_CORE_PROJECT} WINDOWS_NODE_OS_DISTRIBUTION=win2019 \
-  ./hack/e2e-internal/e2e-up.sh
+WINDOWS_NODE_OS_DISTRIBUTION=win2019 ./hack/e2e-internal/e2e-up.sh
 ```
 
 If any e2e cluster exists already, this command will prompt you to tear down and
 create a new one. To teardown existing e2e cluster only, run the command:
 
 ```bash
-PROJECT=${CLOUDSDK_CORE_PROJECT} ./hack/e2e-internal/e2e-down.sh
+./hack/e2e-internal/e2e-down.sh
 ```
 
 No matter what type of cluster you chose to create, the result should be a
@@ -135,14 +153,14 @@ If you brought up an end-to-end test cluster using the steps above then you can
 use the steps below to run K8s e2e tests. These steps are based on
 [kubernetes-sigs/windows-testing](https://github.com/kubernetes-sigs/windows-testing).
 
-* Build the necessary test binaries. This must be done after every change to
+*   Build the necessary test binaries. This must be done after every change to
     test code.
 
     ```bash
     make WHAT=test/e2e/e2e.test
     ```
 
-* Set necessary environment variables and fetch the `run-e2e.sh` script:
+*   Set necessary environment variables and fetch the `run-e2e.sh` script:
 
     ```bash
     export KUBECONFIG=~/.kube/config
@@ -158,9 +176,9 @@ use the steps below to run K8s e2e tests. These steps are based on
     NOTE: `run-e2e.sh` begins with a 5 minute sleep to wait for container images
     to be pre-pulled. You'll probably want to edit the script and remove this.
 
-* The canonical arguments for running all Windows e2e tests against a cluster
-    on GCE can be seen by searching for `--test-cmd-args` in the [test
-    configuration](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-windows/windows-gce.yaml#L78)
+*   The canonical arguments for running all Windows e2e tests against a cluster
+    on GCE can be seen by searching for `--test-cmd-args` in the
+    [test configuration](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-windows/windows-gce.yaml#L78)
     for the `ci-kubernetes-e2e-windows-gce` continuous test job. These arguments
     should be passed to the `run-e2e` script; escape the ginkgo arguments by
     adding quotes around them. For example:
@@ -171,7 +189,7 @@ use the steps below to run K8s e2e tests. These steps are based on
       --ginkgo.skip="\[LinuxOnly\]|\[Serial\]|\[Feature:.+\]" --minStartupPods=8
     ```
 
-* Run a single test by setting the ginkgo focus to match your test name; for
+*   Run a single test by setting the ginkgo focus to match your test name; for
     example, the "DNS should provide DNS for the cluster" test can be run using:
 
     ```bash
@@ -187,6 +205,6 @@ directory.
 
 ## E2E Testing
 
-Once you've created a pull request you can comment,
-`/test pull-kubernetes-e2e-windows-gce` to run the integration tests that cover
-the changes in this directory.
+Once you've created a pull request you can comment, `/test
+pull-kubernetes-e2e-windows-gce` to run the integration tests that cover the
+changes in this directory.