Skip to main content

 

Azure Architect Interview Questions and Answers

 

What is Reapply and Redeploy in Azure?

In Azure, Reapply and Redeploy are two different operations used to troubleshoot and fix issues with virtual machines (VMs). Here's what each does:

1. Reapply

  • Purpose: Resets the VM's state and reapplies the VM properties (like networking settings) without redeploying it.
  • When to use: If the VM is running but experiencing issues with configuration settings, extensions, or networking.

2. Redeploy

  • Purpose: Moves the VM to a new host in Azure while keeping its existing settings.
  • When to use: If the VM is stuck in an unresponsive state or cannot be connected to.
  • Command (Azure CLI):

Key Differences

Feature

Reapply

Redeploy

What it does

Refreshes VM settings

Moves VM to a new host

Impact

No downtime (usually)

VM is restarted (downtime)

Fixes issues like

Incorrect network settings, extensions

Unresponsive VM, OS boot failures

 


 

Why Do We Need to Re-protect After a Failover in Azure Site Recovery (ASR)?

After performing a failover in Azure Site Recovery (ASR), you must reprotect the VM to establish protection in the opposite direction. Here’s why:

  1. Failover Switches the Replication Direction
    • During failover, the VM is moved from the primary site to the secondary site (Azure or another datacentre).
    • The original primary site is now considered the failed site, and it is no longer tracking changes.
  2. Replication Must Be Re-established
    • After failover, the workload is running in the new location.
    • However, if another failure occurs, you have no active replication back to the original site.
    • Reprotection re-establishes replication from the new primary site (previously secondary) back to the original site.
  3. Failback Preparation
    • Without Reprotect, you cannot failback to the original site.
    • Reprotect ensures that the data is synchronized back so that, once the original site is restored, you can failback safely.

 

How Does Azure Site Recovery (ASR) Work?

Azure Site Recovery (ASR) is a disaster recovery (DR) solution that replicates workloads between different locations (on-prem to Azure or Azure region to region).

ASR Workflow:

  1. Replication Setup
    • You configure source (on-premises/another Azure region) and target (Azure/secondary region).
    • ASR replicates the VM data continuously.
  2. Replication & Monitoring
    • ASR tracks incremental changes and stores them in Azure Storage.
    • You can monitor RPO (Recovery Point Objective) and RTO (Recovery Time Objective).
  3. Failover (Planned or Unplanned)
    • In case of an outage, ASR allows you to failover VMs to the secondary site.
    • You can choose:
      • Planned Failover (no data loss, manual, for testing)
      • Unplanned Failover (during an outage)
  4. Reprotect
    • After failover, ASR stops old replication and sets up a new replication in the reverse direction (from the secondary site to the original site).
  5. Failback (If Needed)
    • If the original site is restored, you can failback VMs to the original location.

Failover vs. Reprotect vs. Failback

Step

Action

Purpose

Failover

Move VM to secondary site

Resume operations in case of failure

Reprotect

Set up replication in reverse

Prepare for failback to original site

Failback

Move VM back to the original site

Restore normal operations

 


 

Where Should the Private Endpoint Be Created in a Hub-and-Spoke Topology with Azure Private DNS?

In a Hub-and-Spoke network topology with Azure Private DNS, the Private Endpoint should be created in the Spoke VNet where the consuming resources (VMs, Apps, etc.) reside. Here’s why:

Best Practices for Private Endpoint Placement

  1. Private Endpoints Should Be in the Spoke VNet
    • Private Endpoints allow access to PaaS services (like Azure Storage, SQL, etc.) over private IPs.
    • Since applications and VMs that need to consume the service reside in the Spoke VNet, the Private Endpoint should be created there.
    • This keeps the traffic contained within the Spoke and avoids unnecessary routing through the Hub.
  2. Azure Private DNS Zone Should Be in the Hub (or Centrally Managed)
    • The Private DNS Zone should be created in the Hub VNet (or a shared services VNet).
    • The Hub should be linked to all Spokes as a DNS resolution point.
    • This ensures that VMs in Spokes can resolve Private Endpoints correctly.
  3. Private Endpoint DNS Resolution in Hub-and-Spoke
    • If a Private Endpoint is created in a Spoke VNet, it registers its private IP in the Private DNS Zone.
    • Spoke VNets need DNS forwarding to the Hub to resolve Private Endpoint names.
    • A custom DNS server (or Azure Private Resolver) in the Hub can help with centralizing DNS resolution.

 

Example Deployment

Scenario: Accessing Azure SQL via Private Endpoint

  • Private DNS Zone: privatelink.database.windows.net (Created in Hub)
  • Private Endpoint for Azure SQL: Created in Spoke VNet
  • DNS Resolution:
    • The Spoke VNet is linked to the Private DNS Zone in the Hub.
    • VMs in the Spoke use Private Endpoint IP instead of public IP.

 

Key Takeaways

Component

Placement

Reason

Private Endpoint

Spoke VNet

Keeps PaaS service traffic inside the Spoke

Private DNS Zone

Hub (or Shared VNet)

Centralized DNS resolution

DNS Forwarding

Hub (DNS Resolver/Custom DNS)

Ensures Spokes resolve Private Endpoints correctly

 


 

Best Practices & Steps to Migrate Storage from One Subscription to Another in Azure

When migrating Azure Storage Accounts between subscriptions, you must manually transfer data, as Azure does not support direct subscription moves for storage accounts. Below are best practices and methods to ensure a smooth migration.

🔹 Best Practices Before Migration

✅ Plan the Migration Approach: Choose the best method based on your storage type (Blob, Files, Tables, Queues).
✅ Check Subscription & RBAC Permissions: Ensure both source and target subscriptions have required permissions.
✅ Minimize Downtime: Schedule during off-peak hours and use incremental copy to reduce impact.
✅ Verify Networking & Security: Ensure VNet integration, private endpoints, and firewall rules are correctly configured in the new subscription.
✅ Update Dependencies: Update connection strings for apps using the old storage account.

🔹 Methods to Migrate Azure Storage

🔹 1. Use Azure Storage Account Move (Limited Use)

  • If both subscriptions are in the same Azure AD tenant, you may be able to move storage directly.
  • Supported: General-purpose v1, v2 accounts without private endpoints.
  • Not Supported: Classic storage, Premium storage, Private Endpoints, Storage with CMK encryption.

Azure Portal:

  1. Go to Storage Account → Change Subscription.
  2. Select the destination subscription and resource group.
  3. Click Move.

✅ Best For: Simple moves with no dependencies.
⚠️ Limitations: Not supported for all storage accounts (use manual methods below if unsupported).

🔹 2. Migrate Storage Data Manually (Recommended)

If you cannot move the storage account, migrate data using AzCopy, Storage Explorer, or Data Factory.

🔹 A. AzCopy (Best for Large Blob/File Transfers)

AzCopy is a fast, CLI-based tool to copy large amounts of storage data.

Steps:

  1. Download & Install AzCopy:

sh

CopyEdit

azcopy login

  1. Copy Data to New Storage Account:

sh

CopyEdit

azcopy copy "https://sourceaccount.blob.core.windows.net/container/*" "https://destinationaccount.blob.core.windows.net/container" --recursive=true

  1. Verify Data Integrity:
    • Compare blob counts between source and destination.
    • Run checksum validation if needed.

✅ Best For: Large-scale data migration with high-speed performance.
⚠️ Limitations: Needs scripting for automation.

🔹 B. Azure Storage Explorer (GUI-Based Method)

For smaller migrations, Azure Storage Explorer provides a drag-and-drop interface.

Steps:

  1. Install Azure Storage Explorer.
  2. Connect both source and destination storage accounts.
  3. Select Blobs, Files, Queues, or Tables → Right-click → Copy & Paste.

✅ Best For: Small to medium migrations, easy for non-technical users.
⚠️ Limitations: Slower than AzCopy for large data transfers.

🔹 C. Azure Data Factory (Automated & Scalable)

For structured data (tables, blobs, etc.), Azure Data Factory (ADF) provides an ETL pipeline to migrate data.

Steps:

  1. Create an Azure Data Factory.
  2. Set up a Copy Data Pipeline:
    • Source: Old storage account.
    • Destination: New storage account.
  3. Run the pipeline and monitor transfer logs.

✅ Best For: Scheduled and automated data transfers.
⚠️ Limitations: Requires Azure Data Factory setup.

🔹 3. Migrate Azure Files (SMB/NFS Shares)

If using Azure Files, use Azure File Sync or RoboCopy.

Using AzCopy:

sh

CopyEdit

azcopy copy "https://sourceaccount.file.core.windows.net/share" "https://destinationaccount.file.core.windows.net/share" --recursive=true

Using Robocopy (Windows VM):

sh

CopyEdit

robocopy \\sourceaccount.file.core.windows.net\share \\destinationaccount.file.core.windows.net\share /mir

✅ Best For: File shares requiring SMB/NFS access.
⚠️ Limitations: Permissions (ACLs) may need to be manually migrated.

🔹 Post-Migration Steps

1️⃣ Validate Data: Compare source and destination to ensure all data transferred successfully.
2️⃣ Update Application Connection Strings: Update Azure Function Apps, Web Apps, VMs to use the new storage account.
3️⃣ Check Security Settings: Ensure RBAC, private endpoints, and firewall rules are properly configured.
4️⃣ Delete Old Storage Account (only after validation) to avoid extra costs.

💡 Summary: Which Method Should You Choose?

Method

Best For

Pros

Cons

Move via Portal

Simple storage moves

Easy, no data copy required

Not supported for all storage

AzCopy

Large blob/file migrations

Fast, automated, secure

CLI-based, requires scripting

Storage Explorer

Small migrations

GUI-based, easy to use

Slower for large data

Data Factory

Structured data migration

Automated, scalable

Requires pipeline setup

Robocopy

Azure Files migration

Supports SMB/NFS

Manual ACL migration required

 

Comments

Post a Comment

Popular posts from this blog

PKI Lab Setup

Resource Forest Active Directory Domain Service – DC01 Root Certificate Authority (Offline) – RCA01 Issuing Certificate Authority – ICA01 Client Server – WS01 Account Forest ADC01 AWS01 ------------------------------------------------------------------------------------------------------------------------------------------------------ Step 1 – Installing the Domain Controller Step 2 – Installing the Root Certificate Authority Ø   Install the AD CS Role on the server (RCA01) Ø   Configure the AD CS Role ü   Click – Configure Active Directory Certificate Service on the Destination Server ü   Click Next – If you have logged in with Administration Account or Choose the Account which will be responsible for CA ü   Select Role Service to configure – For my case I am selecting only Certification Authority ü   Select Standalone CA – As this will be offline CA on a work group machine ü   Select Root CA – As this will be the Root CA Server ü ...
Post a Comment
Read more

Enable SSH on ESXi 6.X

Working on your VMware environment, we often needed remote access to your ESXi hosts. Accessing the ESXi Host via SSH offers administrators the ability to maintain, troubleshoot, and remediate issues by using a Secure Shell client such as PuTTY. As per the security concern, SSH is disabled by default. However, you can enable it for remote command execution in multiple ways. In this post, we will provide you a walk through the different processes of enabling SSH on VMware ESXi 6.5 hosts. Let's go through one by one! Enable via Direct Console User Interface (DCUI) Login in ESXi Direct Console User Interface (DCUI) and Press F2 Key. It will ask you for root credentials. Now go to System Customization screen and select Troubleshooting Options. Under Troubleshooting, go to Mode Option and choose Enable SSH . SSH will show now Enabled. Press Esc to go back to main menu. Enable via vSphere Web Client (Host) Log into the ESXi via the Web Client. It must be https://localhostname/UI. Log in ...
Post a Comment
Read more

Active Directory Replication

Active Directory Replication: is the process by which a change made to an Active Directory objects on one domain controller is propagate to another domain controller. Type of change can be addition, modification, container change or deletion of an object. When a change occurs, domain controller notify to other domain controller which is called Change Notification . Then replication partners generates Change Request . Then the source domain controller send the Update to replication partners.  The delay between the time a change occurs and the time it is propagated to all domain controllers in the site is known as  Replication Latency . 15 Sec for first direct replication partner (Configurable) 3 sec for rest replication partner (Configurable) Security updates like Password lock do not wait for 15 sec and replicates immediately and known as Urgent Replication . Changes can take place on any DC. It may possible that same change take place on multiple DC at same time and this ...
Post a Comment
Read more