AZ-104 flashcards

Manage Azure identities and governance

• Microsoft Entra ID (formerly Azure Active Directory) is Azure's cloud identity service holding all users and groups.
• Member users are internal accounts; guest users are external collaborators invited through B2B who sign in with their own home credentials.
• Provision or remove many accounts at once with CSV-driven bulk create, bulk invite, and bulk delete operations.
• Security groups grant access, roles, and licenses; Microsoft 365 groups add shared collaboration resources like a mailbox, SharePoint site, and Teams.
• Assigned membership is maintained manually; dynamic membership adds and removes members automatically from an attribute rule and requires Microsoft Entra ID P1.
• A dynamic rule such as user.department -eq "Sales" auto-includes everyone in the Sales department and drops them when the attribute changes.
• Group-based licensing assigns product licenses to a group so members inherit them, and pairs powerfully with dynamic groups (set usage location or licensing fails).
• SSPR lets users reset their own passwords; Entra ID is a flat cloud directory with no OUs or Group Policy, unlike on-premises Active Directory.

• Azure RBAC is the authorization system that controls access to Azure resources; Microsoft Entra ID handles authentication.
• Every role assignment has three parts: a security principal (who), a role definition (what), and a scope (where).
• Owner has full access including managing access; Contributor manages resources but cannot grant access; Reader is view-only; User Access Administrator manages access but not resources.
• Scopes form a hierarchy — management group > subscription > resource group > resource — and a higher-scope assignment is inherited downward.
• Assign Reader once at the subscription and every child resource group and resource inherits it.
• Permissions are additive across all direct, inherited, and group assignments; explicit deny assignments override any allow.
• Create a custom role (JSON with Actions, NotActions, and AssignableScopes) only when no built-in role fits.
• Azure RBAC manages Azure resources; Microsoft Entra roles (such as Global Administrator) manage identity — they are separate systems.

• The Azure hierarchy is management group → subscription → resource group → resource, and governance applied at a higher scope is inherited by everything beneath it.
• Management groups let you assign policy and access to many subscriptions at once; moving a subscription to a new management group makes it inherit that group's governance.
• Azure Policy governs what configuration is allowed; an initiative (policy set) is a group of policy definitions managed and assigned as one unit.
• Audit reports non-compliant resources while Deny blocks non-compliant create or update requests; deployIfNotExists and modify can remediate existing resources.
• Policy answers "what is allowed" and RBAC answers "who can act" — even an Owner is stopped by a Deny policy.
• Resource locks apply regardless of RBAC: CanNotDelete blocks deletion, ReadOnly blocks modify and delete, and locks are inherited by child resources.
• Tags are not inherited by default but can be enforced and inherited with Policy; Microsoft Cost Management provides cost analysis, budgets with alerts, and Azure Advisor cost recommendations.

Implement and manage storage

• Storage access has two layers: networking (firewall, virtual network rules, private endpoints) and authorization (keys, SAS, Entra RBAC) — decide them separately.
• Storage firewalls restrict access to selected virtual network subnets via service endpoints and to public IP ranges; private endpoints remove public exposure entirely.
• The two account access keys grant full, all-or-nothing control; keep two so you can rotate without downtime, and regenerating a key invalidates every SAS signed with it.
• A SAS grants scoped, time-limited access defined by permissions, start and expiry time, allowed IP, protocol, and signed resources; the three types are account SAS, service SAS, and the most secure user delegation SAS signed with Entra credentials.
• Use a stored access policy so you can revoke or modify an already-issued service SAS server-side, without regenerating account keys.
• Prefer Microsoft Entra ID with Azure RBAC whenever the caller has an identity; ranked most to least secure: Entra RBAC, user delegation SAS, service SAS, access keys.
• Identity-based access lets Azure Files SMB shares authenticate with AD DS or Microsoft Entra; share-level access uses RBAC roles while file-level access uses NTFS ACLs.

• General-purpose v2 (GPv2) is the default account kind, supporting all services and access tiers; choose Standard performance for most workloads and Premium for low-latency, high-transaction needs.
• Every redundancy option keeps at least three copies: LRS stays in one datacenter, ZRS spans three availability zones, and GRS and GZRS add a second region.
• Use GRS or GZRS to survive a full region outage, and ZRS to survive a zone or datacenter outage within a single region.
• RA-GRS and RA-GZRS are the only options that let you read from the secondary region without a failover — the exact trigger is "read from the secondary."
• Object replication asynchronously copies block blobs between two storage accounts and requires blob versioning enabled on both the source and destination.
• Encryption at rest is always on (Storage Service Encryption with 256-bit AES); you can switch to customer-managed keys in Key Vault or add infrastructure encryption for double encryption.
• Manage data with Azure Storage Explorer (GUI, interactive) or AzCopy (command-line, scriptable bulk and account-to-account transfers).

• Azure Files provides managed SMB and NFS file shares you mount like a network drive; Azure Blob Storage provides containers of block, append, and page blobs for object data.
• Create a file share with a protocol and quota, mount SMB over port 445, and use a premium FileStorage account for NFS or low-latency workloads.
• Protect Azure Files with incremental share snapshots (recover individual files) and soft delete (recover a whole deleted share within a 1–365 day retention window).
• Azure File Sync keeps an on-premises Windows Server in sync with an Azure file share, and cloud tiering caches hot files locally while tiering cold files to Azure.
• A blob container's public access level is private (credential required), blob (anonymous read of known URLs), or container (anonymous read and list) — keep it private by default.
• Hot, cool, and cold are online tiers read instantly; archive is offline and cheapest to store but must be rehydrated (Standard up to ~15 hours, or High) before you can read it.
• Soft delete recovers accidentally deleted blobs and containers within a retention window; blob versioning automatically keeps previous versions when a blob is overwritten.
• Blob lifecycle management rules act on blob age to auto-transition to cooler tiers and delete data — e.g. cool at 30 days, archive at 90, delete at 365.

Deploy and manage Azure compute resources

• An ARM template is JSON with parameters, variables, resources, and outputs; parameters are supplied at deployment, outputs are returned after it.
• Bicep is a cleaner declarative language that transpiles to ARM JSON, infers dependencies from symbolic references, and can do anything ARM JSON can.
• Incremental mode (the default) adds and updates resources and leaves everything else untouched.
• Complete mode deletes any resource in the resource group that is not defined in the template — the classic accidental-deletion gotcha.
• Templates are idempotent: redeploying the same file is safe and only changes what differs from the current state.
• Export a template from a resource group or the deployment history to capture resources you built by hand.
• Convert ARM JSON to Bicep with bicep decompile, and Bicep to ARM JSON with bicep build.
• Deploy via the portal, az deployment group create, or New-AzResourceGroupDeployment, targeting a resource group, subscription, management group, or tenant.

• Creating a VM requires five choices: image, size, admin credentials, resource group, and region; the VM attaches to a network interface (NIC).
• VM size families map to workloads — B and D are general purpose, F is compute optimized, and E is memory optimized; resizing to a size on different hardware requires stopping (deallocating) the VM.
• Managed disk types range from Standard HDD (cheapest) through Standard SSD and Premium SSD to Ultra Disk (highest IOPS and lowest latency); data disks can be added online and expanded but not shrunk.
• Availability zones spread VMs across separate datacenters in a region for a 99.99% SLA and survive a whole-datacenter failure.
• Availability sets spread VMs across fault and update domains within one datacenter for a 99.95% SLA, protecting against rack failure and planned maintenance.
• A Virtual Machine Scale Set runs many identical, load-balanced VMs that autoscale with demand and can span zones.
• Encryption at host encrypts the VM's temp disk and disk caches on the physical host, unlike Azure Disk Encryption's in-guest BitLocker or dm-crypt.
• Moving a VM to another resource group or subscription is a native Move; moving to another region uses Azure Resource Mover.

• Azure Container Registry (ACR) is a private, managed registry that stores container images; ACI, Container Apps, and AKS pull from it.
• ACR SKUs are Basic, Standard, and Premium; geo-replication and private endpoints are Premium-only, and a managed identity lets services pull images without stored credentials.
• Azure Container Instances (ACI) runs a single container or container group serverlessly, bills per second, and has no autoscaling, ideal for short, isolated, or bursty tasks.
• Azure Container Apps runs serverless containers with automatic scale rules, scale-to-zero, HTTPS ingress, and revisions, ideal for microservices and event-driven workloads.
• Sizing in ACI is a fixed CPU and memory request; Container Apps adds min/max replicas plus scale rules driven by HTTP, CPU, or KEDA events.
• Choose ACI to run something once with no orchestration, Container Apps to autoscale managed containers, and AKS only when you need full Kubernetes control.

• Azure App Service is a managed PaaS for web apps and APIs; every app runs on an App Service plan, which is the compute you pay for.
• The plan's pricing tier (Free, Shared, Basic, Standard, Premium, Isolated) decides compute, whether apps share hardware, and which features are available.
• Scale up changes the tier for bigger instances; scale out adds more instances, manually or with autoscale rules (Standard tier and above).
• Custom TLS bindings need Basic tier; autoscale, deployment slots, and scheduled backups need Standard or higher.
• Map a custom domain with a CNAME or A record plus a TXT verification record, secure it with a managed or uploaded certificate, and force HTTPS with HTTPS Only.
• Deployment slots (Standard and above) let you test in a staging slot then swap with production for zero-downtime deployment and instant rollback; sticky slot settings stay with their slot.
• Use VNet integration for outbound access and access restrictions or private endpoints for inbound access.

Implement and manage virtual networking

• Azure reserves five IP addresses in every subnet (network, gateway, two for DNS, broadcast), so a /24 yields 251 usable hosts.
• VNet peering connects two VNets over the Microsoft backbone; regional peering is same-region and global peering spans regions.
• Peering is non-transitive: A-to-B plus B-to-C does not connect A to C — each pair needs its own peering.
• Use Allow gateway transit on the hub and Use remote gateways on the spoke so spokes share the hub's VPN or ExpressRoute gateway.
• Standard SKU public IPs are static-only and secure by default; Basic SKU is being retired, so prefer Standard.
• A user-defined route with next hop type Virtual appliance forces traffic through a firewall or NVA; enable IP forwarding on the appliance NIC.
• Network Watcher's IP flow verify, Next hop, and Effective routes diagnose NSG and routing problems quickly.

• NSG rules use priority 100-4096 where a lower number means higher priority, and Azure stops at the first matching rule.
• Every NSG rule is a 5-tuple: source, source port, destination, destination port, and protocol, with an allow or deny action.
• NSGs apply at the subnet level, the NIC level, or both; when both apply, traffic must pass both, so the most restrictive rule wins.
• Application security groups let you reference VMs by workload in NSG rules instead of by IP address, so rules survive scaling.
• Effective security rules combine subnet and NIC NSGs into one merged view to show exactly which rule allows or blocks traffic.
• Azure Bastion gives browser-based RDP and SSH over TLS with no public IP on the VM, from a subnet named AzureBastionSubnet.
• A service endpoint keeps the PaaS public endpoint but routes over the backbone; a private endpoint gives the service a private IP in your VNet.

• A public Azure DNS zone hosts a domain's records (A, CNAME, MX, TXT) and becomes authoritative once you delegate the domain by updating the name servers at the registrar.
• A private DNS zone resolves VM names privately inside and between VNets via a virtual network link; enable autoregistration to have Azure create and remove VM A records automatically.
• Azure Load Balancer is a Layer 4 (TCP/UDP) distributor built from a frontend IP, a backend pool, health probes, and load-balancing rules.
• A public load balancer fronts a public IP for internet traffic; an internal load balancer fronts a private IP to distribute traffic across a private app tier inside the VNet.
• The Standard SKU is zone-redundant and secure by default (closed until an NSG allows traffic); Basic is legacy and being retired.
• Use Application Gateway for Layer 7 URL-path routing and WAF, and Traffic Manager for global DNS-based routing — not Azure Load Balancer.
• If a backend fails its health probe it is removed from rotation; when traffic stops distributing, check the probe port and path, the NSG allowing the AzureLoadBalancer tag, and backend health.

Monitor and maintain Azure resources

• Azure Monitor collects two fundamental data types: metrics (numeric, time-series, near real time) and logs (structured events queried with KQL).
• Interpret metrics in Metrics Explorer using aggregations, filters, and splitting; metrics are collected automatically and need no query language.
• Logs live in a Log Analytics workspace and are queried with Kusto Query Language (KQL) for troubleshooting, correlation, and auditing.
• Diagnostic settings route platform logs and metrics to a Log Analytics workspace (analyze with KQL), a storage account (archive), or an event hub (stream to a SIEM).
• Alert rules fire on a metric or log condition; an action group defines who is notified and what happens — email, SMS, webhook, Azure Function, Logic App, or automation runbook.
• Alert processing rules suppress alerts during maintenance or route them at scale without editing each rule.
• VM insights (via the Azure Monitor Agent) monitors guest performance, while boot diagnostics helps diagnose a VM that will not start.
• Network Watcher diagnoses network paths, and Connection Monitor continuously tests reachability and latency between endpoints over time.

• A Recovery Services vault holds Azure Backup for VMs, Azure Files, and in-VM SQL/SAP, and is the vault Azure Site Recovery uses; the newer Azure Backup vault covers modern workloads like Azure databases, blobs, and managed disks.
• A backup policy is a schedule (how often backups run) plus retention (how long each recovery point is kept).
• Azure Backup protects against data loss, corruption, and ransomware by keeping point-in-time recovery points you restore from.
• Restore granularity for a VM ranges from creating a whole new VM, to replacing disks, to file-level recovery of individual files.
• Azure Site Recovery continuously replicates VMs to a secondary region so you can fail the workload over during a region or site outage.
• Failover comes in three forms: test (isolated, non-disruptive validation), planned (clean shutdown, no data loss), and unplanned (from the latest recovery point).
• The classic distinction: Backup protects against data loss and corruption with point-in-time restore; Site Recovery protects against a site or region outage by keeping the workload running elsewhere, measured by RPO and RTO.
• Backup center is the unified place to monitor backups, and backup alerts can flow through Azure Monitor action groups.

Yes — the whole AZ-104 deck is free and needs no account. Create a free account only if you want to save progress and drill full practice questions and mock exams.