Please clarify the numbering system in Microsoft exams
I am trying to make sense of exam numbers in Microsoft Certification poster. https://arch-center.azureedge.net/Credentials/Certification-Poster_en-us.pdf. For example I notice most azure exam numbers start with 1xx. That gives me the impression that 1xx could be related to Infrastructure. But I am not sure if that is the correct understanding. For example all fundamental exams are numbered 9xx. So are exams numbered differently in role based certifications? What is the numbering pattern and practice in role based certifications? Again one might assume that all architect exams may have the same number pattern but they don’t. Some patterns emerge when it comes to Windows certification - 8xx. Collaboration and communication - 7xx except MB 700. So it appears even under role based certifications the numbering pattern may be different depending on the technology or platform or product. I have not found any authoritative material on the internet form anyone in Microsoft or an MVP on this topic. Some clarification on this topic will help to put at rest years of curiosity and confusion in the community. Thank you.Accelerate Agent Development: Hacks for Building with Microsoft Sentinel data lake
As a Senior Product Manager | Developer Architect on the App Assure team working to bring Microsoft Sentinel and Security Copilot solutions to market, I interact with many ISVs building agents on Microsoft Sentinel data lake for the first time. I’ve written this article to walk you through one possible approach for agent development – the process I use when building sample agents internally at Microsoft. If you have questions about this, or other methods for building your agent, App Assure offers guidance through our Sentinel Advisory Service. Throughout this post, I include screenshots and examples from Gigamon’s Security Posture Insight Agent. This article assumes you have: An existing SaaS or security product with accessible telemetry. A small ISV team (2–3 engineers + 1 PM). Focus on a single high value scenario for the first agent. The Composite Application Model (What You Are Building) When I begin designing an agent, I think end-to-end, from data ingestion requirements through agentic logic, following the Composite application model. The Composite Application Model consists of five layers: Data Sources – Your product’s raw security, audit, or operational data. Ingestion – Getting that data into Microsoft Sentinel. Sentinel data lake & Microsoft Graph – Normalization, storage, and correlation. Agent – Reasoning logic that queries data and produces outcomes. End User – Security Copilot or SaaS experiences that invoke the agent. This separation allows for evolving data ingestion and agent logic simultaneously. It also helps avoid downstream surprises that require going back and rearchitecting the entire solution. Optional Prerequisite You are enrolled in the ISV Success Program, so you can earn Azure Credits to provision Security Compute Units (SCUs) for Security Copilot Agents. Phase 1: Data Ingestion Design & Implementation Choose Your Ingestion Strategy The first choice I face when designing an agent is how the data is going to flow into my Sentinel workspace. Below I document two primary methods for ingestion. Option A: Codeless Connector Framework (CCF) This is the best option for ISVs with REST APIs. To build a CCF solution, reference our documentation for getting started. Option B: CCF Push (Public Preview) In this instance, an ISV pushes events directly to Sentinel via a CCF Push connector. Our MS Learn documentation is a great place to get started using this method. Additional Note: In the event you find that CCF does not support your needs, reach out to App Assure so we can capture your requirements for future consideration. Azure Functions remains an option if you’ve documented your CCF feature needs. Phase 2: Onboard to Microsoft Sentinel data lake Once my data is flowing into Sentinel, I onboard a single Sentinel workspace to data lake. This is a one-time action and cannot be repeated for additional workspaces. Onboarding Steps Go to the Defender portal. Follow the Sentinel Data lake onboarding instructions. Validate that tables are visible in the lake. See Running KQL Queries in data lake for additional information. Phase 3: Build and Test the Agent in Microsoft Foundry Once my data is successfully ingested into data lake, I begin the agent development process. There are multiple ways to build agents depending on your needs and tooling preferences. For this example, I chose Microsoft Foundry because it fit my needs for real-time logging, cost efficiency, and greater control. 1. Create a Microsoft Foundry Instance Foundry is used as a tool for your development environment. Reference our QuickStart guide for setting up your Foundry instance. Required Permissions: Security Reader (Entra or Subscription) Azure AI Developer at the resource group After setup, click Create Agent. 2. Design the Agent A strong first agent: Solves one narrow security problem. Has deterministic outputs. Uses explicit instructions, not vague prompts. Example agent responsibilities: To query Sentinel data lake (Sentinel data exploration tool). To summarize recent incidents. To correlate ISVs specific signals with Sentinel alerts and other ISV tables (Sentinel data exploration tool). 3. Implement Agent Instructions Well-designed agent instructions should include: Role definition ("You are a security investigation agent…"). Data sources it can access. Step by step reasoning rules. Output format expectations. Sample Instructions can be found here: Agent Instructions 4. Configure the Microsoft Model Context Protocol (MCP) tooling for your agent For your agent to query, summarize and correlate all the data your connector has sent to data lake, take the following steps: Select Tools, and under Catalog, type Sentinel, and then select Microsoft Sentinel Data Exploration. For more information about the data exploration tool collection in MCP server, see our documentation. I always test repeatedly with real data until outputs are consistent. For more information on testing and validating the agent, please reference our documentation. Phase 4: Migrate the Agent to Security Copilot Once the agent works in Foundry, I migrate it to Security Copilot. To do this: Copy the full instruction set from Foundry Provision a SCU for your Security Copilot workspace. For instructions, please reference this documentation. Make note of this process as you will be charged per hour per SCU Once you are done testing you will need to deprovision the capacity to prevent additional charges Open Security Copilot and use Create From Scratch Agent Builder as outlined here. Add Sentinel data exploration MCP tools (these are the same instructions from the Foundry agent in the previous step). For more information on linking the Sentinel MCP tools, please refer to this article. Paste and adapt instructions. At this stage, I always validate the following: Agent Permissions – I have confirmed the agent has the necessary permissions to interact with the MCP tool and read data from your data lake instance. Agent Performance – I have confirmed a successful interaction with measured latency and benchmark results. This step intentionally avoids reimplementation. I am reusing proven logic. Phase 5: Execute, Validate, and Publish After setting up my agent, I navigate to the Agents tab to manually trigger the agent. For more information on testing an agent you can refer to this article. Now that the agent has been executed successfully, I download the agent Manifest file from the environment so that it can be packaged. Click View code on the Agent under the Build tab as outlined in this documentation. Publishing to the Microsoft Security Store If I were publishing my agent to the Microsoft Security Store, these are the steps I would follow: Finalize ingestion reliability. Document required permissions. Define supported scenarios clearly. Package agent instructions and guidance (by following these instructions). Summary Based on my experience developing Security Copilot agents on Microsoft Sentinel data lake, this playbook provides a practical, repeatable framework for ISVs to accelerate their agent development and delivery while maintaining high standards of quality. This foundation enables rapid iteration—future agents can often be built in days, not weeks, by reusing the same ingestion and data lake setup. When starting on your own agent development journey, keep the following in mind: To limit initial scope. To reuse Microsoft managed infrastructure. To separate ingestion from intelligence. What Success Looks Like At the end of this development process, you will have the following: A Microsoft Sentinel data connector live in Content Hub (or in process) that provides a data ingestion path. Data visible in data lake. A tested agent running in Security Copilot. Clear documentation for customers. A key success factor I look for is clarity over completeness. A focused agent is far more likely to be adopted. Need help? If you have any issues as you work to develop your agent, please reach out to the App Assure team for support via our Sentinel Advisory Service . Or if you have any other tips, please comment below, I’d love to hear your feedback.Announcing public preview of custom graphs in Microsoft Sentinel
Security attacks span identities, devices, resources, and activity, making it critical to understand how these elements connect to expose real risk. In November, we shared how Sentinel graph brings these signals together into a relationship-aware view to help uncover hidden security risks. We’re excited to announce the public preview of custom graphs in Sentinel, available starting April 1 st . Custom graphs let defenders model relationships that are unique to their organization, then run graph analytics to surface blast radius, attack paths, privilege chains, chokepoints, and anomalies that are difficult to spot in tables alone. In this post, we’ll cover what custom graphs are, how they work, and how to get started so the entire team can use them. Custom graphs Security data is inherently connected: a sign-in leads to a token, a token touches a workload, a workload accesses data, and data movement triggers new activity. Graphs represent these relationships as nodes (entities) and edges (relationships), helping you answer questions like: “Who received the phishing email, who clicked, and which clicks were allowed by the proxy?” or “Show me users who exported notebooks, staged files in storage, then uploaded data to personal cloud storage- the full, three‑phase exfiltration chain through one identity.” With custom graphs, security teams can build, query, and visualize tailored security graphs using data from the Sentinel data lake and non-Microsoft sources, powered by Fabric. By uncovering hidden patterns and attack paths, graphs provide the relationship context needed to surface real risk. This context strengthens AI‑powered agent experiences, speeds investigations, clarifies blast radius, and helps teams move from noisy, disconnected alerts to confident decisions. In the words of our preview customers: “We ingested our Databricks management-plane telemetry into the Sentinel data lake and built a custom security graph. Without writing a single detection rule, the graph surfaced unusual patterns of activity and overprivileged access that we escalated for investigation. We didn't know what we were looking for, the graph surfaced the risk for us by revealing anomalous activity patterns and unusual access combinations driven by relationships, not alerts.” – SVP, Security Solutions | Financial Services organization Use cases Sentinel graph offers embedded, Microsoft managed, security graphs in Defender and Microsoft Purview experiences to help you at every stage of defense, from pre-breach to post-breach and across assets, activities, and threat intelligence. See here for more details. The new custom graph capability gives you full control to create your own graphs combining data from Microsoft sources, non-Microsoft sources, and federated sources in the Sentinel data lake. With custom graphs you can: Understand blast radius – Trace phishing campaigns, malware spread, OAuth abuse, or privilege escalation paths across identities, devices, apps, and data, without stitching together dozens of tables. Reconstruct real attack chains – Model multi-step attacker behavior (MITRE techniques, lateral movement, before/after malware) as connected sequences so investigations are complete and explainable, not a set of partial pivots. Reconstruct these chains from historical data in the Sentinel data lake. Figure 2: Drill into which specific MITRE techniques each IP is executing and in which tactic category Spot hidden risks and anomalies – Detect structural outliers like users with unusually broad access, anomalous email exfiltration, or dangerous permission combinations that are invisible in flat logs. Figure 3: OAuth consent chain – a single compromised user consented four dangerous permissions Creating custom graph Using the Sentinel VS Code extension, you can generate graphs to validate hunting hypotheses, such as understanding attack paths and blast radius of a phishing campaign, reconstructing multi‑step attack chains, and identifying structurally unusual or high‑risk behavior, making it accessible to your team and AI agents. Once persisted via a schedule job, you can access these custom graphs from the ready-to-use section in the graphs section in the Defender portal. Figure 4: Use AI-assisted vibe coding in Visual Studio Code to create tailored security graphs powered by Sentinel data lake and Fabric Graphs experience in the Microsoft Defender portal After creating your custom graphs, you can access them in the Graphs section of the Microsoft Defender portal under Sentinel. From there, you can perform interactive, graph-based investigations, for example, using a graph built for phishing analysis to quickly evaluate the impact of a recent incident, profile the attacker, and trace paths across Microsoft telemetry and third-party data. The graph experience lets you run Graph Query Language (GQL) queries, view the graph schema, visualize results, see results in a table, and interactively traverse to the next hop with a single click. Figure 5: Query, visualize, and traverse custom graphs with the new graph experience in Sentinel Billing Custom graph API usage for creating graph and querying graph is billed according to the Sentinel graph meter. Get started To use custom graphs, you’ll need Microsoft Sentinel data lake enabled in your tenant, since the lake provides the scalable, open-format foundation that custom graphs build on. Use the Sentinel data lake onboarding flow to provision the data lake if it isn’t already enabled. Ensure the required connectors are configured to populate your data lake. See Manage data tiers and retention in Microsoft Sentinel | Microsoft Learn. Create and persist a custom graph. See Get started with custom graphs in Microsoft Sentinel (preview) | Microsoft Learn. Run adhoc graph queries and visualize graph results. See Visualize custom graphs in Microsoft Sentinel graph (preview) | Microsoft Learn. [Optional] Schedule jobs to write graph query results to the lake tier and analytics tier using notebooks. See Exploring and interacting with lake data using Jupyter Notebooks - Microsoft Security | Microsoft Learn. Learn more Earlier posts (Sentinel graph general availability) RSAC 2026 announcement roundup Custom graphs documentation Custom graph billingAnnouncing Fabric Mirroring integration for Azure Database for MySQL - Public Preview at FabCon 2026
At FabCon 2026, we’re excited to announce the Public Preview of Microsoft Fabric Mirroring integration for Azure Database for MySQL. This integration makes it easier than ever to analyze MySQL operational data using Fabric’s unified analytics platform, without building or maintaining ETL pipelines. This milestone brings near real-time data replication from Azure Database for MySQL into Microsoft Fabric OneLake, unlocking powerful analytics, reporting, and AI scenarios while keeping transactional workloads isolated and performant. Why Fabric integration for Azure Database for MySQL? MySQL is widely used to power business‑critical applications, but operational databases aren’t optimized for analytics. Traditionally, teams rely on complex ETL pipelines, custom connectors, or batch exports — adding cost, latency, and operational overhead. With Fabric integration, Azure Database for MySQL now connects directly to Microsoft Fabric, enabling: Zero‑ETL analytics on MySQL operational data Near real-time synchronization into OneLake Analytics‑ready open formats for BI, data engineering, and AI A unified experience across Power BI, Lakehouse, Warehousing, and notebooks All without impacting your production workloads. What’s new in the Public Preview? The Public Preview introduces a first‑class integration between Azure Database for MySQL and Microsoft Fabric, designed for simplicity and scale. It introduces a solid set of core operational and enterprise‑readiness capabilities, enabling end-users to confidently get started and scale their analytics scenarios. Core replication operations Start, monitor, and stop replication directly from the integrated experience Support for both initial data load and continuous change data capture (CDC) to keep data in sync with minimal latency. Network and security Firewall and gateway support, enabling replication from secured MySQL environments. Support for Azure Database for MySQL servers configured with customer‑managed keys (BYOK), aligning with enterprise security and compliance requirements. Broader data coverage and troubleshooting Ability to mirror tables containing previously unsupported data types, expanding schema compatibility and reducing onboarding friction. Support for up to 1,000 tables per server, enabling larger and more complex databases to participate in Fabric analytics. Basic error messaging and visibility to help identify replication issues and monitor progress during setup and ongoing operations. What scenarios does it unlock? With Fabric integration in place, you can now analyze data in Azure Database for MySQL without impacting production, combine it with other data in Fabric for richer reporting, and use Fabric’s built‑in analytics and AI tools to get insights faster. Learn more about exploring replicated data in Fabric in Explore data in your mirrored database using Microsoft Fabric. How does it work (high level)? Fabric integration for Azure Database for MySQL follows a simple but powerful pattern: Enable and Configure - Enable replication in the Azure portal, then use the Fabric portal to provide connection details and select MySQL tables to mirror. Initial snapshot - Fabric takes a bulk snapshot of the selected tables, converts the data to Parquet, and writes it to a Fabric landing zone. Continuous change capture - Ongoing inserts, updates, and deletes are captured from MySQL binlogs and continuously written as incremental Parquet files. Analytics‑ready in Fabric - The Fabric Replicator processes snapshot and change files and applies them to Delta tables in OneLake, keeping data in sync and ready for analytics. This design ensures low overhead on the source, while providing fresh data for analytics and AI workloads. Below is a more detailed workflow illustrating how this works: Getting started with the Public Preview To try Fabric integration for Azure Database for MySQL during Public Preview, you’ll need: An Azure Database for MySQL instance An active Microsoft Fabric capacity (trial or paid) Access to a Fabric workspace Once enabled, you can select the MySQL databases and tables you want to replicate and begin analyzing data in Fabric. For step-by-step tutorial, please refer to - https://learn.microsoft.com/azure/mysql/integration/fabric-mirroring-mysql The demo video below showcases how the mirroring integration works and walks through the end-to-end experience of mirroring MySQL data into Microsoft Fabric. Stay Connected We’re thrilled to share this milestone at FabCon 2026 and can’t wait to see how you use Fabric integration for Azure Database for MySQL to simplify analytics and unlock new insights. We welcome your feedback and invite you to share your experiences or suggestions at AskAzureDBforMySQL@service.microsoft.com Try the Public Preview, share your feedback, and help shape what’s next. Thank you for choosing Azure Database for MySQL!
Looking for official role-based AI learning paths and Microsoft AI ecosystem diagram
Hello everyone, I am responsible for AI up-skilling at my company, and we are currently building role-based learning paths for roles such as AI Engineer, Data Analyst, Data Engineer, and Data Scientist. I would really appreciate any advice or pointers to official Microsoft resources on the following topics. Q1. Role-based learning paths I am aware of the Microsoft Learn career paths: However, I am looking for the most up-to-date official learning paths or curated guidance that also cover newer services such as: Copilot GitHub Copilot Microsoft Fabric Azure AI Foundry Are there any Microsoft resources that organize recommended learning content by role for these newer areas? Q2. Official Microsoft AI ecosystem diagram I am also looking for an official Microsoft diagram, map, or architecture overview that shows the overall AI ecosystem, including services such as Copilot, GitHub Copilot, Microsoft Fabric, and Azure AI Foundry. As a reference, I am aware of unofficial resource, although it appears to be somewhat outdated: If anyone knows of an official and more recent resource, I would be very grateful. (If direct links are not allowed in replies, page titles or document names would also be very helpful.) Thank you.Announcing GA: Advanced Resource Sets in Microsoft Purview Unified Catalog
The Microsoft Purview product team is constantly listening to customer feedback about the data governance challenges that slow teams down. One of the most persistent pain points — understanding the true shape of large-scale data lakes where thousands of files represent a single logical dataset — has driven a highly requested capability. We are pleased to announce that Advanced Resource Sets are now generally available for all Microsoft Purview Unified Catalog customers. The Problem It Solves Anyone managing a modern data lake knows the clutter: a single partitioned dataset like a daily transaction log might manifest as hundreds or thousands of individual files in Azure Data Lake Storage or Amazon S3. Without intelligent grouping, each of those files appears as a separate asset in the catalog. The result is a flood of noise — a catalog that technically contains your data estate but makes it nearly impossible to reason about it at a logical level. Data stewards end up buried in meaningless entries. Analysts searching for "the transactions table" find thousands of file-level hits instead of one clean, actionable asset. Governance efforts stall because nobody can agree on what the estate looks like. Advanced Resource Sets directly address this by grouping those physically separate but logically related files into a single, representative catalog asset — giving your teams a clean, meaningful view of the data landscape. What Advanced Resource Sets Actually Do The standard resource set capability in Purview already groups files using naming pattern heuristics. Advanced Resource Sets go significantly further, and this is where it gets interesting. Custom pattern configuration allows data curators to define precisely how partitioned datasets should be grouped — whether that is by date partition, region, environment, or any other dimension embedded in your file naming conventions. You are no longer relying solely on out-of-the-box heuristics. Partition schema surfacing means Purview now extracts and displays the partition dimensions themselves as metadata on the resource set asset. Instead of knowing only that "a resource set called transactions exists," your teams can see "that resource set is partitioned by year, month, and region." That is the difference between a data inventory and a genuinely useful data catalog. Accurate asset counts ensure that your catalog's asset metrics reflect logical datasets rather than raw file counts — giving leadership and governance teams a truthful picture of the data estate's scale. Getting Started — Simpler Than You Might Expect Enabling Advanced Resource Sets requires no additional connectors or infrastructure changes. The feature is activated and configured directly within the Microsoft Purview Governance Portal. At a high level: Sign in with an account that has Data Curator role in the default domain. Open Account settings in Microsoft Purview. Use the toggle to enable or disable Advanced resource sets. Define custom pattern rules by going to Data Map -> Source Management -> Pattern Rules Trigger a rescan (or allow scheduled scans to run). Purview will re-evaluate existing assets and collapse file-level entries into properly grouped resource sets with partition schema metadata attached. What You Can Do With It Once configured, Advanced Resource Sets surface in the Unified Catalog alongside all other scanned assets — but now at the right level of abstraction for your data consumers and governance teams. Data discoverability improves immediately. Analysts searching the catalog find logical datasets, not file fragments. They can evaluate partition coverage, understand data freshness based on partition metadata, and make confident decisions about whether an asset meets their needs before requesting access. Governance accuracy follows naturally. Data owners can apply classifications, sensitivity labels, and glossary terms to a single representative asset rather than chasing down hundreds of file-level entries. Ready to enable Advanced Resource Sets in your environment? Head to the Microsoft Purview Portal, navigate to account settings. Full documentation is available at Microsoft Learn: Manage resource sets.
Recovering our Default Azure Directory
Hello, everyone, relative newcomer to Azure here. I'm dealing with an inherited situation and, to add to the fun, I've just discovered my organization only has a Basic support plan, so no access to Azure technical support. I'm hoping some knowledgeable souls on here are in a charitable mood and will point me in the right direction. We're having problems getting to our DNS subscription because it's locked away behind an Azure directory to which we don't seem to have access, and I'm not quite sure this is completely an Azure problem. I was able to get into this directory around a year ago but I so seldomly access it that I'm not sure when this changed. We have two Azure directories. One is our "regular" directory, named for our organization, and it's linked (not sure of the terminology here) to our domain. Let's call it This.Domain.com. There are no subscriptions in this directory. The other is named "Default Directory" and it's linked to an onmicrosoft domain -- let's call it OldAdminThisDomain.onmicrosoft.com. When I try to switch to this directory I'm prompted to log in, then I'm hit with the MFA prompt. This is normally not a problem but it's like the MFA was set up for a different account with the same email address. By contrast, I can log into both the regular Azure directory and the 365 admin page with no problem -- I type in my email address (let's call it email address removed for privacy reasons), MFA comes up, and I have several authentication methods to choose from: Microsoft's MFA app, SMS, email, YubiKey, phone, etc., and all these options work. When trying to log into the Azure Default Directory, however, the MFA acknowledges only either the Microsoft Authenticator app or Use a Verification Code (which also goes through the Microsoft Authenticator app), and neither option yields any prompt on my phone. I seem to recall I effectively had two different "accounts" that somehow used the same email address but had different MFA setups, but again this was around a year and 3 phones ago so I don't have a solid memory of what was happening. I am also aware that, while this should not be permittable, there have been several cases where multiple Microsoft accounts were somehow created using the same email address. So this is where I am. Ideally we could merge the two Azure directories so that we combine the accessibility of the "regular" directory with the subscription(s?) that are in the Default Directory. Barring that I would have to somehow get the (suspected) two Microsoft accounts based on the email address removed for privacy reasons email address corrected. Any help would be greatly appreciated. Thanks to all in advance
PowerShell 7 PnP.PowerShell Header Issue
I am trying to connect to the PnPOnline module using PS7. I am running PowerShell version 7.6.0 (Core), PnP.PowerShell PSEdition Core, and have my PnP PowerShell App registered in Azure I have my top level site as the $siteURL variable, my ClientID number as the $clientID variable and the ClientSecret value as the $clientSecret variable... When using the command Connect-PnPOnline -Url $siteUrl -ClientId $clientId -ClientSecret $clientSecret the following is returned: WARNING: Connecting with Client Secret uses legacy authentication and provides limited functionality. We can for instance not execute requests towards the Microsoft Graph, which limits cmdlets related to Microsoft Teams, Microsoft Planner, Microsoft Flow and Microsoft 365 Groups. You can hide this warning by using Connect-PnPOnline [your parameters] -WarningAction Ignore Connect-PnPOnline: The given header was not found. I have double checked my variables, and all components and still receiving this error. I know there is a certificate method for the App Registration, but what else need to happen to make my connection successful? Or should I go the certificate route for the App Registration?
