A non-technical look at data protection, compliance roles, and why your IT team cares about sensitive information

Somewhere in your organization right now, an employee is emailing a spreadsheet with someone’s home address in it. Another person is sharing a file that contains medical information. Neither of them means any harm; they just don’t know. That’s the problem Microsoft Purview is designed to solve.

Two foundational things have to happen before any of this works: the right people need to be in charge of data protection, and the system needs to be taught what “sensitive” actually looks like. Neither happens automatically when you buy a Microsoft license.

Giving the right people the keys

Before any data protection tool can do its job, someone has to be accountable for it. In many organizations, it’s genuinely unclear who owns data security versus IT versus legal compliance. Microsoft formalizes this by assigning administrative roles and permissions that define exactly what a person can see and change inside the system.

Real-world analogy: Giving someone the Compliance Administrator role is like handing them the master binder for your regulatory paperwork; they can read everything, set policies, and run audits, but they can’t change payroll or hire people.

Application Administrator: Manages software applications connected to your Microsoft account, including how Purview connects to other tools your business already uses.

Compliance Administrator: Sets and manages data compliance policies. This is the person responsible for ensuring the organization complies with laws such as GDPR (Europe’s data privacy law) and HIPAA (US healthcare data law).

Security Administrator: Manages security settings across the Microsoft environment. Detects threats, sets access rules, and reviews alerts when something looks wrong.

How it gets set up

1. A global administrator opens the Microsoft 365 Admin Center and finds the user being assigned a role.
2. The specific roles are selected and saved. The user now has access to exactly the parts of the system their role covers.
3. The newly assigned administrator logs into Microsoft Purview and begins configuring data protection settings for the organization.

Teaching the system what “sensitive” looks like

Once the right people are in charge, the next step is teaching Purview to recognize sensitive data before it goes somewhere it shouldn’t. This is done through sensitive information types rules that describe patterns the system watches for across emails, documents, and files.

Pattern matching and Exact Data Match

EDM (Exact Data Match) goes beyond pattern recognition. Instead of flagging anything that looks like an employee ID, you upload your actual employee database so the system only alerts on genuine matches. A product code formatted like “ABC123456” won’t trip the wire; only real employee records will.

Real-world analogy: Like training a mail room worker to hold any envelope with a Social Security number on the outside. They don’t read the letter; they just recognize the pattern and escalate it.

How it gets set up

1. The administrator defines the pattern and supporting keywords that confirm a real match, for example, three uppercase letters and six numbers near the word “Employee.”
2. For EDM, the actual employee database is exported and hashed into an unreadable format, then uploaded so the raw data never lives inside Microsoft’s systems.
3. Keyword dictionaries are added for language-based detection of disease names and absence terminology so the system flags context, not just isolated words.
4. Everything is tested against sample content before being used in a live policy.

Why false alarms matter: If the system flags hundreds of harmless documents daily, employees start ignoring alerts entirely. EDM keeps the signal meaningful.

Putting a label on it, literally

Detecting sensitive data is one thing. Actually doing something about it is another. Sensitivity labels are tags applied to documents and emails that travel with the file wherever it goes and trigger real protections: encryption, watermarks, access restrictions, and more.

Real-world analogy: Think of a label like a classification stamp on a physical document: “Confidential,” “Internal Use Only.” Except this one also locks the filing cabinet, tracks who opens it, and prevents unauthorized copying.

Labels are grouped by category to keep things manageable:

Each has different levels of protection depending on how sensitive that type of information is.

Auto-labeling: no human required

Auto-labeling applies labels automatically based on content; no employee decision needed. If a document contains a credit card number or bank routing number, it gets the “Financial Data” label before anyone has to think about it.

Double Key Encryption: for the highest-stakes content

DKE (Double Key Encryption) means your organization holds one key and Microsoft holds another. Both are required to open the file, so even Microsoft cannot read the content. Combined with a dynamic watermark showing who opened a document and when, this is the highest level of protection available.

Real-world analogy: It’s like a safe deposit box at a bank. The bank has one key, you have the other. Neither of you can open it alone.

How it gets set up

1. Label groups and child labels are created with specific protection settings: encryption, watermarks, and access restrictions per label.
2. Auto-labeling policies run in simulation first, showing what would have been labeled without changing anything, before enforcement goes live.
3. Labels are published to users through label policies. The Confidential Legal label requires written justification before anyone can remove or downgrade it, creating an audit trail for every classification change.

Protecting email at the source

A lot of the most sensitive information in any organization travels by email, and email is easy to forward, screenshot, or accidentally send to the wrong person. Microsoft Purview Message Encryption closes this gap automatically, without changing how employees work.

Real-world analogy: Sending an unencrypted email is like mailing a document in a clear plastic envelope; anyone handling it along the way can read it. Encryption puts it in a sealed, locked box. Only the person with the key can open it on the other end.

A mail flow rule runs silently on every email from the Finance department. When someone in Finance sends an email, it’s encrypted, and a disclaimer is appended automatically. The Finance team sends emails exactly as they always have; they don’t press an “encrypt” button or change their workflow at all.

What the recipient sees from outside the organization:

Encrypted message This message is protected. Sign in or use a one-time passcode to read it. This email has been encrypted and sent securely by Contoso Ltd.

How it gets set up

1. The administrator creates a mail flow rule in the Exchange Admin Center, the control panel for company email, targeting the Finance department group.
2. Encryption and a disclaimer are configured as automatic actions on every matching outbound email.
3. The rule is enabled. Finance staff sends email exactly as before; the protection applies without any change to their workflow.

Stopping sensitive data before it leaves, DLP policies

DLP (Data Loss Prevention) is the enforcement layer. Where labels describe what data is, DLP controls what can be done with it. Policies watch for sensitive content moving through Teams, email, files, and cloud storage and act when they find it.

For example: when someone tries to send a credit card number to a person outside the organization, they see a policy tip:

Policy tip This message appears to contain a credit card number. Sharing this information outside the organization may violate company policy. [Override with justification] [Don’t send]

The override matters. DLP isn’t designed to be a brick wall; it’s designed to catch accidents and make people pause. A salesperson who genuinely needs to share payment information can still do it. They just have to acknowledge why, and that acknowledgment is logged.

Testing before enforcing, simulation mode

Before a policy goes live, it runs invisibly in the background, scanning the same content it would enforce against and showing administrators what it would have caught. This prevents a poorly tuned policy from generating hundreds of false positives and drowning the security team in noise.

How it gets set up

1. A DLP policy is created by selecting which channels to cover: Teams, Exchange, SharePoint, OneDrive, or a combination.
2. Rules define triggers and actions that block external sharing, notify the user, and require justification to override.
3. The policy runs in simulation first. The team reviews match rates before activating enforcement.
4. Policy priority determines which policy wins when multiple policies fire on the same content simultaneously.

When the threat is physical, endpoint DLP

Cloud DLP protects data as it moves through digital channels. Endpoint DLP extends protection to company devices. An employee plugging a USB drive into a company laptop and copying files is one of the most common ways sensitive data leaves organizations. Not through a sophisticated attack, but through a thumb drive in a pocket.

Real-world analogy: Cloud DLP is like a security guard at the building’s email server checking every message that goes out. Endpoint DLP is a guard standing next to every desk, watching what employees plug in and copy to physical media.

Endpoint DLP can control:

• USB drives: Block copying sensitive files to removable storage
• Browsers: Restrict which browsers can upload sensitive content
• Cloud services: Block uploads to specific domains like personal Dropbox accounts
• File paths: Exclude specific folders from scanning for approved use cases

When an employee tries to copy a file containing a Social Security number to a USB drive, the transfer is blocked, and they see a notification explaining why.

How it gets set up

1. Devices are onboarded by running a script that registers them with the organization’s Microsoft tenant and joins them to Microsoft Entra ID, the organization’s identity system.
2. A DLP policy targeting Devices is created, specifying which sensitive information types to watch for and what to block.
3. Additional settings are configured: permitted browsers, blocked cloud domains, and folder exclusions.
4. The policy runs in simulation, then activates automatically after a set period if no changes are made, removing the risk of a policy being forgotten before it’s ever enforced.

Note on browsers: For DLP policies to work in Chrome, the Microsoft Purview Extension must be installed on each device. Microsoft Edge has this built in. Chrome requires a one-time install.

How long to keep data and when to delete it

Keeping data longer than necessary isn’t just wasteful; it’s a liability. Every record your organization holds is a potential target. On the other hand, deleting records too soon can create legal risk if that data is needed in an audit or investigation.

Real-world analogy: Think of it like a records room with a filing system. Each folder has a label that says when it was created, how long it needs to be kept, and what happens when that time is up: shredded, archived, or handed to legal. Purview’s retention policies are built into the system and run automatically across every file, email, and message in your Microsoft environment.

Retention labels: tagging individual records

A retention label governs lifespan. A financial records label might say: keep this file for five years from the last time it was modified, then delete it automatically. Once applied, the system tracks the clock and handles cleanup without any further human involvement.

The lifecycle of a labeled file:

Why automatic deletion matters: Most organizations don’t delete old data not because they want to keep it, but because no one has a process for cleaning it up. Retention policies remove that gap.

Two ways to apply retention labels

Labels can be applied manually by employees, or automatically through auto-apply policies that watch for specific sensitive information types, the same patterns used by DLP. An employee creating a spreadsheet with bank account numbers doesn’t need to think about retention rules; the policy handles it.

Retention policies at scale

Retention labels work record by record. Retention policies apply rules at scale covering entire platforms in one go. A Teams retention policy can cover every chat message and channel post across the organization: keep them for 3 years, then automatically delete them. No one tags individual Teams messages.

Targeted retention for sensitive groups

Not every department should have the same retention rules. Adaptive scopes let you target retention policies at specific groups Leadership and Operations, for example rather than the entire organization. If someone joins or leaves those groups, the policy follows them automatically.

How it gets set up

1. A retention label is created defining the lifespan and what happens at the end: delete automatically or trigger a review.
2. The label is published to users, making it available as a manual option in Exchange, SharePoint, and OneDrive.
3. An auto-apply policy scans for specific sensitive information types and automatically applies an existing label.
4. The auto-apply policy runs in test mode first, before full enforcement begins.
5. For targeted retention, an adaptive scope is created defining which groups to cover, and a separate retention policy is built using that scope.

When the risk comes from inside insider risk management

Every layer of protection covered so far assumes a relatively clear boundary: sensitive data should stay inside the organization. But some of the most damaging data incidents come from people who already have legitimate access: employees, contractors, or privileged users whose behavior shifts in ways that suggest risk.

Insider Risk Management doesn’t treat every employee as a suspect. It watches for patterns of behavior that, taken together, suggest something worth investigating. A single unusual action rarely means anything. A sequence of them might.

Real-world analogy: Think of it like a bank’s fraud detection system. Your card isn’t blocked because you made one purchase in a new city. It flags when you make an unusual purchase, then a cash withdrawal, then another purchase abroad all within an hour. No single action is the problem. The pattern is.

What the system watches for

Insider Risk Management draws on signals across Microsoft 365 and Microsoft Defender for Endpoint:

• File exfiltration: Unusual volume of downloads or uploads outside normal patterns
• Risky browsing: Visits to sites associated with data theft or policy violations
• Office activity: Mass deletion or accessing files outside normal scope of work
• Defender alerts: Device-level threats, malware, disabled protections, defense evasion

Not all employees carry equal risk.

Some employees have access to significantly more sensitive information than others. Priority user groups let administrators define which employees warrant closer monitoring: finance teams, legal staff, executives, because the potential impact of a breach involving their data is higher.

An important distinction: Insider Risk Management is not surveillance. It correlates signals that already exist across Microsoft 365 and Defender actions the system was already recording for other purposes and looks for patterns that warrant human review. A compliance investigator still makes the call on whether an alert represents a real incident.

How it gets set up

1. The administrator is granted the Insider Risk Management role in Microsoft Purview.
2. Policy indicators are turned on, selecting which behavioral signals to watch for: file exfiltration, risky browsing, Office activity, Defender alerts.
3. Defender for Endpoint integration is enabled so device-level security alerts feed into insider risk profiles.
4. Policies are created: quick templates for common scenarios like data leaks, or custom policies for priority user groups.
5. Priority user groups are defined, specifying which employees receive closer monitoring and who on the security team can view their activity data.
6. Notice templates are created so when an alert is investigated, the team has a consistent, pre-approved message ready to send.

When risk scores change how security rules behave, adaptive protection

Every tool covered so far applies the same rules to everyone. A DLP policy treats the cautious long-tenured employee the same as someone whose behavior has already raised red flags. Adaptive Protection closes that gap by connecting insider risk scores directly to enforcement controls.

Instead of fixed rules that apply uniformly, protection tightens automatically when an employee’s risk level rises and relaxes when it returns to normal.

Real-world analogy: Think of it like a building access system that gives most employees standard badge access. But if someone is under active investigation, their badge quietly stops working on the server room door: no confrontation, no announcement, just reduced access while the situation is reviewed.

What changes at each risk level

The Conditional Access piece

Conditional Access is a feature in Microsoft Entra ID, Microsoft’s identity platform that controls who can sign into what, and under what conditions. When integrated with insider risk, it can block access to all company resources for elevated-risk users until their risk level drops. This typically starts in report-only mode so the security team can validate the policy before it goes live.

How it gets set up

1. An insider risk policy is linked to Adaptive Protection; this tells the system which policy’s risk scores should drive enforcement changes.
2. The existing DLP policy is updated with a new condition: if the user has an elevated insider risk level, block sharing entirely rather than allowing override with justification.
3. A Conditional Access policy is created that blocks all system access for elevated-risk users, starting in report-only mode.
4. Adaptive Protection is switched on. Enforcement adjusts automatically as users’ risk scores change.

Proving it all happened, the audit log

Every tool in this article is only as credible as the record it leaves behind. A DLP policy that blocked a sensitive share, a label that was stripped from a document, a security rule that was quietly changed none of that means anything in an investigation or regulatory audit unless there is a timestamped, tamper-resistant record showing exactly what happened, when, and who was responsible.

Real-world analogy: Think of it like the black box on an aircraft. While everything is running normally, nobody’s looking at it. But when something goes wrong or when a regulator asks what happened, it’s the definitive record of every action taken.

What gets recorded

A sample audit log entry:

The problem with default retention

By default, Microsoft retains audit logs for 180 days. For many compliance frameworks, that isn’t enough. Regulatory investigations often look back a year or more. Audit retention policies extend how long specific categories of logs are kept. DLP matches across email, SharePoint, and endpoint devices can be preserved for a full year or longer.

How it gets set up

1. The administrator opens the Audit solution in Microsoft Purview and configures a search, selecting a date range, activity types, and a name for the search.
2. Results are reviewed and exported to a file for offline review or sharing with external auditors.
3. An audit retention policy is created specifying which record types to preserve and for how long.

When something has already gone wrong, content search

Every tool covered so far is preventive. But sometimes an alert arrives after the fact. A potential breach is reported. A regulator asks whether specific data was exposed. The question shifts from “how do we prevent this” to “what actually happened.”

eDiscovery (electronic discovery) searches through an organization’s digital content, emails, chats, files, and SharePoint sites to find specific information relevant to an investigation. It works in minutes across the entire Microsoft 365 environment.

Real-world analogy: Think of it like a legal discovery process the phase of litigation where each side must produce relevant documents. Except instead of lawyers sorting through filing cabinets for weeks, the search runs in minutes and returns every matching item across every mailbox, Teams conversation, and SharePoint site the organization has.

A content search for financial data exposure might target keywords like “bank account” and “credit card” across all Finance team content, returning every email, document, and Teams message where those terms appear, showing who created it and when.

Access control matters here too: The eDiscovery Manager role grants this capability to specific, trusted individuals, keeping investigative access controlled and auditable, just like the administrative roles discussed at the start of this article.

How it gets set up

1. The administrator grants the investigator the eDiscovery Manager role.
2. A case is created in Microsoft Purview to contain and document the investigation.
3. Data sources are added to scope the search: specific users, groups, or sites.
4. Keywords are entered, and the query runs. Results show where terms appeared, in what context, and who created the content.

The newest frontier, protecting data in AI

Every data protection challenge described in this article existed before AI tools arrived in the workplace. AI introduces the same risks through a new interface. When an employee pastes a client contract into ChatGPT to ask for a summary, or types a customer’s financial details into Microsoft Copilot as context for a question, that data leaves the controlled environment.

Real-world analogy: Every data protection rule that applies to a shared drive also applies to what you feed an AI assistant; it just hasn’t felt that way yet because the interface looks like a conversation rather than a file transfer. But from a data governance perspective, pasting a payroll spreadsheet into a chatbot is the same risk as emailing it to the wrong person.

DSPM for AI (Data Security Posture Management for AI) addresses four risk categories:

• Sensitive data in prompts: Employees pasting confidential information into AI tools
• Risky AI interactions: Copilot usage patterns that suggest data exfiltration risk
• Unethical behavior: Policy-violating content in prompts or AI-generated responses
• Unlabeled content exposure: Files without sensitivity labels that Copilot could surface in responses

Blocking sensitive data at the AI interface

A DLP policy watches what employees paste or upload into generative AI websites. When it detects sensitive content, it blocks the action before the data reaches the AI tool. This policy connects directly to Adaptive Protection; a normal-risk employee might see a warning with an override option; an elevated-risk employee gets a hard block.

The labeling gap that AI exposes

Copilot is good at surfacing relevant content; ask it about a client, and it pulls emails, documents, and notes from across SharePoint and OneDrive. That’s useful. It’s also a problem if some of those documents are sensitive but unlabeled. A data risk assessment scans SharePoint for files without sensitivity labels that Copilot could surface, generating a prioritized list of labeling gaps to close.

How it gets set up

1. A DLP policy is created from DSPM for AI recommendations, blocking sensitive content from being pasted into generative AI websites with stricter enforcement for elevated-risk users through Adaptive Protection.
2. An insider risk policy using the Risky AI Usage template monitors Copilot interactions, tracking risky prompts, sensitive responses, and browsing to AI sites.
3. A communication compliance policy detects unethical or policy-violating content in Copilot prompts and responses.
4. A data risk assessment runs against SharePoint to identify files without sensitivity labels that Copilot could expose, generating a prioritized list of labeling gaps to close.

Does any of this actually work?

Configuring policies is one thing. Knowing they fire correctly in the real apps employees use every day is another. Every data protection system has the same failure mode: settings that look right in an admin portal but don’t translate into actual behavior when a real person opens Word, sends an email, or clicks on a document in SharePoint.

Sensitivity labels in Word

Opening a Word document and confirming that sensitivity labels are visible and selectable proves label propagation worked. Applying an HR label to a document should immediately trigger the configured protections: the watermark stamped across the page, the header and footer added to every page, and the document encrypted.

Trying to downgrade the label to something less restrictive should trigger a justification dialog. If that dialog never appears, the policy isn’t working, and the only way to know is to test it.

DLP policies in Outlook

Sending an email containing employee IDs to confirm that the DLP policy blocks it proves the difference between a policy that exists and one that enforces. If the policy is working, the email never arrives. The sender receives a delivery failure notification explaining the message was blocked by a data loss prevention policy.

This single test confirms three things: the sensitive information type is correctly configured, the DLP policy is active and applied to Exchange email, and the rule condition matches the correct pattern.

Retention and sensitivity labels in SharePoint

When navigating to a document in SharePoint and opening its details panel, both the sensitivity label field and the retention label field should be displayed. Applying both confirms the full lifecycle is covered: the document is classified as confidential, and the retention policy knows how long to keep it before automatic deletion.

Why this step matters for the business

Most data protection implementations stop at configuration. Policies get created, someone checks a box on a project plan, and the assumption is that everything is working. Validation challenges that assumption with evidence.

For a compliance team presenting to leadership or preparing for a regulatory review, the difference between “we configured these policies” and “we tested these policies and confirmed they behave as expected” is significant. The first is a claim. The second is a demonstration.

The complete picture

Microsoft Purview isn’t a single tool; it’s a set of overlapping controls that address the full data protection lifecycle. Classify the data. Protect it in transit. Control what employees can do with it. Monitor behavior for signs of risk. Tighten enforcement automatically when risk rises. Record every action for accountability. Search the record when something goes wrong. Extend all of that to AI. And then test it because a policy that hasn’t been validated is just a policy on paper.

None of these layers is sufficient on its own. A DLP policy without good sensitive information types fires on the wrong things. Labels without retention policies leave data sitting around indefinitely. Insider risk monitoring without audit logs can’t support an investigation. The value of the platform is in how the pieces connect, each one making the others more effective.

The organizations that implement this well don’t do it all at once. They start with the foundations, get roles right, define what sensitive means, publish labels, and build from there. The goal isn’t a perfect system on day one. It’s a system that improves continuously, leaves a defensible record of every step, and gets tested regularly enough that when someone asks if it works, the answer is yes and there’s proof.

Cloud infrastructure security is a battle for identity control. Current threat landscapes prioritize exploiting Azure-specific misconfigurations and authentication weaknesses.

Identity Exploitation and Phishing

Attackers use Evilginx to establish man-in-the-middle positions, capture session tokens, and bypass Multi-Factor Authentication (MFA). By configuring glue records to resolve phishing domains to attacker-controlled infrastructure, adversaries deliver convincing lures via phishlets.

The Device Code flow (/devicecode endpoint) is a primary vector for phishing campaigns, providing verification URIs that bypass traditional security boundaries. Primary Refresh Tokens (PRTs) are targeted via the TPM (Trusted Platform Module) using tools like ROADToken to emulate browser sessions and maintain persistent access.

Infrastructure and Resource Access

Excessive permissions facilitate lateral movement. The Contributor role on an Azure Key Vault provides sufficient privilege to modify access policies and extract secrets.

Tools such as Microburst automate the dumping of storage keys from Azure Storage Accounts.

Cloud compute resources present a significant risk:

• Virtual Machines: Administrator-level access allows password resets and arbitrary command execution.
• Container Registries (ACR): Images that are improperly secured often contain sensitive data or secrets. Mitigate this by scanning images before push and deleting compromised images immediately.
• ARM Deployments: Secret fields in deployment templates often contain plaintext strings accessible to unauthorized entities.

Persistence and Lateral Movement

Adversaries establish a long-term presence by elevating the privileges of a Logic App-managed identity. AADConnect is a high-value target; tools like AADInternals extract credentials to move from on-premises environments into the Azure cloud.

Compromising ADFS (Active Directory Federation Services) allows for the extraction of token-signing certificates. Attackers use these to craft SAML tokens that impersonate any user. Similarly, Seamless SSO vulnerabilities enable MFA bypass and direct management portal access via Kerberos TGS ticket crafting.

Reconnaissance and Misconfiguration

Userrealm discovery (/GetUserRealm.srf) identifies whether domains are managed or federated, informing the attack strategy. Subdomain takeover occurs when DNS records point to unassigned Azure resources, allowing attackers to serve malicious content.

You can test your own domain’s federation status by navigating to: https://login.microsoftonline.com/getuserrealm.srf?login=user@yourdomain.com&xml=1

Executive Summary: Financial and Legal Reality

Security testing is not a technical chore; it is a financial insurance policy.

The 2026 Risk Landscape

• Total Loss: The global average cost of a data breach has reached $4.88 million. In the United States, this surges to $10.22 million per incident.
• The Time Tax: Breaches caused by stolen credentials are the primary focus of this testing, and they take the longest to find. Identifying a breach in under 200 days saves your company $1.4 million in recovery costs.
• Cloud Vulnerability: 83% of organizations reported a cloud-related breach in the last 18 months. Identity-based attacks are the leading cause.
• C-Suite Liability: Under NIS2 and DORA regulations, executives now face personal liability and massive corporate fines for failing to implement “adequate risk management,” which includes proactive penetration testing.

Strategic Outcomes

1. Validation of MFA: Proves whether your $1M+ identity investment actually stops a $50 phishing kit.
2. Data Sovereignty: Locates plaintext secrets in ARM templates and Storage Accounts before they appear on the dark web.
3. Brand Resilience: Stops subdomain hijacking before your official URL is used to distribute malware.

Phase 1: Initial Access and Discovery

The attack began with a phishing attempt. By analyzing the Email Entity tab and the Email Preview, I identified the sender and the primary target.

• Sender: jonis@vnevado.alpineskihouse.co
• Target Persona: The email targeted Polly W, the Managing Director and Head of Cybersecurity at Contoso Electronics Management.
• Malicious Link Behavior: In the sandbox view (Email Entity -> URL -> Export), the provided link was flagged for suspicious Navigation behavior properties.

Phase 2: Host Compromise

Once the link was interacted with, the first device was compromised. I tracked the activity via the Device Timeline.

• Compromised Device ID: 31a048e5eea6ad6e6bc025bfa9e0e571c4c20f7e
• The Payload: A PowerShell script named .\Midnight124.ps1 was executed.
• Account Context: The script was run by the user kdickens@niseko.alpineskihouse.co.

Phase 3: Credential Harvesting and Deception

Once it gained a foothold, the attacker focused on escalating privileges.

• Exposed User: I identified pgustavo as the exposed user on the device.
• Privilege Level: A check of group memberships revealed that pgustavo was a member of Domain Admins, Domain Users, and Administrators.
• Deception: Interestingly, a deception account stevem was present on the device, intended to lure attackers into interacting with fake credentials.

• LSASS Access: The attacker used Mimikatz to dump memory and access LSASS. The source for this tool was a GitHub repository:

  BE CAREFUL https://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/master/Invoke-Mimikatz.ps1.

• Execution Method: The script was loaded directly into memory to evade disk-based detection.

Phase 4: Lateral Movement and DCSync

With Domain Admin credentials (pgustavo), the attacker moved toward the Domain Controller to perform a DCSync attack.

• The Attack Tool: A script located at C:\Script\ContosoADFSadmincreds.ps1 triggered the DCSync.
• Command: Invoke-Mimikatz -Command "$arg"
• Lateral Movement: The attacker utilized Invoke-SMBExec to move across the network. This tool created a temporary service named MNCKQWHNSJQWLYBWCJBT on remote machines to execute code.

Phase 5: ADFS Certificate Theft

The ultimate goal of on-premises was to extract Active Directory Federation Services (ADFS) tokens.

1. Preparation: A script C:\Scripts\RenamePowershell.ps1 was executed, followed by the creation of a scheduled task: Run-ExportADFSTokenSigninCert.[Timestamp].
2. Execution: The task triggered a binary (1yc3fegs.0uy.exe) that executed a Base64 encoded command. Decoded, this revealed: C:\Scripts\ExportADFSTokenSigninCert.ps1.
3. Extraction: The script used LDAP queries to extract the secret and created a file named ADFSTokenSigningCertificate.pfx.
4. Exfiltration: The certificate was uploaded to Azure Blob Storage.
5. Remediation: Evidence showed the scheduled task was eventually remediated using the LiveResponseCommand (specifically the ad command).

Phase 6: Cloud Impact and Persistence

The theft of the ADFS certificate allowed the attacker to bypass traditional authentication in the cloud.

• MFA Bypass: Logins showed the MFA method MfaDoneAtExtIdP, indicating the attacker used the stolen certificate to claim MFA was already completed by the external Identity Provider.
• Persistence: The attacker added a delegated permission grant to an application named SimulandApp.
• Secret Injection: A new secret named SimuLand2023_RiAdb was set for the application.
• Data Access: Finally, the investigation confirmed the attacker accessed user data, evidenced by MailItemsAccessed logs.

Executive Briefing

The “Midnight” breach was not a simple malware infection; it was a targeted Identity Attack designed to bypass our most expensive security controls, including Multi-Factor Authentication (MFA). By moving from a single workstation to the heart of our identity infrastructure (ADFS), the attacker gained the ability to impersonate any user within our cloud environment.

The Business Risk Breakdown

The following table translates the technical discovery from the Microsoft CCP Blue Team CTF into specific business risks.

Critical Failure Point: The ADFS Compromise

The most significant business impact occurred when the attacker stole the ADFS Token Signing Certificate.

In plain terms, ADFS is the “Passport Office” for our company. By stealing the signing certificate, the attacker effectively stole the official government stamp. They could then create their own “passports” (authentication tokens) to enter our Microsoft 365 environment. This allowed them to bypass MFA because our cloud system believed the “Passport” was already verified by a trusted authority.

Strategic Lessons for the C-Suite

1. Identity is the New Perimeter: The firewall did not stop this. The attack lived and died by the compromise of the pgustavo account. Protecting high-privilege identities is our primary defense.
2. MFA is Not a Silver Bullet: Because the attacker compromised the Identity Provider (ADFS), they were able to signal to the cloud that MFA was already “Done at Extension.” You must move toward “Phishing-Resistant” MFA (like FIDO2/Passkeys).
3. Modernizing Identity: This incident proves that legacy on-premises identity tools (such as ADFS) are high-value targets. Migrating to a cloud-native identity model (Microsoft Entra ID) reduces the “on-premise footprint” that attackers can exploit.

Next Steps for Resilience

• Audit High-Privilege Accounts: Reduce the number of Domain Admins to the absolute minimum.
• Deception Technology: The presence of the stevem honey-pot account was a successful detection signal; you should expand the use of “Canary” accounts to catch attackers early.
• Incident Response: Confirmed remediation of the scheduled tasks, but a full rotation of the ADFS certificates is mandatory to ensure the attacker is completely locked out.

The hackathon at Westlake Brewery featured inclusive app development and unique tasks, such as spinning a challenge wheel. A memorable challenge was telling the story behind Oktay Sari’s nickname, the “Dutch Cowboy.”

During the hackathon, I was panicking—my team was mostly security-driven, and I didn’t know where to start. Our captain, Ugur Koc, had a clear plan: build a website with an AI chatbot that matches users based on their time zone, communication style, and work habits. The chatbot answers queries like, ‘How well do I work with Artist?’ or gives advice on adapting to different team styles.

1. Ugur introduced the T3 app, a tool that helps build the website’s frontend (the part users see and use) using programming languages suitable for both server-side and client-side development.

2. For the AI agent, we used OpenAI tools to enable chatbot functionality. To store users’ preferences, we set up a PostgreSQL database and managed it through Supabase, a platform that makes it easier to use the database online.

3. The team decided that all participants should log in using their hackathon credentials via Entra ID (an identity service). We requested permission to register the app, specifying that it should function as a single-page application.

4. We enabled Row-Level Security (RLS) for the database, so only authenticated users could enter their own data and only view information belonging to other users, ensuring data privacy and security.

5. Bought a domain named big-corporation.org.

Overall, I learned a lot, got valuable career advice, and felt more confident by the end. After we wrapped up, the event transitioned to presentations and awards. The energy carried over as the conference continued with more sessions and learning opportunities.

And here is a screenshot of the app/website

At the end of the event, we won first place! The team decided I should take home the golden clippy, which was a great way to conclude the hackathon and move into the next phase of learning at the conference.

Day 1

We started the opening with actual ninjas! I was surprised and out of breath watching the flip and do sword play.

Linkedin Post

Navigating the New Frontier: Embracing Cloud-Native and AI for Enhanced Security and Productivity

This talk was about how Copilot can integrate with Intune to make workflows more efficient. Some of the things that piqued my interest and I learned about were:

1. The Copilot agent can be used as a change review assistant. It analyzes your change request and provides recommendations based on it; for example, if you request adding a firewall rule, the agent could say, ‘Hey, this might break such and such.’

2. Use the agent to offboard BYODs from inactive Entra ID users in the tenant.

3. There will be a dashboard that explains to admins what the agent wants to do, and you or other admins can approve or deny the tasks.

4. The agent will not have its own separate permissions; instead, it will execute any tasks you approve or automate on your behalf.

https://techcommunity.microsoft.com/blog/microsoftintuneblog/whats-new-in-microsoft-intune-at-ignite/4471043.

Brains, Bloopers, and Bytes: The Fun Side of Neurodiversity/Neurodegeneration in Tech

Somesh Pathak’s openness about Parkinson’s Disease resonated with me, as I also have ADHD, and public speaking gives me anxiety. I admired his bravery, and his friends surprised him with gifts and a cake.

The interaction was very wholesome, and it resonated with me. I hope to experience that level of support from friends one day.

https://github.com/mobilejon/WorkplaceNinjasUS/blob/main/Brains%2C%20Bloopers%2C%20and%20Bytes.pptx

DIY Intune Tools: PowerShell + Graph = Admin Superpowers

In this session, I learned how Ugur Koc and Jannik Reinhard built tools using PowerShell and the Graph API to streamline security tasks.

Everything in Intune uses Graph AP. Every button click, every data point you see in the Intune portal is powered by Microsoft Graph behind the scenes.

The graph API structure is`graph.microsoft.com/[version]/[resource]?[parameters]`

While v1.0 is officially supported, beta endpoints provide much more data and functionality. Most of the Intune portal itself uses beta endpoints.

There are three Ways to discover API endpoints:

1. Microsoft Graph Explorer(`developer.microsoft.com`) - Test queries, see raw data, and generate code snippets
2. Browser Developer Tools - Open Network tab (F12), perform actions in the portal, and copy the exact API calls
3. Graph X-Ray browser extension - Automatically generates PowerShell code from your portal actions

Some authentication best practices for scripting in PowerShell:

1. Managed Identity(best for Azure resources) - No secrets, lifecycle tied to resource, most secure
2. Service Principal with Certificate- For non-Azure environments
3. User Authentication- Only for local, one-off scripts

Managed identities can’t have permissions added via the Azure portal UI - you must use PowerShell scripts to assign Graph permissions.

Use PowerShell SDK when:

1. You need quick, simple authentication.

2. Token refresh automation is important.

3. You’re comfortable managing module dependencies.

Use native Invoke-RestMethod when:

1. You want to avoid PowerShell module management nightmares.

2. Running in environments with module conflicts

3. Need maximum portability across systems.

Never install the full Microsoft.Graph module - it’s massive and nearly impossible to update. Only install specific modules, such as Microsoft.Graph.Authentication. The Graph API limits responses to ~100 objects; you must handle pagination for larger datasets. In Azure Automation Accounts, create custom runtime environments with preloaded modules to avoid reinstalling dependencies on every run.

For MSP/Multi-Tenant Environments, use Azure Lighthouse to:

1. Deploy runbooks across multiple client tenants.

2. Centrally manage automation at scale.

3. Configure tenant-specific permissions

4. Execute scheduled tasks across your entire customer base.

Don’t build from scratch. Search the community first. About 80% of automation needs have already been solved by someone else. MVPs, GitHub repositories, and community blogs are goldmines of ready-to-use solutions:

1. IntuneAutomation.com - 35-40 ready-to-use scripts with “Deploy to Azure” functionality

2. Open source templates - Remediation scripts, detection scripts, notification templates

3. Graph X-Ray - Browser extension for automatic code generation

4. IntuneChange.com - Track and visualize configuration changes over time

https://github.com/mobilejon/WorkplaceNinjasUS/blob/main/DIY%20Intune%20Tools%20PowerShell%20GraphAdmin%20Superpowers.pptx

Break/Side-quests

I met Mona, who introduced me to other MVPs, which led me to connect with them. We all sat around the table, and some gems were shared:

1. Your Resume Should Tell a Story, Not Check Boxes

2. ATS Systems Won’t Get You Hired, People Will

3. Stop Performing, Start Being Authentic

4. Your “Why” Matters More Than Your Certifications

5. Honor Your Past, Don’t Hide It

The last session of day one was the Women in Tech Panel, where I learned the background of Esther Barthel, Mona Ghadiri, Ewelina Paczkowska, and Lavanya Lakshman. One thing I remember from this panel was how Ewelina had signed up for a SQL class in high school. Upon entering the room, there were 20-25 boys, and because it made her nervous, she never took the class because she was the only girl there. In a male-dominated space, I understand how small you can feel as a woman.

Day 2

The day started with the talk ‘The Everywhere Desktop: Secure productivity on any device with the Windows Cloud’, which discussed the use of AI and AVD together. I don’t have any notes for this talk, but here are the PowerPoint slides used.

Link to slides:

1. https://github.com/mobilejon/WorkplaceNinjasUS/blob/main/Ninja%20US%20Keynote%20-%20Windows%20Cloud.pdf

2. https://github.com/mobilejon/WorkplaceNinjasUS/blob/main/Ninja%20US%20Keynote%202%20-%20Frontier%20Firms%20-%20Powering%20the%20Future%20with%20AI%E2%80%91Enabled%20Cloud%20PCs%20and%20Windows%20365%20for%20Agents.pdf

Side-quests

I wanted more guidance on my career path and what I want to do, so I decided to book two 1:1 sessions with Fabian Bader and Ugur Koc. I was able to ask Fabian questions ‘What signals differentiate a junior who scripts tasks from a mid-level engineer who designs automation systems?’ and ‘How does he decide which Azure and M365 security controls to automate first in an enterprise environment?” All questions are meant to give me a little insight into how to grow strategically into a mid- to senior-level position. How can I identify intuitively and improve on what I was yesterday? He gave me wonderful advice and made me realize I want to continue moving forward with cloud security, with DevSecOps & Security Automation as my main focus. My talk with Ugur was about how to start creating automation tools like his, and the main thing I should focus on is APIs.

Tenant Tetris: Stacking securely with Microsoft Defender MTO

I had never heard of MTO before this talk, and I remember it because it inspired me and left me with some good nuggets.

Managing multiple Microsoft Defender tenants creates three core challenges: context switching between tenants (like playing multiple Tetris games simultaneously), configuration misalignment across environments, and scale issues when managing dozens or hundreds of tenants simultaneously.

Instead of creating separate incident queues for each tenant, organize your SOC by squad specialization and severity levels. This approach maintains consistent psychological standards of care for all clients and lays the foundation for AI-powered workflow automation.

Remove humans from the permission-granting loop by implementing configuration-as-code for access control. Build multi-layered fail-safe controls using conditional access policies at both the service provider and client tenant levels, combined with unified RBAC in Defender.

Create a centralized repository (monorepo) to manage detections, policies, onboarding procedures, and permissions across all tenants.

Use a parameters database to store tenant-specific variables, preventing hard-coded values in detection logic and enabling scalable change management.

1. Never hard-code values into detection rules; use parameter files instead.

2. Be generous with matching logic (use “is not empty” rather than exact values).

3. Design detections to gracefully handle missing fields or tables when connectors fail.

While MTO provides multi-tenant visibility and shared incident queues, Microsoft doesn’t offer operational models for staffing, identity management, or configuration-as-code frameworks. You’ll need to build your own blueprints for drift detection, fleet layer intelligence, governance orchestration, and feedback optimization.

When addressing CISO concerns about tenant commingling, emphasize that multi-tenant operations use federation (maintaining autonomy) rather than integration (combining systems). Each tenant retains its own policies, data boundaries, and response action controls.

The same CI/CD pipeline and automation framework can serve multiple use cases: detections, onboarding, policy deployments, permissions management, and change control. This reduces duplicative infrastructure across different IT teams.

Implement automated “cadence engines” (cron jobs) to continuously verify connector health, detection rule integrity, and configuration drift across all tenants because manually logging into 50+ tenants isn’t feasible.

The infrastructure patterns for multi-tenant security operations often mirror what identity teams, help desks, and other IT functions need. Presenting unified configuration-as-code approaches can demonstrate cost savings and efficiency gains across the entire organization.

Thank you, Mona, for these gems!

Neourdiversity in Tech

To top it all off, I was able to sit in on a presentation about the highs and lows of being neurospicy and how other neurodivergent folks can navigate them in the tech space. There is nothing to be ashamed of; embrace it. It’s a superpower, not a crutch.

Conclusion

This conference had a lot of great people, amazing talks, and even satisfying food. I really enjoyed myself! If anyone wants to come to the next one, there will be another Workplace Ninjas US conference in Arizona in February 2027. Here are some flicks during the conference!

While I didn’t get the job (spoiler alert!), I decided to focus on what I could control: my knowledge and skills. So, I’m sharing the interview questions I received and the detailed answers I formulated for each one.

1. What is Terraform and how does it help in managing infrastructure?

Terraform is an IaC tool that lets you define infrastructure in human-readable language. It uses HCL or Hashicorp Configuration Language to accomplish this. Terraform can automatically provision and manage your infrastructure which eliminates human error, it’s repeatable so it’s always provisioned and configured consistently, supports multiple cloud providers and you can use version control systems like Git to track and collaborate with other engineers.

1. What is the purpose of the Terraform init command?

The command performs several crucial tasks. The first is creating a hidden directory called ‘.terraform’ in the working directory. From there it will download any necessary provider plugins and versions specified for that cloud provider. In the short term, Terraform gets your Terraform environment ready by setting up the essential components needed to work with your infrastructure configurations.

1. How do you manage Terraform state files securely?

You can manage state files securely by utilizing cloud storage services like AWS S3 and using the KMS key to encrypt files at rest ^[2][3] or utilize the IaC platform like Terraform Cloud and leverage their built-in encryption capabilities.

1. How do you write secure and efficient Python code for an AWS Lambda function?

Only include the necessary libraries and dependencies in your deployment package. Store sensitive information like API keys, passwords, and database credentials in the AWS Secret manager, Grant your Lambda function the least privileged access, and lastly choose the appropriate memory allocation for the Lambda function^[4]. You can also utilize Lambda layers for more security^[5].

1. Can you explain the difference between an IAM role and an IAM policy?

An IAM role is an identity within AWS that can be used by users, applications, or other AWS services. An IAM policy is the permissions you will give to that identity, for example, you can specify if that identity has access to certain S3 buckets or can deploy EC2 instances. You can attach policies to a user or group or if you want it more granular you can attach an inline policy.

1. How would you implement least privilege access control for AWS resources using Terraform?

You can break down actions like “s3:GetObject” or “s3:ListBucket” to that specific resource or principle^[6] Define separate IAM roles for different purposes, for example, have a role for a web server and a separate role for a Lambda function. Set maximum permissions to a user or group, and lastly leverage conditional access^[7]. Here’s a Terraform sample of breaking down actions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-static-content-bucket/*"
      ]
    }

1. What security best practices would you recommend for storing data in AWS?

There are multiple ways you can go about doing this^[8] from IAM to defense in depth (AWS WAF, Amazon Inspector, etc.) to regular backups to strong passwords and implementing MFA but the most common way to utilize encryption at rest using KMS or CMKs for your S3 buckets, EBS volumes, DynamoDB tables, and other data storage services.

How would you handle a secrets manager in a Python application in AWS?

You can use environment variables or the secret manager and create a variable in the script using the ‘get_secret_value_ function to retrieve the credentials. Here’s an example:

import boto3
import json

# Replace with your secret ID and region
secret_id = "your_secret_id"
region_name = "us-east-1"

# Create a boto3 session
session = boto3.Session(region_name=region_name)

# Create a Secrets Manager client
client = session.client(service_name='secretsmanager')

try:
  get_secret_value_response = client.get_secret_value(SecretId=secret_id)
except ClientError as e:
  if e.response['Error']['Code'] == 'SecretNotFound':
    # Handle the case where the secret is not found
    print("Secret Not Found!")
  else:
    raise e

if "SecretString" in get_secret_value_response:
  secret = get_secret_value_response['SecretString']
else:
  secret = json.loads(get_secret_value_response['BinarySecretData'])

# Access the secret value (might require decryption if KMS is used)
print(f"Retrieved secret: {secret}")

# Use the secret value in your application logic here

1. How do I implement security controls in AWS using Terraform?

You can specify that resource to deploy in that environment:

Security Groups with Restricted Access

resource "aws_security_group" "webserver_sg" {
  name = "webserver_security_group"

  ingress {
    from_port = 80
    to_port   = 80
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # Adjust for specific allowed IP ranges
  }

  egress {
    from_port = 0
    to_port   = 0
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]  # Allow outbound traffic to anywhere
  }
}

resource "aws_instance" "web_server" {
  # ...
  vpc_security_group_ids = [aws_security_group.webserver_sg.id]
}

Encryption at Rest and in Transit

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"
  acl    = "private"

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        kms_master_key_id = aws_kms_key.master_key.arn
        sse_algorithm     = "aws:kms"
      }
    }
  }
}

1. What methods should I use to automate security patch deployments in AWS?

You can use the Systems Manager Patch Manager, define a patch baseline specifying the patching rules for your resources, target resources using tags, and install patches based on a schedule or trigger^[9].

Conclusion

Many more questions were asked during the interview, I even had to explain what a terraform code snippet was doing but I’m going to stop it right here since it’ll become a long read. I hope these questions give you guys a little insight into what companies are looking for in a Junior Cloud Security Engineer.

References

1. Shaik, A. (2023, March 11). Terraform 01: An Introduction to the Terraform Series. Aasifa Shaik. https://mysoftwarediary.hashnode.dev/terraform-01-an-introduction-to-the-terraform-series

2. Rodgers, M. (2022, June 7). Using an AWS S3 Bucket to Securely Manage and Encrypt Terraform State Files. Medium. https://medium.com/@mjrod/using-an-aws-s3-bucket-to-securely-manage-and-encrypt-terraform-state-files-78a5dac569ab

3. How to Manage Terraform S3 Backend - Best Practices. (n.d.). Spacelift. Retrieved May 11, 2024, from https://spacelift.io/blog/terraform-s3-backend

4. ‌Best Practices for Writing Python Code for AWS Lambda Function. (n.d.). CloudThat Resources. Retrieved May 11, 2024, from https://www.cloudthat.com/resources/blog/best-practices-for-writing-python-code-for-aws-lambda-function

5. ‌Tanikin, Y. (2023, July 10). Best Practices for Python with AWS Lambda: An Essential Guide. Medium. https://aws.plainenglish.io/best-practices-for-python-with-aws-lambda-an-essential-guide-a22b708f8006

6. ‌Testing IAM policies with the IAM policy simulator - AWS Identity and Access Management. (n.d.). Docs.aws.amazon.com. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html

7. ‌Douglas, N. (2023, March 21). Terraform Security Best Practices. Sysdig. https://sysdig.com/blog/terraform-security-best-practices/#:~:text=With%20Terraform%2C%20you%20can%20implement

8. ‌Best practices for securing sensitive data in AWS data stores. (2018, December 24). Amazon Web Services. https://aws.amazon.com/blogs/database/best-practices-for-securing-sensitive-data-in-aws-data-stores/

9. ‌Automate Patching with AWS Systems Manager Quick Setup Patch Policy. (n.d.). Www.youtube.com. Retrieved May 11, 2024, from https://www.youtube.com/watch?v=nDe9kLnDmsk

Setting Up the Environment

I used Azure Cloud Shell for this lab. First, I created a dedicated directory for the Terraform project:

mkdir terraform-lab && cd terraform-lab

Then I created a provider.tf file using the Cloud Shell editor (code provider.tf) and pasted in the Azure provider configuration from the Terraform registry:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "3.14.0"
    }
  }
}

provider "azurerm" {
  features {}

  storage_use_azuread = true
}

terraform init

The first command to run in any Terraform project:

terraform init

terraform init initializes the working directory by downloading the required provider plugins (in this case, the azurerm provider) and setting up the backend. You always run this first, it’s what makes the other commands work.

terraform fmt

Next, I created variables.tf and main.tf:

touch variables.tf main.tf
code .

Before validating or planning, run:

terraform fmt

terraform fmt automatically formats your .tf files to the canonical style, consistent indentation, spacing, and alignment. It’s a good habit to run this before committing any Terraform code.

Writing the Configuration

I started with a resource group in main.tf, referencing variables for the name and location:

resource "azurerm_resource_group" "basics" {
  name     = var.resource_group_name
  location = var.location
}

Then added a container group running a public Docker image:

resource "azurerm_container_group" "example" {
  name                = var.container_group_name
  location            = azurerm_resource_group.basics.location
  resource_group_name = azurerm_resource_group.basics.name
  ip_address_type     = "Public"
  dns_name_label      = "${var.prefix}-${var.container_group_name}"
  os_type             = "Linux"

  container {
    name   = "inspectorgadget"
    image  = "jelledruyts/inspectorgadget:latest"
    cpu    = "0.5"
    memory = "1.0"

    ports {
      port     = 80
      protocol = "TCP"
    }
  }
}

The azurerm_resource_group.basics.location reference tells Terraform: go look at the resource named basics of type azurerm_resource_group and grab its location attribute. This is how Terraform understands dependencies between resources.

In variables.tf:

variable "resource_group_name" {
  description = "Name for the resource group"
  type        = string
  default     = "terraform-basics"
}

variable "location" {
  description = "Azure region"
  type        = string
  default     = "East US"
}

variable "container_group_name" {
  description = "Name of the container group"
  type        = string
  default     = "terraform-basics"
}

variable "prefix" {
  description = "Prefix string to ensure FQDNs are globally unique"
  type        = string
}

And a terraform.tfvars file to set specific values:

location = "eastus"
prefix   = "Artist"

terraform validate

Before planning, check that your configuration is syntactically and logically valid:

terraform validate

This catches things like missing required arguments, invalid resource types, or circular dependencies without making any API calls.

terraform plan

Preview the changes Terraform will make before applying them:

terraform plan

The output shows which resources will be created, updated, or destroyed. It’s the “measure twice, cut once” step, always review the plan before applying.

terraform apply

Deploy the resources to Azure:

terraform apply

Terraform will show the plan one more time and prompt for confirmation. Type yes to proceed. Once complete, the resource group and container group will be live in your Azure subscription.

terraform destroy

When you’re done with the resources, tear everything down:

terraform destroy

This removes all resources defined in the configuration from your Azure account. Type yes to confirm.

Wrapping Up

Nothing too advanced here just wanted to brush up on the Terraform workflow in Azure. What I’ve found is that Azure has more concepts to internalize than AWS (Cloud Shell was something I didn’t even know existed until recently), but once you start using the tools the pieces start fitting together. Learning by doing different things and seeing how they connect is just how I work.

That’s all for today just keeping you updated on the journey!

What Is Azure Active Directory (AD)?

Azure Active Directory is a cloud-based identity service. It handles two foundational security concerns:

• Authentication — verifying that you are who you claim to be
• Authorization — controlling what resources you can access

Don’t confuse it with the on-premises Windows Server Active Directory. Azure AD is designed for Internet-based services and applications — Microsoft 365, Azure services, and third-party SaaS apps. That said, you can use both together through hybrid identity.

When you first sign up for Azure, an Azure AD tenant is already configured. A tenant is your organization’s dedicated directory that stores all its users.

Key Features of Azure AD

• Application Management — manage access to cloud and on-premises apps from one place
• Authentication — includes Self-Service Password Reset (SSPR) so users can reset their own passwords
• Conditional Access — an if/then policy engine: if a user wants to access a resource, then they must complete a specific action (like MFA)
• Device Management — control how cloud or on-premises devices access corporate data

Azure AD also supports Business-to-Business (B2B) collaboration — invite partner organizations to access your data without creating local user accounts. And for streamlining onboarding, Entitlement Management lets you bundle apps and permissions into access packages that new employees can request.

What Is Microsoft Sentinel?

Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) platform. In plain terms:

• SIEM — collects, correlates, and analyzes security data from across your environment to detect threats
• SOAR — automates and orchestrates response actions so your team isn’t doing everything manually

Sentinel is built on top of Log Analytics workspaces, using Data Connectors to ingest logs from Microsoft services, third-party tools, and custom sources.

What Sentinel Can Do

• Detect threats with built-in machine learning and threat intelligence
• Investigate incidents using an AI-assisted investigation graph
• Respond automatically with Logic Apps-based playbooks
• Hunt proactively for threats using KQL queries
• Leverage Jupyter notebooks for machine learning–driven investigations
• Integrate with Azure Monitor workbooks for interactive dashboards

Sentinel’s analytics rules — including Fusion, Machine Learning Behavioral, Anomaly, Microsoft Security, and Scheduled types — let you configure alerts tailored to your environment using Microsoft’s provided templates as a starting point.

What Is Microsoft Defender?

Microsoft Defender isn’t one product — it’s a family of security tools, each targeting a different attack surface. Here’s a breakdown:

Microsoft Defender for Cloud (formerly Azure Security Center)

Defender for Cloud protects workloads across AWS, GCP, Azure, and on-premises environments from a single pane of glass. It uses a Secure Score to measure your security posture and recommends specific remediations for misconfigurations. It offers workload-specific plans — for example, Defender for Servers if you need to protect virtual machines hosting sensitive data.

Microsoft Defender for Identity (formerly Azure ATP)

Social engineering remains the most common attack vector — a user clicks a malicious link and enters their credentials without thinking. Defender for Identity doesn’t stop the click, but it monitors on-premises Active Directory for suspicious user behavior.

It builds a baseline of normal behavior for each user, then flags anomalies. For example, if a user starts enumerating other accounts in the directory, Defender for Identity maps that to the reconnaissance phase of the cyber kill chain and raises an alert.

Microsoft Defender for Endpoint

Defender for Endpoint provides threat protection across devices — including mobile. It combines:

• Threat and vulnerability management
• Attack surface reduction
• Next-generation antivirus protection
• Endpoint detection and response (EDR)
• Automated investigation and remediation
• Behavioral sensors that gather activity data from endpoints and feed it into Microsoft’s threat intelligence cloud

Microsoft 365 Defender

When you have Defender for Endpoint, Office 365, Identity, and Cloud Apps all running, incidents can span multiple products. Microsoft 365 Defender correlates signals across all of them into a single incident — giving you the full who, what, when, where, and how of an attack without pivoting between four different dashboards.

Microsoft Defender for Office 365

Protects your organization from email-borne threats — malicious attachments and links. It has two plans:

• Plan 1 — Safe Attachments and Safe Links (detonates attachments in a sandbox before delivery)
• Plan 2 — Adds automated investigation/response and attack simulation training for users

It operates across four protection layers: Edge, Sender Intelligence, Content Filtering, and Post-Delivery.

Microsoft Defender for Cloud Apps

As companies move data to the cloud, they need visibility into what SaaS apps employees are using and how. Defender for Cloud Apps acts as a Cloud Access Security Broker (CASB) — a gatekeeper between users and cloud services. It helps you:

• Discover shadow IT (unsanctioned app usage)
• Enforce data loss prevention (DLP) policies
• Maintain compliance with government frameworks (HIPAA, PCI DSS, etc.)
• Classify and label sensitive data

What Is Microsoft Purview?

Data is the most sensitive asset in any organization. You need to protect it and prove compliance with regulatory frameworks — and that’s where Microsoft Purview comes in. It gives you a bird’s-eye view of your entire data estate:

• Classify data with sensitivity labels (confidential, highly confidential, etc.)
• Track data lineage — understand the origin of your data and how it flows through systems
• Identify stale data and surface data ownership
• Enforce compliance against frameworks like HIPAA, GDPR, and PCI DSS

Purview is a newer service with a rapidly expanding feature set.

How Do They All Fit Together?

Protecting a modern organization means covering identity, endpoints, data, email, and cloud workloads simultaneously. Here’s how the Microsoft stack connects:

Instead of cobbling together separate tools with separate dashboards, Microsoft makes it possible to manage most of your security posture from a unified interface. Sentinel pulls signals from Defender products and correlates them into incidents; Azure AD controls who gets through the door; Purview ensures the data behind that door is properly classified and protected.

This doesn’t mean it’s a silver bullet — knowing what your organization needs and properly configuring each service still takes real work. But when it’s all set up correctly, it’s a genuinely powerful stack.

Thanks for reading! If you have any questions or feedback, reach out to me on LinkedIn.

The Scenario

Three EC2 instances are deployed in a VPC. Instances 1 and 2 are reachable from the internet; Instance 3 is not. The task: identify what’s different about Instance 3 and fix it.

Step 1: Check the Security Group

The first thing I did was inspect the security group attached to Instance 3 to see what inbound and outbound rules were configured.

The security group rules looked correct — SSH and ICMP were allowed inbound, and outbound was open. So the security group wasn’t the problem.

Step 2: Check the Subnet NACL

Next, I looked at the Network ACL (NACL) for the subnet Instance 3 was placed in.

The NACL was missing rules for SSH and ICMP inbound, and had a restrictive outbound rule. I edited the NACL to:

• Allow inbound SSH (port 22) and ICMP from anywhere
• Allow all outbound traffic

Step 3: Assign a Public IP Address

With the NACL fixed, I still needed to test connectivity — but Instance 3 only had a private IP address. I allocated an Elastic IP and associated it with the instance:

1. In the EC2 console, select the instance → Actions → Networking → Manage IP Addresses
2. Click the link to Allocate Elastic IP address
3. Allocate the IP, then associate it with Instance 3

Step 4: Fix the Route Table

I tried pinging the instance but still got no response. With help from the walkthrough video, I spotted the real issue: the subnet’s route table had no route to an internet gateway.

Instances 1 and 2 were in subnets whose route tables had a 0.0.0.0/0 route pointing to an IGW. Instance 3’s subnet was associated with the wrong route table — one without that default route.

I updated the route table association:

• Navigate to VPC → Route Tables
• Select the route table for Instance 3’s subnet
• Edit the association and switch it to the public route table (the one with the IGW route)

Step 5: Verify Connectivity

After updating the route table, I pinged the Elastic IP:

ping <elastic-ip-address>

And it responded. Problem solved!

Conclusion

My troubleshooting thought process was to compare Instance 3 against Instances 1 and 2 at each layer of the network stack:

1. Security Group — checked first, was fine
2. Network ACL — missing SSH/ICMP rules, fixed
3. Public IP — missing, allocated an Elastic IP
4. Route Table — the real culprit, no IGW route

The key lesson: for any EC2 instance to communicate with the internet, all four pieces need to be in place — security group rules, NACL rules, a public IP, and a route table entry pointing to an internet gateway. Missing any one of them breaks connectivity.

Hope someone learned something today — because I definitely did. Until next time!

Stage 1: Configure Security & Create a CodeCommit Repository

SSH Key Setup for CodeCommit

Generate an SSH key pair for CodeCommit authentication. The setup steps differ by OS:

• Windows: Follow the Windows SSH guide
• Linux/macOS: Follow the Linux/macOS SSH guide

Clone the Repository

Once SSH is set up, create a CodeCommit repository and clone it into a local folder:

git clone ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/catpipeline ~/repos/catpipeline-codecommit

Add the Lab Files

Download and unzip the lab files provided via this link, copy them into the cloned repo, then push:

git add -A .
git commit -m "container of cats"
git push

Stage 2: CodeBuild + ECR — Build and Store the Docker Image

Create an ECR Repository

Create a private Amazon Elastic Container Registry (ECR) to store the Docker images that CodeBuild produces.

Grant CodeBuild Access to ECR

Before CodeBuild can push images to ECR, attach an inline policy to its IAM role:

{
  "Statement": [
    {
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:CompleteLayerUpload",
        "ecr:GetAuthorizationToken",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ],
      "Resource": "*",
      "Effect": "Allow"
    }
  ],
  "Version": "2012-10-17"
}

Create the buildspec.yml

Add a buildspec.yml file to the CodeCommit repository. This file tells CodeBuild how to build and push the Docker image:

version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
  build:
    commands:
      - echo Build started on `date`
      - echo Building the Docker image...
      - docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
      - docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker image...
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG

Gotcha: YAML does not allow tabs for indentation. If the build fails with “a character that cannot start any token” at line 4, convert all tab indentation to spaces. In VSCode: click the indentation indicator in the status bar → “Convert Indentation to Spaces”, then push the fixed file.

Test the Docker Image

A CloudFormation stack provisions a test EC2. Connect via EC2 Instance Connect and verify the image:

# Confirm Docker is running
docker ps

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin <ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com

# Pull the image
docker pull <IMAGE_URI>

# Run it
docker run -p 80:80 <IMAGE_ID>

Navigate to http://<EC2_PUBLIC_IP> — cats should appear!

Stage 3: CodePipeline — Automate Build on Commit

Create a CodePipeline with two stages: Source (CodeCommit) and Build (CodeBuild). Now every push to the repository automatically triggers a new build.

Update buildspec.yml to tag images with the git commit hash and output an imagedefinitions.json artifact (required for ECS deployment in Stage 4):

version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
      - REPOSITORY_URI=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=${COMMIT_HASH:=latest}
  build:
    commands:
      - echo Build started on `date`
      - echo Building the Docker image...
      - docker build -t $REPOSITORY_URI:latest .
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker image...
      - docker push $REPOSITORY_URI:latest
      - docker push $REPOSITORY_URI:$IMAGE_TAG
      - echo Writing image definitions file...
      - printf '[{"name":"%s","imageUri":"%s"}]' "$IMAGE_REPO_NAME" "$REPOSITORY_URI:$IMAGE_TAG" > imagedefinitions.json
artifacts:
  files: imagedefinitions.json

Push the updated file to trigger the pipeline and confirm it runs successfully.

Stage 4: ECS Fargate + ALB — Automated Deployment

Create an Application Load Balancer

Create an ALB with a security group that allows all inbound HTTP traffic. Configure a target group for the ECS service.

Create the ECS Cluster and Task Definition

Create an ECS cluster, then define a Fargate task. Here’s the task definition JSON for reference:

{
  "family": "catpiplinedemo",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "containerDefinitions": [
    {
      "name": "catpipline",
      "image": "<ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/catpipeline",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/catpiplinedemo",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Create the ECS Service

Create a Fargate service in the cluster, attaching it to the ALB target group. Verify the service starts and the ALB DNS name shows the running application.

Add a Deploy Stage to CodePipeline

Edit the pipeline and add a Deploy stage after Build:

• Action provider: Amazon ECS
• Input artifact: imagedefinitions.json from the build stage
• Cluster / Service: your Fargate cluster and service

Test the Full Pipeline

Make a change in your local index.html and push it:

git add index.html
git commit -m "update cat display page"
git push

Watch the pipeline run through Source → Build → Deploy. Once complete, copy the ALB DNS name into the browser to see the updated application live.

Conclusion

This was a genuinely fun demo to go through. Building the full pipeline — from commit to running container behind a load balancer — really cements how CI/CD works in AWS. A couple of things to watch out for:

1. YAML tabs vs. spaces — always use spaces in buildspec.yml
2. Spelling in CodePipeline — the deploy stage configuration is case-sensitive when naming ECS clusters and services

Happy 4th of July, and happy shipping! :)

What Is AWS IAM?

IAM has existed as a concept long before AWS. At its core, it’s an access control framework: defining who can access what resources, under what conditions. AWS IAM puts this into practice by letting you:

• Create users, groups, and roles
• Attach policies that grant or deny specific API actions on specific resources
• Enforce conditions like MFA presence, IP address restrictions, and time-of-day controls

The distinction between authentication (proving who you are) and authorization (controlling what you can do) is central to understanding IAM.

Lab: Create and Assume an IAM Role with S3 Scoping

This lab creates a custom policy that grants full S3 access except to two protected buckets, then attaches it to a role and user.

Step 1: Create the Policy

The policy below grants broad S3 access while explicitly scoping resource access to avoid the two pre-created sensitive buckets. It uses the visual policy editor output:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "s3:ListStorageLensConfigurations",
        "s3:ListAccessPointsForObjectLambda",
        "s3:GetAccessPoint",
        "s3:PutAccountPublicAccessBlock",
        "s3:GetAccountPublicAccessBlock",
        "s3:ListAllMyBuckets",
        "s3:ListAccessPoints",
        "s3:PutAccessPointPublicAccessBlock",
        "s3:ListJobs",
        "s3:PutStorageLensConfiguration",
        "s3:ListMultiRegionAccessPoints",
        "s3:CreateJob"
      ],
      "Resource": "*"
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3::851592760101:accesspoint/*"
    },
    {
      "Sid": "VisualEditor2",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:*:851592760101:storage-lens/*",
        "arn:aws:s3:*:851592760101:accesspoint/*",
        "arn:aws:s3:::cfst-3352-0420dac77a81904f3474ca99-appconfigprod1-8x31vcbk3f3w",
        "arn:aws:s3:::cfst-3352-0420dac77a81904f3474ca99-appconfigprod2-19s6selwyo5x3",
        "arn:aws:s3:*:851592760101:job/*",
        "arn:aws:s3:::*/*",
        "arn:aws:s3:us-west-2:851592760101:async-request/mrap/*/*",
        "arn:aws:s3-object-lambda:*:851592760101:accesspoint/*"
      ]
    }
  ]
}

Step 2: Attach the Policy to a Role

Create an IAM role and attach the policy from Step 1 to it. Then attach the role to the lab user.

Step 3: Verify Access

With the policy in place, the user can access the appconfigprod1 and appconfigprod2 buckets but is blocked from the customer-data buckets — exactly as intended. Developers get what they need; sensitive data stays protected.

CloudFormation: IAM Baseline with MFA Enforcement

You can also provision groups, policies, and roles as code using CloudFormation. The template below creates a complete IAM baseline — including MFA-enforced admin roles, a read-only role, and CloudFormation deployment roles:

Parameters:
  AllowRegion:
    Type: String
    Description: 'A single region that resources can be created in'
    Default: 'ap-southeast-2'
  BaselineNamePrefix:
    Type: String
    Description: 'The prefix for roles, groups and policies created by this stack'
    Default: 'Baseline'
  BaselineExportName:
    Type: String
    Description: 'The CloudFormation export name prefix'
    Default: 'Baseline'
    MinLength: '3'
    MaxLength: '32'
  IdentityManagementAccount:
    Type: String
    Description: AccountId trusted to assume all roles (blank for no cross-account trust)
    Default: ''
  ToolingManagementAccount:
    Type: String
    Description: AccountId trusted to assume ReadOnly and StackSet roles
    Default: ''
  OrganizationsRootAccount:
    Type: String
    Description: AccountId trusted to assume Organizations role
    Default: ''

Conditions:
  LinkToIdentityManagementAccount: !Not
    - !Equals
      - !Ref IdentityManagementAccount
      - ''
  LinkToToolingManagementAccount: !Not
    - !Equals
      - !Ref ToolingManagementAccount
      - ''
  LinkToOrganizationsRootAccount: !Not
    - !Equals
      - !Ref OrganizationsRootAccount
      - ''

Resources:
  ManageSelfIAMUserGroupPolicy:
    Type: 'AWS::IAM::ManagedPolicy'
    Properties:
      ManagedPolicyName: !Sub '${BaselineNamePrefix}-ManageSelfIAMUserGroupPolicy'
      Description: !Sub 'Policy for ${BaselineNamePrefix} managing own IAM user'
      Path: /
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Action: 'iam:GetAccountPasswordPolicy'
            Resource: '*'
          - Sid: AllowUsersToListMFADevicesandUsersForConsole
            Effect: Allow
            Action:
              - 'iam:ListMFADevices'
              - 'iam:ListVirtualMFADevices'
              - 'iam:ListUsers'
            Resource: '*'
          - Effect: Allow
            Action:
              - 'iam:ChangePassword'
            Resource:
              - !Sub 'arn:aws:iam::${AWS::AccountId}:user/${!aws:username}'
          - Sid: AllowUsersToDeactivateTheirOwnVirtualMFADevice
            Effect: Allow
            Action:
              - 'iam:DeactivateMFADevice'
              - 'iam:*LoginProfile'
              - 'iam:*AccessKey*'
              - 'iam:*SSHPublicKey*'
            Resource:
              - !Sub 'arn:aws:iam::${AWS::AccountId}:user/${!aws:username}'
              - !Sub 'arn:aws:iam::${AWS::AccountId}:mfa/${!aws:username}'
            Condition:
              Bool:
                'aws:MultiFactorAuthPresent': true
          - Sid: AllowUsersToCreateEnableResyncDeleteTheirOwnVirtualMFADevice
            Effect: Allow
            Action:
              - 'iam:CreateVirtualMFADevice'
              - 'iam:EnableMFADevice'
              - 'iam:ResyncMFADevice'
              - 'iam:DeleteVirtualMFADevice'
            Resource:
              - !Sub 'arn:aws:iam::${AWS::AccountId}:user/${!aws:username}'
              - !Sub 'arn:aws:iam::${AWS::AccountId}:mfa/${!aws:username}'

  PrivilegedAdminRole:
    Type: 'AWS::IAM::Role'
    Properties:
      RoleName: !Sub '${BaselineNamePrefix}-PrivilegedAdmin'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AdministratorAccess
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - !Sub 'arn:aws:iam::${AWS::AccountId}:root'
            Action: 'sts:AssumeRole'
            Condition:
              Bool:
                'aws:MultiFactorAuthPresent': 'true'
          - !If
            - LinkToIdentityManagementAccount
            - Effect: Allow
              Principal:
                AWS:
                  !Sub 'arn:aws:iam::${IdentityManagementAccount}:root'
              Action: 'sts:AssumeRole'
              Condition:
                Bool:
                  'aws:MultiFactorAuthPresent': 'true'
            - !Ref 'AWS::NoValue'

  AccountWideReadOnlyRole:
    Type: 'AWS::IAM::Role'
    Properties:
      RoleName: !Sub '${BaselineNamePrefix}-AccountWideReadOnly'
      ManagedPolicyArns:
        - 'arn:aws:iam::aws:policy/ReadOnlyAccess'
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - !Sub 'arn:aws:iam::${AWS::AccountId}:root'
            Action: 'sts:AssumeRole'
            Condition:
              Bool:
                'aws:MultiFactorAuthPresent': 'true'

  CloudFormationRole:
    Type: 'AWS::IAM::Role'
    Properties:
      RoleName: !Sub '${BaselineNamePrefix}-CloudFormation'
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service: cloudformation.amazonaws.com
            Action: 'sts:AssumeRole'
      Policies:
        - PolicyName: root
          PolicyDocument:
            Version: 2012-10-17
            Statement:
              - Effect: Allow
                Action: '*'
                Resource: '*'
              - Effect: Deny
                Action:
                  - 'cloudformation:CreateStack'
                  - 'cloudformation:UpdateStack'
                Resource: '*'
                Condition:
                  'Null':
                    'cloudformation:TemplateURL': 'true'

  StackSetRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: AWSCloudFormationStackSetExecutionRole
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - !Sub 'arn:aws:iam::${AWS::AccountId}:root'
            Action: 'sts:AssumeRole'
      Path: /
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AdministratorAccess

Outputs:
  PrivilegedAdminRole:
    Description: Privileged Admin Role
    Value: !GetAtt PrivilegedAdminRole.Arn
    Export:
      Name: !Sub '${BaselineExportName}-PrivilegedAdminRole'
  AccountWideReadOnlyRole:
    Description: Account Wide Read Only Role
    Value: !GetAtt AccountWideReadOnlyRole.Arn
    Export:
      Name: !Sub '${BaselineExportName}-AccountWideReadOnlyRole'
  CloudFormationRole:
    Description: Baseline CloudFormation Role
    Value: !GetAtt CloudFormationRole.Arn
    Export:
      Name: !Sub '${BaselineExportName}-CloudFormationRole'

The template enforces MFA as a condition on all privileged role assumptions — meaning even if credentials are compromised, an attacker can’t assume the admin role without a valid MFA token.

Wrapping Up

IAM is not a set-it-and-forget-it service. The key principles to live by:

• Least privilege — grant only the permissions needed for the job, and no more
• MFA everywhere — especially for privileged roles
• Infrastructure as Code — define IAM in CloudFormation or Terraform so changes are reviewed and versioned
• Audit regularly — use IAM Access Analyzer and AWS Config rules to catch drift

Hope this was helpful and informative. Feel free to message me on LinkedIn with any questions — Artist out!