Lab 01 – Storage Accounts

Objectives

1. Create storage accounts with different redundancy/performance tiers
2. Configure access keys, SAS tokens, and network rules
3. Work with blob containers, queues, tables, and file shares
4. Move/copy data using the Portal's Storage browser

Prerequisites

1. A resource group (we'll create one)
2. Signed in at portal.azure.com

Estimated time

40 minutes

---

Part 1 – Create the resource group and storage account

Step 1: Create resource group

1. Search for Resource groups > Create
2. Name: rg-az104-lab04, Region: East US
3. Review + create > Create

Step 2: Create storage account

1. Search for Storage accounts > Create
2. Basics tab:

- Resource group: rg-az104-lab04

- Storage account name: stoaz104lab (3–24 chars, lowercase + numbers only)

- Region: East US

- Performance: Standard

- Redundancy: Locally-redundant storage (LRS)

1. Leave Advanced defaults (StorageV2, Hot tier)
2. Review + create > Create

---

Part 2 – Explore redundancy & performance options

Understanding Redundancy

| Option | Copies | Locations | Cost | Best For |

|--------|--------|-----------|------|----------|

| LRS | 3 | 1 Datacenter | $$$ | Dev/Test |

| ZRS | 3 | 3 AZs (1 region) | $$$$ | Production (regional) |

| GRS | 6 | 2 Regions | $$$$$ | Disaster recovery |

Step 1: View redundancy options

1. Open the storage account > Redundancy (under Data management)
2. Note the options: LRS, ZRS, GRS, GZRS, RA-GRS, RA-GZRS
3. Observe that changing redundancy is easy, but note the cost implications

Step 2: Understand performance tiers

1. Go to Configuration > Access tier

- Hot: Frequent access (cheapest storage, expensive per-operation)

- Cool: Infrequent access (cheaper per-operation, expensive storage)

- Archive: Long-term (cheapest storage, slow retrieval)

---

Part 3 – Containers, blobs, queues, tables, file shares

Step 1: Create and upload to blob container

1. Open the storage account > Containers (under Data storage)
2. Select + Container, name: demo-container, Public access level: Private
3. Open demo-container > Upload
4. Create a small text file locally (e.g., sample.txt with text "hello az104")
5. Upload it to the container

Step 2: Create queue and table

1. Queues (under Data storage) > + Queue, name: demo-queue
2. Tables (under Data storage) > + Table, name: demotable

Step 3: Create file share

1. File shares (under Data storage) > + File share

- Name: demo-share

- Quota: 5 GiB

- Tier: Transaction optimized

1. Create

---

Part 4 – Access keys vs SAS vs Microsoft Entra authorization

Access Patterns

| Method | Security | Use Case |

|--------|----------|----------|

| Access Keys | Full admin | Internal apps only |

| SAS | Time-limited | Temporary external access |

| Entra ID | Role-based | Production (recommended) |

Step 1: View Access Keys

1. Access keys (under Security + networking)
2. Note: two keys (key1, key2) for rotation without downtime

Step 2: Generate SAS token

1. Shared Access Signature (under Security + networking)
2. Allowed services: Blob
3. Allowed resource types: Container, Object
4. Allowed permissions: Read
5. Start and expiry time: set expiry to 1 hour from now
6. Allowed protocols: HTTPS only
7. Select Generate SAS and connection string
8. Copy the Blob SAS URL

Step 3: Test SAS access

1. Construct the full URL:

https://<account>.blob.core.windows.net/demo-container/sample.txt?<sas-token>
``

Open in browser—you should download sample.txt

After 1 hour, this URL will expire and access will fail


> Tip: SAS tokens are great for temporary sharing. Generate new ones for each user/device to minimize blast radius if leaked.

<h3 id="step-4-test-entra-id-access-">Step 4: Test Entra ID access
</h3>

Go to the storage account > <strong>Access control (IAM)</strong> > <strong>Add role assignment</strong>

<strong>Role</strong>: <strong>Storage Blob Data Reader</strong>

<strong>Assign to</strong>: your user account

Open <strong>Containers</strong> > demo-container

In the top toolbar, switch <strong>Authentication method</strong> from <strong>Access key</strong> to <strong>Microsoft Entra user account</strong>

Confirm you can still view sample.txt


> Important: This uses your Entra identity + RBAC instead of account keys. This is the most secure approach for production.

---

<h2 id="part-5-network-rules-">Part 5 – Network rules
</h2>

<h3 id="restricting-access-">Restricting Access
</h3>

> Warning: Network rules can lock you out if misconfigured. Always test before deploying to production.

<h3 id="step-1-enable-network-rules-">Step 1: Enable network rules
</h3>

<strong>Networking</strong> (under <strong>Security + networking</strong>)

<strong>Public network access</strong>: select <strong>Enabled from selected virtual networks and IP addresses</strong>

Under <strong>Firewall</strong>, select <strong>Add your client IP address</strong> to allow-list your current IP

<strong>Save</strong>


<h3 id="step-2-test-the-restriction-">Step 2: Test the restriction
</h3>

Confirm you can still access the storage account (you're on the allow-list)

Try accessing from a different network/VPN (should fail with 403 Forbidden)

Observe that having the access key alone is NOT enough—network rules now take precedence


> Tip: In production, use Service Endpoints or Private Endpoints instead of IP ranges for more security.

<h3 id="step-3-revert-for-simplicity-">Step 3: Revert for simplicity
</h3>

Go back to <strong>Networking</strong> > <strong>Public network access</strong>: <strong>Enable from all networks</strong>

<strong>Save</strong> (to not interfere with other labs)


---

<h2 id="part-6-copy-data-with-storage-browser-">Part 6 – Copy data with Storage browser
</h2>

<h3 id="step-1-copy-blob-between-containers-">Step 1: Copy blob between containers
</h3>

<strong>Storage browser</strong> > <strong>Blob containers</strong> > demo-container > select sample.txt

<strong>Copy</strong>

Create a new container demo-container-2 (or navigate to an existing empty one)

<strong>Paste</strong>—the blob is now copied


> Tip: This is the Portal equivalent of azcopy. For large data migrations, use AzCopy CLI for speed.


<h3 id="step-2-download-and-upload-">Step 2: Download and upload
</h3>

Select sample.txt > <strong>Download</strong> (pulls to your local machine)

Modify the file locally

Go back to <strong>Upload</strong> > upload the modified file

Confirm the updated file is in the container


---

<h2 id="success-criteria-">Success Criteria
</h2>

✓ Storage account created with StorageV2, LRS, Hot tier
✓ Container, queue, table, and file share all exist
✓ SAS URL grants time-limited read access to blob
✓ Entra ID authentication works (view blob with your user account)
✓ Network rule restricts access to allow-listed IPs
✓ Blob successfully copied between containers

---

<h2 id="cleanup-if-needed-">Cleanup (If Needed)
</h2>

``

---

Key Takeaways

1. LRS is cheap but not HA. GRS replicates to another region for disaster recovery
2. SAS tokens are time-limited and granular—perfect for sharing data without keys
3. Network rules add another layer of security on top of access keys
4. Entra ID authentication is the modern approach—don't rely on access keys in production
5. Storage browser is convenient for small files; use AzCopy for bulk data

---

Next Steps

Proceed to Lab 02 to learn about blob security and lifecycle management.