Fix em-dash usage

Author: Rob-Barefoot

learn-pr/wwl-azure/guided-project-share-files-securely/includes/1-introduction.md

@@ -1,10 +1,10 @@
 This guided project focuses on sharing files securely using Azure Blob Storage, shared access signatures (SAS), and lifecycle management.
 
-A shared access signature (SAS) is a token that grants temporary, scoped access to a blob or container without sharing your storage account keys. When you generate a SAS from a stored access policy, the policy acts as a central control point — you can revoke all linked tokens instantly by deleting the policy.
+A shared access signature (SAS) is a token that grants temporary, scoped access to a blob or container without sharing your storage account keys. When you generate a SAS from a stored access policy, the policy acts as a central control point—you can revoke all linked tokens instantly by deleting the policy.
 
 ## Scenario
 
-Your internal finance team needs to share monthly reports with an external partner for a short review window. You upload the report to a private container, set up a stored access policy, generate a SAS link from that policy, and then test both sides of the access model — confirming the partner can access the file with the SAS while anonymous access stays blocked. When the review is complete, you revoke access by deleting the policy and configure a lifecycle rule to automatically clean up shared files.
+Your internal finance team needs to share monthly reports with an external partner for a short review window. You upload the report to a private container, set up a stored access policy, generate a SAS link from that policy, and then test both sides of the access model—confirming the partner can access the file with the SAS while anonymous access stays blocked. When the review is complete, you revoke access by deleting the policy and configure a lifecycle rule to automatically clean up shared files.
 
 - Exercise 1 - Create a storage account, private container, and upload a file.
 - Exercise 2 - Create a stored access policy and generate a SAS link.

learn-pr/wwl-azure/guided-project-share-files-securely/includes/2-exercise-create-storage-upload-file.md

@@ -53,7 +53,7 @@ Set up the foundation for blob storage. The storage account holds your blob cont
 > **Validation step:** Verify the storage account is deployed. Confirm the storage account name and region match your configuration.
 
 > [!NOTE]
-> Each exercise includes validation steps like this one. Track your results as you go — you'll review them all in the validation unit at the end of this module.
+> Each exercise includes validation steps like this one. Track your results as you go—you'll review them all in the validation unit at the end of this module.
 
 ## Task 3: Create the private container
 

learn-pr/wwl-azure/guided-project-share-files-securely/includes/3-exercise-create-access-policy.md

@@ -6,7 +6,7 @@ This guided project consists of the following exercises:
  - Revoke partner access
  - Configure lifecycle management
 
-In this exercise, you create a stored access policy on the container and generate a SAS URL from it. The stored access policy acts as a control point — if you need to revoke access later, you can delete the policy instead of tracking down individual tokens.
+In this exercise, you create a stored access policy on the container and generate a SAS URL from it. The stored access policy acts as a control point—if you need to revoke access later, you can delete the policy instead of tracking down individual tokens.
 
 This exercise includes the following tasks:
 
@@ -15,7 +15,7 @@ This exercise includes the following tasks:
 
 **Outcome:** A stored access policy on the container and a SAS URL generated from that policy.
 
-Instead of generating a one-off SAS token with its own permissions and expiry, you'll create a **stored access policy** first. A stored access policy defines the rules (permissions and expiry) at the container level. Any SAS token generated from that policy inherits those rules — and if you delete the policy later, every SAS token linked to it is instantly revoked. This is the enterprise approach to SAS management.
+Instead of generating a one-off SAS token with its own permissions and expiry, you'll create a **stored access policy** first. A stored access policy defines the rules (permissions and expiry) at the container level. Any SAS token generated from that policy inherits those rules—and if you delete the policy later, every SAS token linked to it is instantly revoked. This is the enterprise approach to SAS management.
 
 ## Task 1: Create a stored access policy
 
@@ -55,7 +55,7 @@ Now generate a SAS token that inherits its rules from the policy you just create
 9.  Copy the **Blob SAS URL** and save it securely. You'll use this URL in the next exercise.
 
 > [!NOTE]
-> Notice that the **Permissions** and **Expiry** fields are grayed out — they're controlled by the policy, not set individually. This is the key advantage: all tokens share the same rules, and revoking the policy revokes them all.
+> Notice that the **Permissions** and **Expiry** fields are grayed out—they're controlled by the policy, not set individually. This is the key advantage: all tokens share the same rules, and revoking the policy revokes them all.
 
 > [!NOTE]
 > **Validation step:** Confirm the SAS URL is generated and the permissions came from the stored access policy.

learn-pr/wwl-azure/guided-project-share-files-securely/includes/4-exercise-test-partner-access.md

@@ -6,7 +6,7 @@ This guided project consists of the following exercises:
  - Revoke partner access
  - Configure lifecycle management
 
-In this exercise, you test both sides of the access model — first confirming that direct access is blocked, then verifying that the SAS URL grants access to the file. This demonstrates the security boundary between public access and token-based access.
+In this exercise, you test both sides of the access model—first confirming that direct access is blocked, then verifying that the SAS URL grants access to the file. This demonstrates the security boundary between public access and token-based access.
 
 This exercise includes the following tasks:
 
@@ -39,7 +39,7 @@ Now verify that the policy-based SAS token grants access to the same file that w
 1.  In the same incognito window, paste the SAS URL into the address bar and press **Enter**.
 2.  Confirm the file content displays in the browser. Because this is a text file, the browser renders it directly instead of downloading it.
 3.  Note that you are not signed in but still have access due to the SAS token.
-4.  Keep this incognito window open — you'll use it again in the next exercise.
+4.  Keep this incognito window open—you'll use it again in the next exercise.
 
 > [!NOTE]
 > **Validation step:** Confirm the SAS URL displays the file content from the same unauthenticated incognito session that was just denied direct access.

learn-pr/wwl-azure/guided-project-share-files-securely/includes/5-exercise-revoke-access.md

@@ -6,7 +6,7 @@ This guided project consists of the following exercises:
  - **Revoke partner access**
  - Configure lifecycle management
 
-In this exercise, you revoke the partner's access by deleting the stored access policy. This instantly invalidates all SAS tokens generated from the policy — even those that haven't expired yet. You then confirm the file itself is still safely stored.
+In this exercise, you revoke the partner's access by deleting the stored access policy. This instantly invalidates all SAS tokens generated from the policy—even those that haven't expired yet. You then confirm the file itself is still safely stored.
 
 This exercise includes the following tasks:
 
@@ -17,7 +17,7 @@ This exercise includes the following tasks:
 
 **Outcome:** Deleting the stored access policy instantly revokes all SAS tokens generated from it.
 
-The partner has finished reviewing the file. Instead of waiting for the SAS token to expire on its own, you'll revoke access immediately by deleting the stored access policy. Every SAS token linked to that policy stops working the moment the policy is deleted — even if the token's expiry time hasn't passed yet.
+The partner has finished reviewing the file. Instead of waiting for the SAS token to expire on its own, you'll revoke access immediately by deleting the stored access policy. Every SAS token linked to that policy stops working the moment the policy is deleted—even if the token's expiry time hasn't passed yet.
 
 ## Task 1: Confirm SAS still works
 
@@ -51,7 +51,7 @@ Remove the policy to instantly revoke all SAS tokens that were generated from it
 
 ## Task 3: Verify access is revoked
 
-Test the same SAS URL to confirm it no longer works — even though the token's expiry time hasn't passed.
+Test the same SAS URL to confirm it no longer works—even though the token's expiry time hasn't passed.
 
 1.  Return to the incognito window.
 2.  Refresh the SAS URL.
@@ -62,14 +62,14 @@ Test the same SAS URL to confirm it no longer works — even though the token's
 
 ## Task 4: Confirm the file still exists
 
-Verify that revoking SAS access only removed the external pathway — the file itself is untouched.
+Verify that revoking SAS access only removed the external pathway—the file itself is untouched.
 
 1.  Return to the Azure portal in your main browser window.
 2.  Navigate to the **partner-drop** container.
 3.  Confirm **monthly-report.txt** still exists in the container.
 4.  Close the incognito window.
 
 > [!NOTE]
-> **Validation step:** The file remains in the container. Revoking SAS access doesn't delete data — it only removes the access pathway.
+> **Validation step:** The file remains in the container. Revoking SAS access doesn't delete data—it only removes the access pathway.
 
 > [!NOTE]

learn-pr/wwl-azure/guided-project-share-files-securely/includes/7-validate-success.md

@@ -8,8 +8,8 @@ Review the validation steps you completed during the exercises. Confirm that eac
 -   [ ] The SAS URL is generated from the stored access policy (permissions inherited, not set manually).
 -   [ ] The direct URL (without SAS token) is denied from an unauthenticated incognito session.
 -   [ ] The SAS URL displays the file content from the same unauthenticated session.
--   [ ] After deleting the stored access policy, the SAS URL is instantly denied — even before the token's expiry time.
--   [ ] The file still exists in the container after access is revoked — only the access pathway was removed.
+-   [ ] After deleting the stored access policy, the SAS URL is instantly denied—even before the token's expiry time.
+-   [ ] The file still exists in the container after access is revoked—only the access pathway was removed.
 -   [ ] A lifecycle management rule named **delete-shared-files** is configured to delete blobs in **partner-drop/** after 30 days.
 
 If any item is not true, return to the relevant exercise and troubleshoot before continuing.

learn-pr/wwl-azure/guided-project-share-files-securely/includes/unused/6-validate-success.md

@@ -8,7 +8,7 @@ Review the validation steps you completed during the exercises. Confirm that eac
 -   [ ] The direct URL (without SAS token) is denied from an unauthenticated incognito session.
 -   [ ] The SAS URL displays the file content from the same unauthenticated session.
 -   [ ] The expired SAS URL returns an authorization error after the expiry time passes.
--   [ ] The file still exists in the container after SAS expiry — only external access was revoked.
+-   [ ] The file still exists in the container after SAS expiry—only external access was revoked.
 -   [ ] The **partner-upload** container is created with **Private** access level.
 -   [ ] A write-only SAS is generated with only **Write** and **Create** permissions.
 -   [ ] A file is uploaded via Cloud Shell using the write SAS URL.