Explanation:

Statement Evaluations

1. The resource tagging policy assignment will be applied to KV1.
Answer: Yes

Explanation:
The "Resource tagging" policy is assigned at the Finance management group scope.

KV1 resides in RG4, which is in Subscription3.
Subscription3 belongs to the Finance management group.
All resources within that management group hierarchy (subscriptions → resource groups → resources) are subject to the policy assignment. Therefore, KV1 will have the resource tagging policy applied.

2. Cost management data for the InternalCharge = True tag will include VM1.
Answer: No

Explanation:
Azure Cost Management uses tags directly applied to the resource itself (or the resource group, if the resource inherits tags via an Azure Policy configuration—but no such inheritance policy is present here).

VM1 is in RG1, under Subscription2.
Subscription2 has the tag InternalCharge: False.
VM1 has no tag specified, and by default, subscription-level tags do not automatically flow to resources for cost tracking.
Filtering cost data by InternalCharge = True will not include VM1, because it does not carry that tag.

3. Moving Subscription4 to the Marketing management group will cause VM2 to shut down.
Answer: No

Explanation:
The "Deny creating virtual machines" policy assigned to the Marketing management group only prevents the creation of new VMs (including updates that would trigger a creation).

Existing VMs, such as VM2 in Subscription4, are not affected by such a Deny policy. They continue to run normally.
Moving a subscription into a management group with this policy will not cause any existing resources to be shut down, deleted, or stopped.

Explanation:

To solve this, focus on two key design constraints in Azure Container Apps:

Networking isolation is defined at the Container Apps environment level
Compute types (consumption vs dedicated SKUs) are defined using workload profiles within an environment

Step 1: Determine environment separation (networking)
Requirements:
App1 & App2:
Must communicate with each other
Use NSGs
App3:
Must be fully isolated from App1 and App2
Uses IP restrictions instead of NSGs

Key point:
Full isolation requires a separate Container Apps environment
Apps in the same environment share the same virtual network boundary

Conclusion:
1 environment for App1 + App2
1 environment for App3

Total Container Apps environments = 2

Step 2: Determine workload profiles (compute)
App requirements:

App1
Dynamically allocated compute → Consumption profile

App2
Up to 10 Dedicated-D16 (general purpose) → Dedicated workload profile

App3
Up to 10 Dedicated-E16 (memory optimized) → Another dedicated workload profile

Important:
Different VM SKUs (D-series vs E-series) require separate workload profiles
Consumption profile is separate from dedicated profiles

Conclusion:
You need:
Consumption profile (App1)
Dedicated D16 profile (App2)
Dedicated E16 profile (App3)

Total workload profiles = 3

Final Answer
Container Apps environments: 2
Workload profiles: 3

AZ-305 Exam Insight
Environment = networking + isolation boundary
Workload profile = compute type and scaling characteristics
If apps need:
Different isolation → separate environments
Different VM SKUs → separate workload profiles

Explanation:

Key Reasoning
Temporary Security: A security PIN is a manual, one-time code used for specific high-risk operations (like stopping backups or deleting data). While it adds a layer of verification, it is designed to prevent unauthorized actions by someone who has hijacked a session, rather than structurally preventing a compromised administrator from taking action.

Administrative Access: An administrator with sufficient privileges in the contoso.com tenant can simply generate the PIN themselves within the portal or via CLI. Therefore, the PIN does not truly "prevent" a compromised admin from performing these tasks; it only adds a minor speed bump.

The "Gold Standard" Solution: To truly meet this goal, you should use Multi-user authorization (MUA) for Azure Backup using Resource Guard. This requires an operation to be approved by a user in a different tenant or with a different role, ensuring a single compromised account cannot bypass the protection.

Why "A. Yes" is incorrect (despite what some brain dumps may say)

Vulnerability: Since the PIN is generated within the same environment the admin already controls, it offers no protection against an "Inside Man" or a compromised Global Admin or Backup Admin account.

Logic Gap: The goal asks to prevent the account from modifying policies. A security PIN is an authentication step, not an authorization barrier or an immutable lock.

Reference
Multi-user authorization for Azure Backup
Security features to protect backups

Explanation:

In Kubernetes, pod scheduling rules determine how pods are placed across nodes and zones. To ensure high availability in a multi-zone AKS cluster, you want pods from the same tier to be spread across different availability zones.

Pod anti-affinity rules
Prevent multiple pods with the same labels (e.g., same tier) from being scheduled on the same node or in the same zone.
This guarantees distribution of active pods across zones, which maximizes resilience against zone failures.

Since the cluster spans three availability zones and each tier has three pods, anti-affinity ensures that each pod is placed in a different zone.

Why not the other options?

A. Kubernetes controller type
Refers to workload controllers like Deployments, StatefulSets, etc. These manage pod lifecycles but do not enforce zone distribution.

B. Leader election
Used in scenarios where one pod must act as the leader (e.g., in HA applications). It does not control pod placement across zones.

C. Startup probes
Used to check if a container has started successfully before receiving traffic. This is about health monitoring, not distribution.

D. Scheduling anti-affinity
Correct choice — ensures pods are spread across zones by preventing them from being co-located.

Reference:
Microsoft Learn: Best practices for running AKS across availability zones
Kubernetes Docs: Affinity and anti-affinity

Explanation:

Minimum number of network managers
Azure Virtual Network Manager is a per-tenant resource. It can manage virtual networks across multiple subscriptions, but only within the same Microsoft Entra tenant.

The table shows two different tenants:
contoso.com
fabrikam.com

Because a single network manager cannot span tenants, you need at least one network manager per tenant. That gives a minimum of 2 network managers — one in contoso.com and one in fabrikam.com. All the subscriptions under management groups mg01, mg02 (in contoso.com) can be served by one network manager; all subscriptions under mg03 (in fabrikam.com) need a separate network manager.

Assigning network group membership
Network groups in Azure Virtual Network Manager define which virtual networks are governed by a connectivity or security configuration. Membership can be assigned manually (by selecting VNets one by one) or dynamically using Azure Policy.

To minimize administrative effort, you use Azure Policy with a custom policy definition that evaluates conditions (e.g., resource name, tags, location) and automatically adds matching virtual networks to the network group. This eliminates the need for manual updates whenever new VNets are created or existing ones change.

Azure Automanage automates VM management best practices, not network group membership.
Azure Automation is used for runbooks and configuration management, not for defining dynamic network group membership.

Therefore, Azure Policy is the recommended approach for low-touch, automatic network group assignment.

Reference
Azure Virtual Network Manager – Cross-tenant support and network groups (confirms per-tenant scope)
Dynamic network group membership with Azure Policy

Explanation:

Why this is correct
To achieve an SLA of 99.99%, you need a design that protects against:
Data center-level failures
Rack-level failures
Power/network outages in a single location

Azure Availability Zones are physically separate locations within an Azure region, each with:
Independent power
Independent cooling
Independent networking

By deploying virtual machines across multiple Availability Zones, you ensure:
If one zone goes down, the app continues running in another zone
This design meets the 99.99% SLA requirement for many multi-VM workloads

Why the other options are incorrect

A. Application groups
Not an Azure high availability feature for VMs
More related to application management concepts, not infrastructure resilience

C. Availability Sets
Provide intra-datacenter redundancy
Protect against:
Hardware failure
Rack/host maintenance
But they are limited to a single datacenter, so:
They do NOT protect against full datacenter failure
Typically only support approximately 99.95% SLA (not 99.99%)

Good for basic HA, but not sufficient for 99.99% requirements.

D. Azure Site Recovery
Used for disaster recovery (DR), not high availability
Focus:
Replicating VMs to another region
Failover during disasters
Recovery is not instant (RTO/RPO delays exist)

Too slow for HA design requirements.

Exam takeaway (important for AZ-305)
Availability Sets = single datacenter HA (approximately 99.95%)
Availability Zones = regional HA (99.99%)
Site Recovery = cross-region disaster recovery
Always match SLA level to redundancy scope

Explanation:

When you replicate virtual machines across availability zones within the same Azure region using Azure Site Recovery (ASR), the underlying managed disks must be able to survive a zone-level failure to maximize availability.

Here’s why ZRS is the right choice:

Zone-redundant storage (ZRS)
Replicates your managed disk data synchronously across three Azure availability zones in the primary region. If one zone becomes unavailable, the disk remains accessible from the other zones. This complements the zone-to-zone replication of the VM itself, ensuring both compute and storage are resilient to a zone outage.

Locally-redundant storage (LRS)
Replicates data three times within a single data center (one zone). If that zone fails, the disk becomes unavailable, which undermines a zone-to-zone ASR strategy.

Geo-redundant storage (GRS) and Geo-zone-redundant storage (GZRS)
Replicate data to a secondary region, which is unnecessary in this scenario because ASR already handles cross-zone replication within the same region. GZRS includes ZRS in the primary region, but its extra geo-replication does not increase availability within the primary region for zone-to-zone failover. It only adds region-level disaster recovery, which is not the focus here.

Key Point
To maximize availability when replicating VMs across availability zones with ASR, your disks should also be zone-redundant. ZRS ensures the storage layer is resilient to a zone failure, matching the compute layer’s resilience.

References
Azure managed disk redundancy options
Azure Site Recovery: Zone-to-zone disaster recovery architecture

Explanation:
You need to provide fabrikam.com users access to contoso.com enterprise apps with automated identity provisioning and policy-based access management (assignments, approvals, expirations). B2B collaboration invites external users to your tenant. Cross-tenant synchronization automatically provisions identities from fabrikam.com to contoso.com. Entitlement management provides policy-based access packages with approvals and expirations. This combination minimizes administrative effort.

Correct Options:

For identity provisioning: Cross-tenant synchronization
Cross-tenant synchronization automatically creates, updates, and deletes B2B users in contoso.com based on users from fabrikam.com. It provisions identities programmatically without manual invitations. This ensures fabrikam.com administrators can manage which users are synchronized, meeting the requirement that they provide access to their users.

For access management: Entitlement management
Entitlement management allows you to create access packages with policies that govern assignments, approvals, and expirations. You can add the synchronized fabrikam.com users as allowed requestors or assignees. This provides policy-based governance with minimal administrative effort compared to manual role assignments.

Incorrect Options:

B2B collaboration (for identity provisioning) - B2B collaboration requires manual invitation or self-service sign-up. It does not automatically provision identities in bulk or allow fabrikam.com administrators to manage the provisioning process. Cross-tenant synchronization is the automated solution.

B2B direct connect (for identity provisioning) - B2B direct connect is for sharing Teams resources with external users using mutual trust and shared settings. It does not provision identities for enterprise app access across tenants.

Privileged Identity Management (PIM) - PIM manages just-in-time activation of privileged roles within a tenant. It does not manage access assignments, approvals, and expirations for external users accessing enterprise apps. PIM is for role elevation, not general access governance.

Permissions Management - Permissions Management is for managing permissions across multicloud infrastructures (AWS, GCP, Azure). It does not provide policy-based access assignments for external users to enterprise apps.

Reference:
Microsoft Learn: Cross-tenant synchronization overview; Microsoft Entra entitlement management; B2B collaboration vs. cross-tenant synchronization.