Updated alt text values

Author: Ratulac-Azure

articles/spring-apps/basic-standard/how-to-appdynamics-java-agent-monitor.md

@@ -44,7 +44,7 @@ For the whole workflow, you need to:
 * Activate the AppDynamics Java in-process agent in Azure Spring Apps to generate application metrics data.
 * Connect the AppDynamics Agent to the AppDynamics Controller to collect and visualize the data in the controller.
 
-:::image type="content" source="media/how-to-appdynamics-java-agent-monitor/appdynamics-activation.jpg" alt-text="Diagram showing a Spring Boot application in 'Azure Spring Apps' box with a two-directional arrow connecting it to an 'AppDynamics Agent' box, which also has an arrow pointing to an 'AppDynamics Controller' box" lightbox="media/how-to-appdynamics-java-agent-monitor/appdynamics-activation.jpg":::
+:::image type="content" source="media/how-to-appdynamics-java-agent-monitor/appdynamics-activation.jpg" alt-text="Diagram that shows a Spring Boot application in Azure Spring Apps box." lightbox="media/how-to-appdynamics-java-agent-monitor/appdynamics-activation.jpg":::
 
 ### Activate an application with the AppDynamics Agent using the Azure CLI
 

articles/spring-apps/basic-standard/quickstart-logs-metrics-tracing.md

@@ -161,15 +161,15 @@ To get the logs using Azure Toolkit for IntelliJ:
 
 1. Select **Streaming Logs** from the drop-down list.
 
-   :::image type="content" source="media/quickstart-logs-metrics-tracing/streaming-logs.png" alt-text="Select streaming logs" lightbox="media/quickstart-logs-metrics-tracing/streaming-logs.png":::
+   :::image type="content" source="media/quickstart-logs-metrics-tracing/streaming-logs.png" alt-text="Screenshot of the Azure portal that shows the Streaming Logs option highlighted." lightbox="media/quickstart-logs-metrics-tracing/streaming-logs.png":::
 
 1. Select **Instance**.
 
-   :::image type="content" source="media/quickstart-logs-metrics-tracing/select-instance.png" alt-text="Select instance" lightbox="media/quickstart-logs-metrics-tracing/select-instance.png":::
+   :::image type="content" source="media/quickstart-logs-metrics-tracing/select-instance.png" alt-text="Screenshot of the Azure portal that shows the Select Instance option." lightbox="media/quickstart-logs-metrics-tracing/select-instance.png":::
 
 1. The streaming log is visible in the output window.
 
-   :::image type="content" source="media/quickstart-logs-metrics-tracing/streaming-log-output.png" alt-text="Streaming log output" lightbox="media/quickstart-logs-metrics-tracing/streaming-log-output.png":::
+   :::image type="content" source="media/quickstart-logs-metrics-tracing/streaming-log-output.png" alt-text="Screenshot of the Azure portla that shows the Streaming Log output window." lightbox="media/quickstart-logs-metrics-tracing/streaming-log-output.png":::
 
  To learn more about the query language that's used in Log Analytics, see [Azure Monitor log queries](/azure/data-explorer/kusto/query/). To query all your Log Analytics logs from a centralized client, check out [Azure Data Explorer](/azure/data-explorer/query-monitor-data).
 

articles/spring-apps/enterprise/concepts-blue-green-deployment-strategies.md

@@ -30,27 +30,27 @@ Suppose your application has two deployments: `deployment1` and `deployment2`. C
 
 This makes `deployment2` the staging deployment. Thus, when the Continuous Delivery (CD) pipeline is ready to run, it deploys the next version of the app, version `v4`, onto the staging deployment `deployment2`.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-1.png" alt-text="Two deployments: deployment1 receives production traffic" lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-1.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-1.png" alt-text="Diagram that shows deployment1 receiving production traffic." lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-1.png":::
 
 After `v4` has started up on `deployment2`, you can run automated and manual tests against it through a private test endpoint to ensure `v4` meets all expectations.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-2.png" alt-text="V4 is now deployed on deployment2 and undergoes testing" lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-2.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-2.png" alt-text="Diagram that shows V4 deployed on deployment2 and undergoing testing." lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-2.png":::
 
 When you have confidence in `v4`, you can set `deployment2` as the production deployment so that it receives all production traffic. `v3` will remain running on `deployment1` in case you discover a critical issue that requires rolling back.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-3.png" alt-text="V4 on deployment2 now receives production traffic" lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-3.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-3.png" alt-text="Diagram that shows V4 on deployment2 receiving production traffic." lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-3.png":::
 
 Now, `deployment1` is the staging deployment. So the next run of the deployment pipeline deploys onto `deployment1`.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-4.png" alt-text="V5 deployed on deployment1" lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-4.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-4.png" alt-text="Diagram that shows V5 deployed on deployment1." lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-4.png":::
 
 You can now test `V5` on `deployment1`'s private test endpoint.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-5.png" alt-text="V5 tested on deployment1" lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-5.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-5.png" alt-text="Diagram that shows V5 tested on deployment1." lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-5.png":::
 
 Finally, after `v5` meets all your expectations, you set `deployment1` as the production deployment once again, so that `v5` receives all production traffic.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-6.png" alt-text="V5 receives traffic on deployment1" lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-6.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-6.png" alt-text="Diagram that shows V5 receiving traffic on deployment1." lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-6.png":::
 
 ### Tradeoffs of the alternating deployments approach
 
@@ -64,7 +64,7 @@ The staging deployment always remains running, and thus consuming resources of t
 
 Suppose in the above application, the release pipeline requires manual approval before each new version of the application can receive production traffic. This creates the risk that while one version (`v6`) awaits manual approval on the staging deployment, the deployment pipeline will run again and overwrite it with a newer version (`v7`). Then, when the approval for `v6` is granted, the pipeline that deployed `v6` will set the staging deployment as production. But now it will be the unapproved `v7`, not the approved `v6`, that is deployed on that deployment and receives traffic.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-race-condition.png" alt-text="The approval race condition" lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-race-condition.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-race-condition.png" alt-text="Diagram that shows the approval race condition." lightbox="media/concepts-blue-green-deployment-strategies/alternating-deployments-race-condition.png":::
 
 You may be able to prevent the race condition by ensuring that the deployment flow for one version can't begin until the deployment flow for all previous versions is complete or aborted. Another way to prevent the approval race condition is to use the Named Deployments approach described below.
 
@@ -74,15 +74,15 @@ In the named deployments approach, a new deployment is created for each new vers
 
 In the illustration below, version `v5` is running on the deployment `deployment-v5`. The deployment name now contains the version because the deployment was created specifically for this version. There's no other deployment at the outset. Now, to deploy version `v6`, the deployment pipeline creates a new deployment `deployment-v6` and deploys app version `v6` there.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-1.png" alt-text="Deploying new version on a named deployment" lightbox="media/concepts-blue-green-deployment-strategies/named-deployment-1.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-1.png" alt-text="Diagram that shows deployment of a new version on a named deployment." lightbox="media/concepts-blue-green-deployment-strategies/named-deployment-1.png":::
 
 There's no risk of another version being deployed in parallel. First, Azure Spring Apps doesn't allow the creation of a third deployment while two deployments already exist. Second, even if it was possible to have more than two deployments, each deployment is identified by the version of the application it contains. Thus, the pipeline orchestrating the deployment of `v6` would only attempt to set `deployment-v6` as the production deployment.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-2.png" alt-text="New version receives production traffic named deployment" lightbox="media/concepts-blue-green-deployment-strategies/named-deployment-2.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-2.png" alt-text="Diagram that shows a new version receiving production traffic named deployment." lightbox="media/concepts-blue-green-deployment-strategies/named-deployment-2.png":::
 
 After the deployment created for the new version receives production traffic, you'll need to remove the deployment containing the previous version to make room for future deployments. You may wish to postpone by some number of minutes or hours so you can roll back to the previous version if you discover a critical issue in the new version.
 
-:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-3.png" alt-text="After a fallback period, deleting the previous deployment" lightbox="media/concepts-blue-green-deployment-strategies/named-deployment-3.png":::
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-3.png" alt-text="Diagram that shows that after a fallback period, the previous deployment is deleted." lightbox="media/concepts-blue-green-deployment-strategies/named-deployment-3.png":::
 
 ### Tradeoffs of the named deployments approach
 

articles/spring-apps/enterprise/github-actions-key-vault.md

@@ -56,11 +56,11 @@ The credential you created above can get only general information about the Key
 
 Go to the **Key Vault** dashboard in Azure portal, select the **Access control** menu, then open the **Role assignments** tab. Select **Apps** for **Type** and `This resource` for **scope**.  You should see the credential you created in previous step:
 
-:::image type="content" source="media/github-actions-key-vault/key-vault1.png" alt-text="Set access policy" lightbox="media/github-actions-key-vault/key-vault1.png":::
+:::image type="content" source="media/github-actions-key-vault/key-vault1.png" alt-text="Screenshot of the Azure portal that shows the Access control page with the Role assignmnets highlighted." lightbox="media/github-actions-key-vault/key-vault1.png":::
 
 Copy the credential name, for example, `azure-cli-2020-01-19-04-39-02`. Open the **Access policies** menu, then select the **Add Access Policy** link.  Select `Secret Management` for **Template**, then select **Principal**. Paste the credential name in **Principal**/**Select** input box:
 
-:::image type="content" source="media/github-actions-key-vault/key-vault2.png" alt-text="Select" lightbox="media/github-actions-key-vault/key-vault2.png":::
+:::image type="content" source="media/github-actions-key-vault/key-vault2.png" alt-text="Screenshot of the Azure portal that shows the Add access policies page." lightbox="media/github-actions-key-vault/key-vault2.png":::
 
 Select the **Add** button in the **Add access policy** dialog, then select **Save**.
 
@@ -90,7 +90,7 @@ Again, results:
 
 Copy the entire JSON string.  Go back to **Key Vault** dashboard. Open the **Secrets** menu, then select the **Generate/Import** button. Input the secret name, such as `AZURE-CREDENTIALS-FOR-SPRING`. Paste the JSON credential string to the **Value** input box. You may notice the value input box is a one-line text field, rather than a multi-line text area.  You can paste the complete JSON string there.
 
-:::image type="content" source="media/github-actions-key-vault/key-vault3.png" alt-text="Full scope credential" lightbox="media/github-actions-key-vault/key-vault3.png":::
+:::image type="content" source="media/github-actions-key-vault/key-vault3.png" alt-text="Screenshot of the Azure portal that shows the Create a secret page." lightbox="media/github-actions-key-vault/key-vault3.png":::
 
 ## Combine credentials in GitHub Actions
 

articles/spring-apps/enterprise/how-to-circuit-breaker-metrics.md

@@ -216,7 +216,7 @@ Use the following steps to build and deploy the sample applications.
 
 1. Set **Metric** to **resilience4j_circuitbreaker_calls**, and then set **Aggregation** to **Avg**. Select **Add metric** and set **Metric** to **resilience4j_circuitbreaker_buffered_calls**, and then set **Aggregation** to **Avg**. Select **Add metric** again and set **Metric** to **resilience4j_circuitbreaker_slow_calls**, and then set **Aggregation** set to **Avg**.
 
-   :::image type="content" source="media/how-to-circuit-breaker-metrics/slow-calls.png" alt-text="Screenshot of the Azure portal Application Insights Metrics page that shows three charts: A chart with Metric set to circuit breaker calls and Aggregation set to Average. A chart with Metric set to circuit breaker calls buffered and Aggregation set to Average. A chart with Metric set to circuit breaker slow calls  and Aggregation set to Average." lightbox="media/how-to-circuit-breaker-metrics/slow-calls.png":::
+   :::image type="content" source="media/how-to-circuit-breaker-metrics/slow-calls.png" alt-text="Screenshot of the Azure portal that shows the Application Insights Metrics page with a chart as mentioned in the process step." lightbox="media/how-to-circuit-breaker-metrics/slow-calls.png":::
 
 ::: zone-end
 
@@ -253,7 +253,7 @@ Use the following steps to build and deploy the sample applications.
 
 1. Set **Metric** to **resilience4j_circuitbreaker_calls**, and then set **Aggregation** to **Avg**. Select **Add metric** and set **Metric** to **resilience4j_circuitbreaker_buffered_calls**, and then set **Aggregation** to **Avg**. Select **Add metric** again and set **Metric** to **resilience4j_circuitbreaker_slow_calls**, and then set **Aggregation** set to **Avg**.
 
-   :::image type="content" source="media/how-to-circuit-breaker-metrics/slow-calls.png" alt-text="Screenshot of the Azure portal Application Insights Metrics page that shows three charts: A chart with Metric set to circuit breaker calls and Aggregation set to Average. A chart with Metric set to circuit breaker calls buffered and Aggregation set to Average. A chart with Metric set to circuit breaker slow calls  and Aggregation set to Average." lightbox="media/how-to-circuit-breaker-metrics/slow-calls.png":::
+   :::image type="content" source="media/how-to-circuit-breaker-metrics/slow-calls.png" alt-text="Screenshot of the Azure portal that shows the Application Insights Metrics page with a chart as mentioned in the process step." lightbox="media/how-to-circuit-breaker-metrics/slow-calls.png":::
 
 ::: zone-end
 

articles/spring-apps/enterprise/how-to-permissions.md

@@ -67,7 +67,7 @@ The Developer role includes permissions to restart apps and see their log stream
 
 1. In the search box, search for **Microsoft.app**. Select **Microsoft Azure Spring Apps**:
 
-   :::image type="content" source="media/how-to-permissions/permissions.png" alt-text="Screenshot that shows the results of searching for Microsoft.app." lightbox="media/how-to-permissions/permissions.png":::
+   :::image type="content" source="media/how-to-permissions/permissions.png" alt-text="Screenshot of the Azure portal that shows the results of searching for Microsoft.app." lightbox="media/how-to-permissions/permissions.png":::
 
 1. Select the permissions for the Developer role.
 

articles/spring-apps/enterprise/troubleshoot.md

@@ -272,7 +272,7 @@ Creating an Azure Spring Apps Enterprise plan instance fails with error code "11
 
 When you visit the SaaS offer [Azure Spring Apps Enterprise](https://aka.ms/ascmpoffer) in the Azure Marketplace, it may say "No plans are available for market '\<Location>'" as in the following image.
 
-:::image type="content" source="./media/troubleshoot/no-enterprise-plans-available.png" alt-text="No plans available error image" lightbox="./media/troubleshoot/no-enterprise-plans-available.png":::
+:::image type="content" source="./media/troubleshoot/no-enterprise-plans-available.png" alt-text="Screenshot of the Azure portal that shows the No plans are available for market error." lightbox="./media/troubleshoot/no-enterprise-plans-available.png":::
 
 The Azure Spring Apps Enterprise plan needs customers to pay for a license to Tanzu components through an Azure Marketplace offer. To purchase in the Azure Marketplace, the billing account's country or region for your Azure subscription should be in the SaaS offer's supported geographic locations.