Question 1. An IT administrator has been told to "handle security" for the company's M365 tenant. Which of the following best describes their primary responsibility?
Building a 24/7 security monitoring operation and conducting forensic investigations of every alert — No. This describes a SOC team, not an IT administrator with security responsibilities. The IT admin's primary job is configuration and first response, not full-time monitoring and investigation.
Configuring the security controls included in the M365 license, maintaining a light monitoring cadence, and handling the first 15 minutes of incident response — Correct. The three-category model (Configure 70%, Monitor 20%, Respond 10%) defines the IT admin's security role. Configuration delivers the highest impact, monitoring catches drift, and response handles the first minutes before escalation.
Writing security policies and conducting quarterly risk assessments aligned to ISO 27001 — No. This describes a GRC role. While security policies are valuable, the IT admin's immediate priority is configuring the technical controls. Policy work can follow once the controls are in place.
Deploying Microsoft Sentinel and building KQL detection rules for advanced threats — No. This describes a detection engineer or SOC analyst role. Sentinel deployment and KQL rule development are advanced capabilities covered by other Ridgeline courses.
Question 2. Which attack surface is the most critical to defend in an M365 environment, and which security control addresses it?
Email, defended by Defender for Office 365 Safe Links and Safe Attachments — Important but not the most critical. Email is the delivery mechanism, not the entry point. Reducing phishing volume helps, but if identity controls are weak, the attacker can use credentials obtained through other means (password spray, breach databases).
Endpoints, defended by Microsoft Defender Antivirus and Defender for Endpoint — Important but not the most critical for M365. Endpoint protection matters for device-level threats, but the majority of M365 attacks compromise identity without touching the endpoint.
Identity, defended by MFA and conditional access — Correct. Over 80% of M365 breaches start with compromised credentials. MFA and conditional access prevent the attacker from using stolen credentials, which stops the attack before it reaches email or data. Identity is the perimeter.
Data, defended by sensitivity labels and DLP policies — Important but last-priority. Data protection limits the damage after a compromise, but it doesn't prevent the compromise itself. Identity and email controls should be configured before data protection.
Question 3. Your M365 E3 tenant has security defaults enabled. Which of the following protections is NOT provided by security defaults?
MFA registration requirement for all users — This IS provided. Security defaults require all users to register for MFA within 14 days.
MFA challenge on admin sign-ins — This IS provided. Security defaults require MFA for all administrator role holders on every sign-in.
Blocking of some legacy authentication protocols — This IS partially provided. Security defaults block certain legacy authentication flows, though not as comprehensively as a conditional access policy.
Requiring a compliant or managed device for access to cloud applications — Correct — NOT provided. Security defaults have no device compliance requirement. Only conditional access can enforce device compliance by integrating with Intune compliance policies. This is one of the key gaps that drives the transition from security defaults to conditional access.
Question 4. You want to configure a conditional access policy. Which admin portal do you navigate to?
Entra admin center at entra.microsoft.com → Protection → Conditional Access — Correct. All conditional access policy creation and management happens in the Entra admin center. The Defender portal shows CA evaluation results but doesn't host policy configuration.
Microsoft Defender portal at security.microsoft.com → Settings → Identity — No. The Defender portal is for monitoring and investigation, not CA policy configuration.
M365 Admin Center at admin.microsoft.com → Settings → Security & privacy — No. The M365 Admin Center has some security settings but not conditional access.
Intune admin center at intune.microsoft.com → Endpoint security — Not directly. Intune has a CA link but it redirects to the Entra admin center.
Question 5. You see a high-severity incident in the Defender portal: "Compromised user account" for a finance team member. The incident was created 6 hours ago and shows sign-ins from an unusual country followed by inbox rule creation. What is your first action?
Investigate the full scope of the compromise before taking any containment action — No. With 6 hours of active access, the attacker has already read emails, possibly exfiltrated data, and created persistence. Investigating before containing extends the attacker's access window. Contain first.
Reset the user's password, revoke all sessions, and remove the suspicious inbox rule — then investigate — Correct. Contain immediately: password reset blocks new sign-ins, session revocation terminates active sessions, inbox rule removal stops ongoing email forwarding. Then investigate what the attacker accessed during the 6-hour window.
Contact the user to ask if they were travelling internationally — Not the first action. Verifying with the user is a reasonable step, but not before containment. If it turns out to be a false positive (the user was genuinely travelling), you can re-enable the account. The cost of a false positive containment (user inconvenience) is much lower than the cost of delaying containment on a real compromise.
Escalate to the managed SOC partner immediately — Not yet. You should contain first, then escalate if the investigation reveals broader compromise. The containment actions (password reset, session revocation, rule removal) are within your capability and should not wait for escalation.
Question 6. Your Secure Score is 42%. Your manager asks what that means. Which response is most accurate?
"We're only 42% secure — we need to fix this urgently" — Misleading. Secure Score measures configuration breadth, not security level. 42% doesn't mean 58% of your environment is vulnerable.
"It's a meaningless number that we should ignore" — Wrong. Secure Score is a useful prioritisation tool and trend metric. Dismissing it entirely means losing a useful framework for identifying gaps.
"We've implemented 42% of Microsoft's recommended configurations. I've identified the top 5 highest-impact improvements and can implement them over the next two weeks" — Correct. This frames the score accurately, acknowledges the gap without panic, and presents an actionable plan. It treats Secure Score as what it is: a prioritisation tool, not a security rating.
"The industry average is 45% so we're close to normal" — Unhelpful. Being average in security means being equally vulnerable to the same attacks that compromise average organisations. The goal isn't to be average — it's to close the highest-impact gaps.
Question 7. What is the correct sequence for improving M365 security from a default-configured tenant?
Identity (MFA, conditional access) → Email (Safe Links, anti-phishing) → Devices (compliance policies) → Monitoring and response — Correct. This sequence follows the attack chain: stop the attacker from authenticating (identity), then reduce the delivery of attacks (email), then protect the access layer (devices), then establish operational monitoring. Each phase has dependencies on the previous phase.
Email → Identity → Devices → Monitoring — Incorrect sequence. Email protection reduces phishing volume but doesn't stop credential-based attacks that bypass email entirely (password spray, breach database credentials). Identity should come before email.
Monitoring → Identity → Email → Devices — Incorrect sequence. Monitoring without controls to protect the environment means watching incidents happen without the ability to prevent them. Controls first, monitoring second.
Devices → Email → Identity → Monitoring — Incorrect sequence. Device compliance depends on conditional access for enforcement, which is an identity control. You need conditional access before device compliance adds value.
Question 8. After completing this course, which of the following is within your expected scope as an IT administrator with security responsibilities?
Writing custom KQL detection rules for advanced persistent threat campaigns — Out of scope. This is detection engineering work covered by the Detection Engineering course.
Conducting forensic analysis of a compromised endpoint including memory acquisition and timeline reconstruction — Out of scope. This is incident response work covered by the Practical IR course.
Deploying and managing Microsoft Sentinel as the organisation's SIEM — Out of scope. Sentinel deployment and management is covered by the M365 Security Operations course.
Configuring conditional access policies, managing email protection, monitoring the Defender portal for alerts, and handling the first 15 minutes of a compromised account response — Correct. This is the configure-monitor-respond scope that this course builds. These are high-impact security capabilities that fit alongside an IT administration workload.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
You're reading the free modules of M365 Security: From Admin to Defender
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.
