Practice exam 1
60 questions
Open this course’s practice exams →Microsoft cybersecurity architecture · Public course · v1.0.1
810 focused flashcards and 498 original practice questions covering all 81 SC-100 assessment objectives effective 21 October 2026, with six non-overlapping 60-question practice exams.
810 flashcards · 498 practice questions
Choose topics, then use Flashcards, Learn, Write, Match, Practice Questions or Mock Exam when the course has suitable content.
Unofficial study material. Not affiliated with or endorsed by Microsoft. These are original learning questions, not actual exam questions. Product capabilities and exam objectives can change; verify current Microsoft documentation. Practice scores do not predict or guarantee an exam result.
Fixed question sets within this course. Open study modes to take an exam and save results in your browser.
60 questions
Open this course’s practice exams →60 questions
Open this course’s practice exams →60 questions
Open this course’s practice exams →60 questions
Open this course’s practice exams →60 questions
Open this course’s practice exams →60 questions
Open this course’s practice exams →Business resilience and ransomware
Its compromise would materially damage the organization through loss of revenue, mission, safety, operations, reputation, or sensitive information. Technical size and replacement cost alone do not establish criticality.
Business resilience and ransomware
The identity can control the high-value application, its permissions, configuration, or recovery. Protect privileged access at the same level or above the assets it can influence.
Business resilience and ransomware
Include identity services, DNS, networks, keys, certificates, data stores, deployment systems, suppliers, people, and recovery documentation. A dependency can prevent a business service from operating even when its primary compute is healthy.
Business resilience and ransomware
Integrity failure is unauthorized or incorrect modification, such as changed payment instructions. Availability failure prevents timely authorized use. A system can remain online while an integrity attack causes severe business loss.
Business resilience and ransomware
Identify the consequences of disrupting each business process, its dependencies, and acceptable recovery targets. Use business impact to justify priorities and investment rather than treating all systems equally.
Recovery targets require business agreement.
Business resilience and ransomware
A threat is a potential cause of harm, such as a credential-stealing adversary. A vulnerability is a weakness that can be exploited, such as excessive service-account permissions. Risk considers the resulting likelihood and business impact.
Business resilience and ransomware
Severity describes a weakness, while exposure, exploitability, attack paths, existing controls, and asset value determine practical risk. An exposed path to a critical identity system can outweigh an isolated higher-severity issue.
Business resilience and ransomware
An accountable business risk owner, informed by security expertise, should accept it explicitly within organizational authority. Record the rationale, scope, compensating controls, review conditions, and time limit.
Acceptance is a governance decision, not an unattended technical exception.
Business resilience and ransomware
Insurance can transfer some financial consequences. It does not restore systems, prevent exfiltration, recover keys, or remove an attacker. Maintain technical prevention, containment, and tested recovery.
Business resilience and ransomware
Demonstrate that high-value assets and their administrative paths are identified, access is constrained, relevant attacks are detected, and recovery tests meet agreed business targets. A purchased license or high aggregate score alone is insufficient.
Business resilience and ransomware
RPO measures the maximum acceptable data loss expressed as time. Compare it with the age of the latest usable recovery point at the incident time, including application consistency and recoverability.
Business resilience and ransomware
RTO is the maximum acceptable time to restore business operations after disruption. Include detection and recovery decisions as defined by the plan, infrastructure restoration, dependencies, application validation, and usable service.
Business resilience and ransomware
Business continuity preserves essential processes, including people, communications, suppliers, and alternate procedures. Disaster recovery restores the technology supporting those processes.
Business resilience and ransomware
Replication can reproduce corruption or encryption in the secondary environment. Keep protected historical recovery points and a validated process for restoring a known-good state.
Business resilience and ransomware
High availability keeps a service running through component failures. Historical backup enables restoration to an earlier state after deletion or corruption. One does not automatically provide the other.
Business resilience and ransomware
A successful disk or database restore can still leave identity, configuration, keys, or dependencies broken. Validated business transactions demonstrate that the recovered service actually works.
Business resilience and ransomware
Cold standby minimizes running infrastructure but requires more deployment during recovery. Warm standby maintains some ready capacity and can reduce restoration time at additional operating cost.
Business resilience and ransomware
Verify supported recovery mechanisms, regional capacity, identity and network dependencies, data residency, backup availability, and restoration time. A second region alone does not prove a usable recovery path.
Business resilience and ransomware
Encrypted recovery data can be unusable if keys, key permissions, or required historical versions are unavailable. Protect the key lifecycle and test retrieval during recovery.
Business resilience and ransomware
Set common business targets, security requirements, ownership, monitoring, and test expectations while using supported platform-specific backup and recovery mechanisms. Do not assume one Azure feature protects every service in every cloud.
Business resilience and ransomware
Prepare recovery so the organization can survive an attack: protect backups and essential dependencies and test restoration. The guidance uses assume breach to minimize business impact.
Business resilience and ransomware
Limit the scope of damage by securing privileged access. Protect identities, workstations, and management systems that can control multiple critical assets.
Business resilience and ransomware
Make initial access harder through controls such as secure remote access, phishing defenses, modern authentication, endpoint protection, and patching. These tasks must not delay recovery and privileged-access priorities.
Business resilience and ransomware
No. Separate teams can work in parallel and complete quick improvements earlier. The order expresses business-risk urgency, rather than a strict technical dependency chain.
Business resilience and ransomware
Attackers can steal sensitive data before encrypting systems and threaten disclosure. Recovery addresses restoration; access controls, data protection, monitoring, and exfiltration controls address disclosure risk.
Business resilience and ransomware
It blocks operations that could cause recovery-point loss before allowed retention ends. Locking immutability makes the setting irreversible, so validate retention and operational needs before locking.
Business resilience and ransomware
Enabled immutability can still be disabled. Locked immutability cannot be reversed. The decision to lock therefore requires careful validation of the supported workload and required retention.
Business resilience and ransomware
It provides an additional authorization boundary for configured critical vault operations. The normal vault administrator should not already possess Resource Guard permissions that satisfy those checks.
Business resilience and ransomware
It lets responders validate recovered data, credentials, configurations, and business functions before reconnecting the service. Restoring directly into a still-compromised environment can reinfect the recovered workload.
Business resilience and ransomware
MUA protects listed, configured operations on vaulted backups. It does not govern every operation directly on the original data source or automatically make ordinary production permissions safe.
Business resilience and ransomware
It assesses and manages updates for supported Windows and Linux servers in Azure and for supported on-premises or other-cloud servers connected through Azure Arc.
Business resilience and ransomware
No. The current service uses native Azure VM and Arc capabilities and Azure Resource Manager operations; it does not depend on the retired Automation-based Update Management architecture.
Business resilience and ransomware
Assessment identifies available or missing updates. Installation attempts the selected updates, and post-installation verification establishes actual compliance and workload health. Finding an update does not prove it was installed.
Business resilience and ransomware
It defines the allowed time for scheduled patching. Design it around application dependencies, safe restart behavior, recovery capacity, and the time needed to validate the workload.
Business resilience and ransomware
A small initial population reveals failures before wider exposure. Expand only after health and security checks pass, and halt or recover when failures appear.
Business resilience and ransomware
Keep explicit authority, targeted validation, monitoring, and a recovery plan while shortening the normal rollout when active exploitation justifies urgency. Emergency status does not remove deployment risk.
Business resilience and ransomware
A reachable actively exploited weakness on a critical path can deserve faster treatment than an isolated issue. Use vulnerability severity alongside exposure, dependencies, available mitigations, and operational risk.
Business resilience and ransomware
Record a time-bound exception, reduce exposure, restrict access, segment the workload, monitor relevant threats, and plan an approved update or replacement. Compensating controls reduce risk without repairing the vulnerable code.
Business resilience and ransomware
A patching or deployment identity can execute changes across many machines. Scope its authority to necessary resources, protect its credentials, and audit changes to avoid turning management infrastructure into an attack path.
Business resilience and ransomware
Confirm installation results, required reboots, remaining vulnerabilities, and application health. Investigate failed or skipped machines rather than treating the presence of a schedule as evidence of compliance.
MCRA MCSB and Zero Trust
MCRA describes end-to-end cybersecurity capabilities and integration across hybrid, multicloud, legacy IT, IoT, OT, and AI. Use it to define and compare an enterprise security target state.
MCRA MCSB and Zero Trust
Use MCSB when selecting prescriptive cloud security controls, service baselines, and posture requirements. It provides guidance across Azure and multicloud environments rather than a single application quality review.
MCRA MCSB and Zero Trust
CAF organizes cloud adoption, operating models, governance, and the platform foundation. MCRA maps cybersecurity capabilities and integrations across the broader enterprise estate.
MCRA MCSB and Zero Trust
Well-Architected evaluates an individual workload across reliability, security, cost, operations, and performance. MCRA helps plan integrated security capabilities across the enterprise.
MCRA MCSB and Zero Trust
Identify capability gaps, overlapping tools, missing integrations, and controls that exist but are not effectively implemented. Owning a depicted product does not prove the corresponding security outcome.
MCRA MCSB and Zero Trust
Business requirements, existing systems, risks, responsibilities, and supported technology differ between organizations. A reference supplies a starting target architecture, not a universal configuration script.
MCRA MCSB and Zero Trust
The preview introduces an AI Security domain with seven recommendations, expanded Azure Policy mappings, and detailed risk- and threat-based implementation guidance. Verify preview status and service support when applying it.
MCRA MCSB and Zero Trust
A mapping helps organize relevant control guidance and assessment evidence. Compliance also depends on correct implementation, scope, operating processes, validation, and applicable legal or contractual requirements.
MCRA MCSB and Zero Trust
Start with the required outcome and threat, map the control to supported technology, assign an owner, and test the result. Selecting products first can leave gaps between controls and operational responsibilities.
MCRA MCSB and Zero Trust
Signals, identity decisions, data protection, response authority, and recovery must work together. A disconnected deployment can collect evidence without enforcing the control or response needed to stop an attack.
MCRA MCSB and Zero Trust
An insider may already have valid credentials and legitimate network access. Constrain privileges, protect sensitive data, audit activity, and govern investigations rather than relying only on external traffic filtering.
MCRA MCSB and Zero Trust
It correlates signals for potential malicious and inadvertent insider risks, including data leakage, intellectual-property theft, and security violations. A risk signal requires investigation rather than automatically proving intent.
MCRA MCSB and Zero Trust
Users are pseudonymized by default, and role-based access controls and audit logs help protect privacy. Govern who can investigate and reveal identities within an approved process.
MCRA MCSB and Zero Trust
Anti-phishing controls address deceptive entry messages. They do not decrypt data or restore services after encryption; a separate incident response and recovery capability remains necessary.
MCRA MCSB and Zero Trust
A stolen credential or session can bypass a single preventive layer. Combine strong authentication, contextual access, least privilege, data authorization, monitoring, and response to reduce the resulting impact.
MCRA MCSB and Zero Trust
Repositories, dependencies, build runners, artifact stores, and deployment credentials can influence code delivered to production. Compromise before deployment can bypass protections focused only on running applications.
MCRA MCSB and Zero Trust
It can establish integrity and provenance relative to a trusted signer and verification process. It does not prove that the signed code has no vulnerabilities or that the signer has never been compromised.
MCRA MCSB and Zero Trust
Untrusted build inputs should not automatically gain production deployment authority. Scope identities to their stage, protect release approvals, and isolate execution contexts to limit supply-chain compromise.
MCRA MCSB and Zero Trust
Separate resource authorization, segmentation, scoped privileges, monitoring, and containment can still restrict the attacker. Successful authentication should not grant unrestricted access to all resources.
MCRA MCSB and Zero Trust
Controls should prevent, detect, or contain the ways an adversary can affect valuable assets. A long tool inventory can still miss a path through privileged identities, suppliers, or data access.
MCRA MCSB and Zero Trust
Deploy models that have passed a trusted review and approval process. Maintain model provenance, validation results, authorized deployment paths, and approval history to reduce supply-chain risk.
MCRA MCSB and Zero Trust
Validate prompts, external content, processing, and outputs through appropriate layers. A single prompt filter does not cover every route for harmful content, data leakage, or adversarial manipulation.
MCRA MCSB and Zero Trust
System instructions guide intended behavior and add a defensive layer against misuse. They do not replace independently enforced permissions, input validation, or authorization on tools and data.
MCRA MCSB and Zero Trust
Give tools or plugins only the capabilities, resources, and permissions needed for their approved tasks. Enforce these restrictions in the application or downstream system, not only in natural-language instructions.
MCRA MCSB and Zero Trust
Require accountable human review or approval for critical decisions and actions, especially when they affect sensitive data or external systems. Place the approval checkpoint before the consequential action.
MCRA MCSB and Zero Trust
Detect suspicious AI activity and risky data access, investigate misuse and jailbreak attempts, and support containment. Protect monitoring data because prompts, responses, and logs can themselves contain sensitive information.
MCRA MCSB and Zero Trust
Use adversarial exercises to discover harmful outcomes, prompt injection, model or data manipulation, and unsafe tool paths. Reassess after relevant model, prompt, data, or capability changes.
MCRA MCSB and Zero Trust
AI models, data, tools, identities, networks, and hosts remain valuable IT assets. Apply identity, network, encryption, logging, and recovery controls alongside AI-specific safeguards.
MCRA MCSB and Zero Trust
External content can contain indirect prompt injection that attempts to override intended behavior. Treat retrieved content as untrusted data and independently authorize retrieval and tool actions.
MCRA MCSB and Zero Trust
MCSB v2 is preview guidance and is not a certification or compliance attestation. Check the current status and supported implementation of each control; not every recommendation is a universally available automated feature.
MCRA MCSB and Zero Trust
Verify explicitly, use least privilege, and assume breach. Apply them to access, security controls, detection, response, and recovery across the environment.
MCRA MCSB and Zero Trust
Authenticate and authorize requests using available context such as identity, device, location, behavior, and risk. Internal network origin is not sufficient evidence of trust.
MCRA MCSB and Zero Trust
Give identities only the actions and resources needed, for the required time. Avoid unnecessary standing privileges and continually govern whether access remains justified.
MCRA MCSB and Zero Trust
Design for an attacker who gets inside: segment access, limit administrative influence, collect useful telemetry, support containment, and preserve recoverability instead of relying on prevention alone.
MCRA MCSB and Zero Trust
Identity, endpoints, applications, data, infrastructure, and networks. Controls across one area do not automatically establish protection across the others.
MCRA MCSB and Zero Trust
It changes operating processes, responsibilities, user access, investment, and priorities across the organization. Business leaders must align the change with measurable outcomes and support adoption.
MCRA MCSB and Zero Trust
Identify business scenarios and current maturity, select achievable high-impact initiatives, assign owners, implement in phases, and measure results. Do not use a product list as the entire adoption plan.
MCRA MCSB and Zero Trust
Measure outcomes such as protected privileged access, reduced critical attack paths, effective access enforcement, healthy detection coverage, and tested recovery. License counts and policy counts alone do not prove effectiveness.
MCRA MCSB and Zero Trust
Device posture is one access signal. The identity still needs appropriate resource and action permissions, and application or data controls must enforce the requested scope.
MCRA MCSB and Zero Trust
Continuous verification is the architectural goal, but actual enforcement depends on supported clients, resources, protocols, and policies. Test revocation and changed-risk behavior rather than assuming all sessions react identically.
Verify actual application behavior and service support.
CAF Well Architected and secure adoption
Define the approved business use case, data classification, potential impact, and accountable owners. These determine model, platform, access, evaluation, and governance requirements.
CAF Well Architected and secure adoption
The agent can change business state and creates additional tool and transaction risks. Its approved autonomy, permissions, human oversight, and recovery mechanisms must match that impact.
CAF Well Architected and secure adoption
Evaluate the model provider, model provenance, security requirements, and intended use before approval. Apply additional scrutiny to external or community models and reassess material changes.
CAF Well Architected and secure adoption
Use Microsoft Entra identity-based authentication and governed identities for agents and downstream calls. Grant only required permissions; protect and rotate keys where keys remain necessary.
CAF Well Architected and secure adoption
Enforce data boundaries through identity and data-access controls at retrieval and downstream services. Prompts cannot independently authorize access to a document or database.
CAF Well Architected and secure adoption
It limits supported network paths but does not decide whether a user or agent may read data or execute tools. Identity, authorization, model safeguards, and monitoring are also required.
CAF Well Architected and secure adoption
It detects prompt-injection attempts in user inputs and external content. Configure supported guardrails and combine them with independent data and tool authorization.
CAF Well Architected and secure adoption
Fairness; reliability and safety; privacy and security; inclusiveness; transparency; and accountability. Evaluate them against the use case rather than treating security alone as complete responsible AI.
CAF Well Architected and secure adoption
Reassess when the model, data sources, connectors, prompts, permissions, or allowed autonomy change, and when monitoring reveals new risks. Approval is tied to the evaluated system and use case.
CAF Well Architected and secure adoption
Evidence that authorized retrieval, tool restrictions, prompt-injection protections, output evaluation, monitoring, and consequential-action oversight work for the intended use case. Record unresolved risks and accountable decisions.
CAF Well Architected and secure adoption
Strategy, Plan, Ready, Adopt, Govern, Secure, and Manage. Governance, security, and management continue during operation rather than ending when migration finishes.
CAF Well Architected and secure adoption
Define what Azure adoption should look like and align investments with business outcomes. This establishes direction for the operating model, platform, and subsequent adoption decisions.
CAF Well Architected and secure adoption
Determine how the organization will prepare for Azure adoption, including the people, work, and readiness needed to execute the strategy.
CAF Well Architected and secure adoption
An Azure landing zone designed around organizational requirements. It provides the foundation and guardrails in which workload teams can deploy and operate.
CAF Well Architected and secure adoption
CAF guides organizational adoption, operating standards, and the platform foundation. Well-Architected assesses individual workloads against five quality pillars. Use both to connect enterprise guardrails with workload decisions.
CAF Well Architected and secure adoption
Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency. An assessment should examine tradeoffs across them rather than optimizing one in isolation.
CAF Well Architected and secure adoption
Compare business requirements and threats with assigned responsibilities, implemented controls, operating evidence, exceptions, and remediation ownership. A written strategy alone does not prove effective enforcement.
CAF Well Architected and secure adoption
Central teams supply shared standards and capabilities, while workload teams secure and operate their resources within those guardrails. Gaps arise when each assumes the other owns a control.
CAF Well Architected and secure adoption
Identify the security benefit and its effect on reliability, cost, performance, and operations. Choose a documented tradeoff that satisfies the required business and security outcomes.
CAF Well Architected and secure adoption
Workloads, threats, organizational obligations, and technologies change. Ongoing governance, security, and management validate whether the foundation and workload controls still meet requirements.
CAF Well Architected and secure adoption
Feed lessons from security operations into improvements to security standards, controls, and governance processes, using business goals and risk to guide the changes.
CAF Well Architected and secure adoption
An initiative groups related policy definitions into a single assignment, supporting consistent deployment and assessment of a set of governance requirements.
CAF Well Architected and secure adoption
Audit records noncompliance without blocking the operation. Deny blocks matching noncompliant resource requests when the policy applies. Audit results alone do not demonstrate preventive enforcement.
CAF Well Architected and secure adoption
The effect can deploy related configuration under its conditions, but existing resources generally require a remediation task. Configure the assignment identity and required permissions and verify remediation results.
CAF Well Architected and secure adoption
Assign common requirements at suitable management-group or subscription scopes so applicable descendants inherit them. Tailor narrower assignments and governed exemptions to justified workload needs.
CAF Well Architected and secure adoption
Document scope, justification, risk owner, compensating controls, and expiry or review. Use an appropriate scoped exemption and review it instead of weakening the baseline for every workload.
CAF Well Architected and secure adoption
A deny rule or remediation can affect deployments and existing dependencies. Test representative resources, assess impact, and use an approved rollout and recovery process.
CAF Well Architected and secure adoption
Microsoft Defender for Cloud supplies security posture recommendations and assessment. Use them with business risk and control ownership rather than treating a score as complete assurance.
CAF Well Architected and secure adoption
Translate organizational requirements into repeatable workload controls and implementation guidance. Pair the baseline with deployment automation, ownership, monitoring, and a governed exception process.
CAF Well Architected and secure adoption
A control must be shown to work. Define the configuration assessment, access test, collected logs, remediation evidence, or operational exercise that demonstrates the expected result.
CAF Well Architected and secure adoption
The platform landing zone provides the centralized foundation, governance, security, and shared resources. Workload landing zones host workload-owned resources within platform guardrails.
CAF Well Architected and secure adoption
A workload has a workload landing zone containing its required environments. Each environment uses one or more subscriptions according to workload requirements, ownership boundaries, and platform limits.
CAF Well Architected and secure adoption
It organizes subscriptions and applies inherited governance standards consistently. Separate platform and workload resources while avoiding unnecessary hierarchy complexity.
CAF Well Architected and secure adoption
Connectivity and networking, security monitoring, identity services, and management services. Centralize capabilities when they provide clear governance, operational, or economic benefits.
CAF Well Architected and secure adoption
A repeatable process for requesting, creating, and distributing governed workload subscriptions. Automation applies organizational security and governance baselines consistently as demand grows.
CAF Well Architected and secure adoption
Workload teams need authority over their own resources without unrestricted control over shared security, connectivity, or governance. Narrow scope limits the effect of compromised workload credentials.
CAF Well Architected and secure adoption
Microsoft-provided infrastructure-as-code deployment patterns that implement recommended platform or workload architectures. Adapt and validate them against organizational requirements rather than treating deployment as complete assurance.
CAF Well Architected and secure adoption
Deploy AI resources within workload landing zones and update central governance and security standards for new requirements. AI data, model, and agent controls extend the foundation rather than removing its guardrails.
CAF Well Architected and secure adoption
Peering or central placement of a firewall does not by itself prove that all required paths traverse inspection. Validate routing, DNS, segmentation, and allowed access for the selected architecture.
CAF Well Architected and secure adoption
Check inherited policy and appropriate RBAC, approved connectivity, security monitoring, relevant Defender coverage, ownership, and required operational controls. Verify outcomes rather than only subscription creation.
CAF Well Architected and secure adoption
Security is integrated into design, development, build, release, and operations, with development ownership supported by security expertise and reusable platform standards.
CAF Well Architected and secure adoption
It identifies assets, trust boundaries, threats, and required mitigations while design changes are easier. Update the model when interfaces, data flows, or privileges materially change.
CAF Well Architected and secure adoption
SAST inspects code, SCA assesses components and dependencies, and DAST exercises a running application. Their findings complement one another rather than proving the same security property.
CAF Well Architected and secure adoption
Potential exposed credentials or secrets in supported code and workflow locations. Detection must trigger revocation or rotation and remediation; deleting visible text alone does not invalidate a leaked credential.
CAF Well Architected and secure adoption
Prefer supported scoped workload identity federation or managed identity, restrict the workflow or environment that may obtain access, and grant only the deployment permissions required.
CAF Well Architected and secure adoption
An attacker who changes code or release workflows can compromise the deployed system. Peer review, controlled merges, protected identities, and security checks protect the path to production.
CAF Well Architected and secure adoption
An SBOM identifies the components and dependencies used in development, build, integration, and deployment. Use it to track affected software and prioritize remediation when a dependency vulnerability is disclosed.
CAF Well Architected and secure adoption
Use separate environments and scoped identities or connections; prevent test workflows from obtaining production authority. Apply independent approval where production impact warrants it.
CAF Well Architected and secure adoption
Risk-based criteria, actionable findings, clear owners, and a governed exception process. A routinely bypassed or untriaged gate does not deliver its intended control.
CAF Well Architected and secure adoption
Runtime monitoring, vulnerability response, incident handling, recovery, and lessons from production feed back into the backlog and secure design. Pre-release tests cannot detect every future weakness.
Security operations detection and response
Related security signals across endpoints, identities, email, and applications into incidents that describe attacks.
Security operations detection and response
When it needs third-party or multicloud logs, custom detection, and enterprise-wide investigation beyond the XDR product domains.
Security operations detection and response
Its associated alerts, entities, and relevant context for triage and investigation.
Security operations detection and response
Status, owner, and closing reason synchronize between the paired incidents.
Security operations detection and response
They can create duplicate incidents for alerts already correlated by Defender XDR.
Security operations detection and response
The Defender XDR correlation engine chooses incident titles; stable tags or other suitable conditions are safer.
Security operations detection and response
No. Some tables, including TVM tables, appear in the schema without their data being ingested.
Security operations detection and response
It supplies selected event-level data for Sentinel queries; incident integration alone does not prove all raw tables are available.
Security operations detection and response
Incident integration is enabled but the required Defender for Cloud alert/entity connector is missing.
Security operations detection and response
Sentinel enterprise and third-party data with Defender incidents and security signals in the Defender portal.
Security operations detection and response
Audited user and administrator operations across supported Microsoft services for forensic and compliance investigation.
Security operations detection and response
180 days; the older 90-day default applies to records generated before 17 October 2023.
Security operations detection and response
Microsoft Entra ID, Exchange, OneDrive, and SharePoint audit records for appropriately licensed users.
Security operations detection and response
The per-user ten-year retention add-on plus an appropriate retention policy; the policy is not retroactive.
Security operations detection and response
A fixed one year; custom audit retention policies do not apply to those non-user records.
Security operations detection and response
The service, audited activities, and users generating the records.
Security operations detection and response
Other activities retain their default period unless an applicable custom policy extends retention.
Security operations detection and response
Use supported access such as the Office 365 Management Activity API, with planned permissions and collection.
Security operations detection and response
Higher-value activity details, including mail access and searches, that can help establish compromise scope.
Security operations detection and response
Audit records are sensitive evidence; only investigators with necessary audit permissions should search them.
Security operations detection and response
Use Azure Arc-enabled servers with Azure Monitor Agent and appropriate data collection rules.
Security operations detection and response
Data collection rules specify the intended telemetry and destinations.
Security operations detection and response
AWS CloudTrail and GCP Cloud Audit Logs, ingested through suitable Sentinel connectors.
Security operations detection and response
No. Guest telemetry and cloud-provider control-plane audit logs require different collection paths.
Security operations detection and response
Microsoft Sentinel can consolidate them in a Log Analytics workspace through suitable connectors.
Security operations detection and response
Application Insights with the appropriate SDKs.
Security operations detection and response
Use the Azure Monitor Logs Ingestion API with the appropriate collection configuration.
Security operations detection and response
Appropriate Container insights or managed Prometheus collection, including Arc or remote-write paths.
Security operations detection and response
Azure Update Manager assesses and installs updates independently of Azure Monitor log collection.
Security operations detection and response
Guest OS, applications, cloud control plane, containers, and custom sources, with an explicit collection path for each.
Security operations detection and response
Centrally coordinate incident handling and trigger playbooks based on supported events and conditions.
Security operations detection and response
Incident creation, incident update, or alert creation, subject to configured conditions.
Security operations detection and response
Assign owners, change status, add tags or tasks, and close incidents with reasons.
Security operations detection and response
Playbooks built on Azure Logic Apps.
Security operations detection and response
An analytics rule detects threats; a playbook executes a response workflow.
Security operations detection and response
The workflow identity needs narrowly scoped rights for its connector actions.
Security operations detection and response
It reduces unintended business disruption when automatic action could disable a critical service.
Security operations detection and response
The order in which configured rules and actions execute for a matching event.
Security operations detection and response
A workflow can change an incident that triggers further updates; conditions must prevent unintended repeated action.
Security operations detection and response
Actions attempted, results, failures, and relevant approval context for investigation and recovery.
Security operations detection and response
A testable hypothesis about an undetected threat or malicious behavior.
Security operations detection and response
It searches available evidence proactively, including behavior that existing detections may miss.
Security operations detection and response
Selected query results, the query, annotations, and relevant entity context.
Security operations detection and response
Create or enrich an incident with relevant hunting evidence.
Security operations detection and response
Record whether the evidence validates or invalidates the hypothesis and document the reasoning.
Security operations detection and response
New analytics rules, threat indicators, and incidents based on validated findings.
Security operations detection and response
The operational state of the hunt; it is distinct from whether its hypothesis was validated.
Security operations detection and response
An uncommon process can be legitimate; investigate context before creating a high-noise detector.
Security operations detection and response
Validated hypotheses, incidents created, and new analytics rules.
Security operations detection and response
No. They remain in the Sentinel-specific hunting experience; use appropriate alternatives in Advanced hunting.
Security operations detection and response
An adversary’s objective; a technique describes how that objective is pursued.
Security operations detection and response
ATT&CK technique coverage from active analytics and relevant available detection content.
The current Microsoft Learn page marks Sentinel MITRE ATT&CK coverage as preview. Verify current availability; coverage mappings are not proof that every relevant technique is detected in the deployed environment.
Security operations detection and response
That required telemetry arrives and the rule detects the relevant behavior reliably.
Security operations detection and response
It identifies relevant content that could fill a detection gap after prerequisites and tuning are assessed.
Security operations detection and response
Confirm data dependencies and safely test representative behavior; review detection quality and response.
Security operations detection and response
ATT&CK for ICS; OT-specific Defender for IoT content includes ICS technique mappings.
Security operations detection and response
OT analytics rules, workbooks, playbooks, and incident mappings to ICS techniques.
Security operations detection and response
Response can affect physical processes and availability; OT context must guide safe action.
Security operations detection and response
Matrices and telemetry differ; validate the techniques and data relevant to the actual mobile environment.
Security operations detection and response
By relevant adversary behavior, asset impact, available telemetry, and feasible detection—not simply the number of colored cells.
Identity authentication and access
The signed-in user represented in the delegated access token.
Identity authentication and access
The agent identity; target agent identities or their blueprint with supported policies.
Identity authentication and access
Agent Users, targeted explicitly; ordinary Users assignments do not apply.
Identity authentication and access
No. Blueprint targeting covers agent identities, including future ones from that blueprint, rather than linked user accounts.
Identity authentication and access
The original token has a different audience; the agent needs a downstream token for the target resource.
Identity authentication and access
That request bypasses Entra token issuance, so Entra Conditional Access does not evaluate it.
Identity authentication and access
No. Even all-users or group-based Users targeting excludes agent user accounts under current documented scope rules.
Identity authentication and access
No. Current documentation does not support including or excluding agent user accounts through group membership.
Identity authentication and access
Define configuration and governance for creating related agent identities; runtime tasks use the agent identity.
Identity authentication and access
The resource validates the token and grants only authorized actions; successful token issuance is not unrestricted tool access.
Identity authentication and access
Identity establishes the caller and access conditions, network controls reachability, and application authorization permitted actions.
Identity authentication and access
SSO authenticates the user; the application still needs appropriate roles, assignments, or permission checks.
Identity authentication and access
Appropriate application assignment, provisioning/deprovisioning, and application permissions.
Identity authentication and access
Private reachability does not replace data-plane authentication and authorization.
Identity authentication and access
Use supported managed identities or workload identity federation with minimal resource permissions.
Identity authentication and access
Azure resource-management permissions and guest OS authentication are different planes. However, management actions such as Run Command, VM extensions, and password resets can provide indirect guest control. Assess those effective permissions as privileged access paths.
Microsoft Learn documents VM Contributor software execution, password reset, and local account management through extensions; Windows Run Command scripts run as System. Supporting reference: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command
Identity authentication and access
Its supported authentication protocol, resource authorization, client support, and network publication path.
Identity authentication and access
It authenticates identities; native cloud role mappings and effective permissions still determine allowed actions.
Identity authentication and access
Evaluate supported sign-in/token requests using identity, resource, and context signals; it does not replace all resource controls.
Identity authentication and access
Test intended and denied user/workload paths, including offboarding, unauthorized permissions, and network bypass attempts.
Identity authentication and access
Cloud sign-in can be validated by Entra ID without contacting on-premises authentication infrastructure.
Identity authentication and access
Available on-premises authentication agents and connectivity to validate the credentials.
Identity authentication and access
Authentication to a trusted external identity system, whose availability and security become part of the sign-in path.
Identity authentication and access
It can support a planned fallback and cloud identity protection scenarios; fallback must be deliberately designed.
Identity authentication and access
No. It synchronizes a derived password hash rather than clear-text passwords.
Identity authentication and access
They influence hybrid identity trust and can provide powerful paths into cloud and directory access.
Identity authentication and access
A documented authentication requirement unavailable in supported managed authentication, evaluated against federation complexity.
Identity authentication and access
To reduce reliance on a single authentication agent; on-premises dependencies still remain.
Identity authentication and access
Authentication service loss, synchronization recovery, fallback activation, and emergency cloud administration.
Identity authentication and access
Synchronization creates/updates identity information; authentication validates sign-in through the chosen method.
Identity authentication and access
External users use their identities to access resources in a resource organization under its access policies.
Identity authentication and access
External identities accessing your organization’s resources.
Identity authentication and access
Your users accessing other organizations with your organizational identities.
Identity authentication and access
When supported inbound trust settings are explicitly configured; the resource tenant still evaluates its access policy.
Identity authentication and access
No. Trust decisions and the resource’s authorization assignments remain separate.
Identity authentication and access
Use an entitlement management access package with approval, duration, and review.
Identity authentication and access
The issuer signs credentials, the holder presents them, and the verifier checks the evidence.
Identity authentication and access
No. The relying service decides how verified claims support its authorization policy.
Identity authentication and access
Issuer trust and cryptographic validity, plus relevant expiry, status, and presentation requirements.
Identity authentication and access
They can prove trusted claims without sharing an institution’s account password.
Identity authentication and access
If configured assignments and conditions match, enforce the specified grant and session controls.
Identity authentication and access
All applicable requirements are evaluated; a weaker grant does not override an applicable block.
Identity authentication and access
The probability that a particular authentication request is unauthorized.
Identity authentication and access
The probability that the identity itself is compromised.
Identity authentication and access
The acceptable combinations of authentication methods for access.
Identity authentication and access
Their method may not be in the required authentication strength, such as phishing-resistant MFA.
Identity authentication and access
Supported resources and clients can react to critical identity events without waiting for ordinary token expiry.
Identity authentication and access
It depends on supported clients/resources and can have propagation delay.
Identity authentication and access
Action-time Conditional Access requirements for selected sensitive permissions using authentication context.
Identity authentication and access
PIM temporarily grants a role; protected actions check conditions when selected sensitive operations are attempted.
Identity authentication and access
It combines available identity, device, resource, location, and risk signals rather than trusting one perimeter.
Identity authentication and access
A valid internal location does not prove the user or device is uncompromised.
Identity authentication and access
Evaluates and records policy effects without enforcing access controls.
Identity authentication and access
Representative actual sign-in tests and log review, including dependencies and exceptional journeys.
Identity authentication and access
A narrow scope, accountable owner, business rationale, expiry, and periodic review.
Identity authentication and access
Users need supported methods and recovery paths to avoid lockout.
Identity authentication and access
No. Workload, agent identity, and agent user scopes have distinct support and targeting requirements.
Identity authentication and access
Limit resource assignments, API permissions, and roles; conditional sign-in is not authorization minimization.
Identity authentication and access
Test detection, session revocation, and containment paths as well as successful sign-in.
Identity authentication and access
Supported controls and token/session paths can differ across clients and identity types.
Identity authentication and access
Identify identity misconfigurations and recommend remediation; they do not automatically make every configuration safe.
Identity authentication and access
Unsigned LDAP traffic is susceptible to man-in-the-middle attacks; assess compatibility before enforcement.
Identity authentication and access
It prevents delegation of the privileged identity’s credentials; evaluate legitimate delegation dependencies.
Identity authentication and access
It permits broad impersonation; constrain or remove delegation according to the legitimate service requirement.
Identity authentication and access
Certificate misconfigurations can enable unauthorized identity access or privilege escalation.
Identity authentication and access
A sensor installed on the AD CS server; template assessments have a different documented availability boundary.
Identity authentication and access
A Defender for Identity sensor on servers running Entra Connect services.
Identity authentication and access
Lower-trust services can expose privileged credentials or abuse delegation into more sensitive systems.
Identity authentication and access
Accounts, groups, and delegated permissions can create indirect privileged access paths.
Identity authentication and access
Reassess affected entities, test legitimate service behavior, and allow for score/status update delay.
Identity authentication and access
Secrets, cryptographic keys, and certificates with their associated private-key material.
Identity authentication and access
They can eliminate reusable application secrets while retaining identity-based least-privileged authorization.
Identity authentication and access
Store it as a Key Vault certificate and configure autorotation for its supported certificate lifecycle, rather than managing it solely as an ordinary secret.
Identity authentication and access
Managing the resource and reading or using its sensitive objects are different privilege boundaries.
Identity authentication and access
A recoverable period after deletion rather than immediate permanent loss.
Identity authentication and access
It prevents permanent purge during the retention window, protecting against destructive loss.
Identity authentication and access
Consumers may retain caches or version-pinned references; adoption must be verified.
Identity authentication and access
Azure Key Vault Managed HSM for cryptographic keys.
Identity authentication and access
Lost, disabled, or deleted required keys can make dependent data services unavailable.
Identity authentication and access
Recording secret values, credentials, or temporary tokens in diagnostic or pipeline logs.
Privileged access and governance
Enterprise identity, trust, and access decisions that can control who receives privileges.
Privileged access and governance
Administer infrastructure and workloads at scale, often through powerful central management systems.
Privileged access and governance
Business applications, processes, and information that the organization values.
Privileged access and governance
Their control of many systems can turn a management-tool compromise into broad workload compromise.
Privileged access and governance
By the highest-impact resources and trust decisions it can control, including indirect authority.
Privileged access and governance
It can enable control of another identity and therefore its access, even without the same visible role.
Privileged access and governance
Grant the minimum actions at the minimum resource scope needed for the assigned job.
Privileged access and governance
Operating a workload should not automatically allow the operator to grant broader access to others.
Privileged access and governance
Indirect or inherited permissions can undermine an apparently narrow direct assignment.
Privileged access and governance
Avoid letting the same actor independently request, approve, execute, and erase evidence of sensitive work.
Privileged access and governance
Requesting activation under configured conditions; it does not grant the role’s privileges until activated.
Privileged access and governance
The assigned role’s privileges for the configured duration without a separate activation step.
Privileged access and governance
Time limits, approval, justification, MFA, notifications, and relevant audit history.
Privileged access and governance
Eligibility remains a path to future privileged activation and can become excessive or stale.
Privileged access and governance
Manage supported group membership or ownership with time-bound or just-in-time access.
Privileged access and governance
Access request, assignment, review, and expiry through supported access packages.
Privileged access and governance
A governed bundle of supported resource access needed for a project or role.
Privileged access and governance
Whether existing access still has a legitimate business reason.
Privileged access and governance
An activated privileged role can still be abused from a compromised session or workstation.
Privileged access and governance
Its supported role/group scope is bounded; native third-party permissions need their own governance design.
Privileged access and governance
A stolen NTLM hash to authenticate or move to another system.
Privileged access and governance
A stolen Kerberos ticket to gain access as its represented identity.
Privileged access and governance
Service-ticket material associated with service accounts for offline password cracking.
Privileged access and governance
Directory replication to extract credential data such as password hashes.
Privileged access and governance
An attacker can issue malicious certificates that support later authentication as unauthorized identities.
Privileged access and governance
Indirect access can expose credentials or privileged control even without obvious administrator membership.
Privileged access and governance
Trusted usable backups and required Domain Admin/DSRM recovery credentials under secure procedures.
Privileged access and governance
Every domain needs recovery from an available trusted backup; one restored root DC alone is insufficient.
Privileged access and governance
It might already contain the compromise or dangerous state; balance recentness with trusted integrity.
Privileged access and governance
Recovered identity state must be assessed before reintroducing it into trusted operations.
Privileged access and governance
Federated, native, automation, and recovery paths may each grant powerful control and need protection.
Privileged access and governance
Productivity activity should not expose the credentials and sessions used for sensitive administration.
Privileged access and governance
Their permissions can control production workloads even when they are not human administrator accounts.
Privileged access and governance
No. Native accounts and application-specific roles must be inventoried and governed.
Privileged access and governance
Phishing-resistant authentication, a trusted workstation, limited interfaces, and monitoring.
Privileged access and governance
At least two to reduce lockout and single-account dependency.
Privileged access and governance
They avoid dependency on federated or synchronized on-premises identities during an outage.
Privileged access and governance
Permanent active, so emergency recovery does not depend on an unavailable activation or approval path.
Privileged access and governance
Exclude them from policies that block or restrict sign-in; keep strong independent authentication and monitoring.
Privileged access and governance
Alerts on sign-in/audit activity and regular validation that authorized recovery remains usable.
Privileged access and governance
Excessive, unused, misconfigured, and risky infrastructure permissions across cloud identities and resources.
Privileged access and governance
Azure, AWS, and GCP, across supported identity and resource types.
Privileged access and governance
No. The documentation explicitly states the deprecation does not affect existing Defender for Cloud CIEM.
Privileged access and governance
What an identity can actually reach and do, rather than merely the names of assigned roles.
Privileged access and governance
Service principals, managed identities, and service accounts can hold excessive access and support lateral movement.
Privileged access and governance
Queries about identities, resources, permissions, and contextual exposure.
Privileged access and governance
It links risky identities and exposed resources to routes toward sensitive or business-critical targets.
Privileged access and governance
Observed inactivity may omit rare legitimate operations; rights reduction should preserve required workload behavior.
Privileged access and governance
CIEM assesses authorization risk and excessive permissions; MFA strengthens authentication.
Privileged access and governance
Recertify whether existing resource access remains justified and apply the resulting decisions.
Privileged access and governance
They can assess the legitimate business need for continued access.
Privileged access and governance
An alternate reviewer used when the chosen owner or manager is unavailable.
Privileged access and governance
Unanswered reviews otherwise may leave unjustified access; the chosen policy must be deliberate and auditable.
Privileged access and governance
Applies completed review outcomes, such as membership or assignment removal, where supported.
Privileged access and governance
Decision support based on configured usage criteria, not conclusive proof that the access has no legitimate purpose.
Privileged access and governance
No. On-premises AD remains the source of authority, so results need an appropriate source-side action.
Privileged access and governance
If the group is the governed access path to the resources, its membership can represent the relevant entitlement bundle.
Privileged access and governance
Direct rights assigned outside the observed Entra groups/app assignments, such as some direct resource grants.
Privileged access and governance
Use limited scope, initially control result application, document removals, and monitor audit records.
Privileged access and governance
The originating device must be trustworthy; a compromised device can undermine account and session controls.
Privileged access and governance
Malware on the source can steal credentials, impersonate the user, or control the privileged session.
Privileged access and governance
General browsing, unapproved software, local administrative rights, and unnecessary applications.
Privileged access and governance
A trusted hardware/firmware chain with TPM, Secure Boot, disk encryption, and relevant platform protections.
Privileged access and governance
Central management applies baselines, updates, approved applications, and compliance controls.
Privileged access and governance
Hardening reduces attack surface, but detection is still needed to identify device compromise.
Privileged access and governance
Device, account, intermediaries, and administrative application interface.
Privileged access and governance
Remote transport and intermediaries do not remove the source device’s credential/session compromise risk.
Privileged access and governance
Necessary management interfaces can be allowlisted while reducing exposure to arbitrary web content.
Privileged access and governance
Match device restrictions and trust to the sensitivity and impact of the privileges used.
Regulatory compliance and controls
Define the requirement and its in-scope services, data, identities, and organizational responsibilities.
Regulatory compliance and controls
A stated objective, implementation, owner, evidence, and success criteria.
Regulatory compliance and controls
A requirement implemented and operated by the customer organization.
Regulatory compliance and controls
A control Microsoft implements for its cloud service within the assessed scope.
Regulatory compliance and controls
A requirement with implementation responsibilities divided between Microsoft and the customer.
Regulatory compliance and controls
It covers provider-managed scope; the customer’s configurations, processes, and responsibilities still require assessment.
Regulatory compliance and controls
Controls associated with a regulation, standard, or organizational policy.
Regulatory compliance and controls
Assign implementation/testing work, track status, and retain evidence and notes.
Regulatory compliance and controls
Its owner, residual risk, duration, and compensating controls need documented review.
Regulatory compliance and controls
Prioritization and progress tracking; it is not a legal assurance verdict for the entire organization.
Regulatory compliance and controls
Sensitivity labels, with configured protection such as encryption and markings.
Regulatory compliance and controls
Data Loss Prevention policies with specified locations, conditions, and actions.
Regulatory compliance and controls
Whether content is retained, deleted, or retained and then deleted for the configured period.
Regulatory compliance and controls
Audit retention preserves operation records; content retention preserves or deletes the underlying information.
Regulatory compliance and controls
Relevant content in selected case locations during an investigation.
Regulatory compliance and controls
Related searches, holds, and review sets with case-specific access control.
Regulatory compliance and controls
Label protection and DLP rules are separate configurations; policy conditions and actions must be designed.
Regulatory compliance and controls
Policies only assess supported configured channels and activities; coverage must match the actual data paths.
Regulatory compliance and controls
Assessment workflows organize accountability/evidence, while the relevant solutions implement data and investigation controls.
Regulatory compliance and controls
Azure resource configuration/state against assigned policy rules, with effect behavior defined by the policy.
Regulatory compliance and controls
Policy constrains resource configuration; RBAC determines who can perform permitted resource actions.
Regulatory compliance and controls
A collection of policy definitions managed and assigned together toward an overarching goal.
Regulatory compliance and controls
Records noncompliance without blocking the resource request.
Regulatory compliance and controls
Prevents the request; it does not retroactively repair an existing resource.
Regulatory compliance and controls
Deploy a required related configuration when its existence condition is not satisfied, subject to policy behavior and permissions.
Regulatory compliance and controls
Changing supported resource properties to meet policy requirements.
Regulatory compliance and controls
The policy assignment’s managed identity, with the minimum required Azure roles.
Regulatory compliance and controls
An appropriate remediation task and sufficient assignment-identity permissions.
Regulatory compliance and controls
No. An applicable denying assignment must be changed or appropriately excluded/exempted; another grant does not override it.
Regulatory compliance and controls
Supported resource security configurations against assigned compliance controls and standards.
Regulatory compliance and controls
Azure, AWS, and GCP, with appropriate onboarding and plan support.
Regulatory compliance and controls
Microsoft Cloud Security Benchmark (MCSB) under the documented onboarding defaults.
Regulatory compliance and controls
Current documentation requires at least one paid Defender for Cloud plan.
Regulatory compliance and controls
Its assessments, affected resources, and remediation information.
Regulatory compliance and controls
Manual attestation with relevant evidence for the scoped subscriptions.
Regulatory compliance and controls
Relevant assessments run periodically; the dashboard reflects changes after the next assessment.
Regulatory compliance and controls
Resource-level compliance data for the same standard contributes to broader centralized improvement-action tracking.
Regulatory compliance and controls
No. It is evidence within supported assessment scope; customer and manual obligations still require validation.
Regulatory compliance and controls
A summary based on the standard’s Defender assessment data, useful evidence rather than universal certification.
Hybrid multicloud posture and exposure
Cloud resource configuration and posture against security standards, producing recommendations to reduce misconfiguration risk.
Hybrid multicloud posture and exposure
CSPM improves configuration posture; CWPP detects and responds to threats affecting running workloads.
Hybrid multicloud posture and exposure
Foundational CSPM, available at no cost.
Hybrid multicloud posture and exposure
The paid Defender CSPM plan; verify feature support for the connected environment.
Hybrid multicloud posture and exposure
MCSB provides consistent cloud security principles and platform-specific implementation guidance for evaluating resource security.
Hybrid multicloud posture and exposure
MCSB begins assessing resources in scope; additional benchmarks and standards can also apply.
Hybrid multicloud posture and exposure
The Regulatory compliance dashboard provides a dedicated benchmark view.
Hybrid multicloud posture and exposure
No. Assessment covers supported resource controls; full compliance also requires applicable manual evidence and organizational responsibilities.
Hybrid multicloud posture and exposure
Lower identified risk from the assessed recommendations, rather than proof that every security risk is eliminated.
Hybrid multicloud posture and exposure
MCSB v2 is documented as preview and can be enabled from the Regulatory compliance dashboard; validate preview suitability.
Hybrid multicloud posture and exposure
Accept the risk or remaining risk for the recommended action. Record the decision and residual exposure; risk acceptance does not mean the recommended mitigation was implemented.
Hybrid multicloud posture and exposure
In the Microsoft Defender portal at the Secure Score experience.
Hybrid multicloud posture and exposure
No. It measures recommended actions and does not guarantee protection against every threat.
Hybrid multicloud posture and exposure
Progress in implementing recommended controls over time and changes in measured security posture.
Hybrid multicloud posture and exposure
The score can reflect qualifying third-party solutions when the associated recommendation is addressed; document the actual protection.
Hybrid multicloud posture and exposure
Available products and capabilities affect the recommendations and actions the organization can implement.
Hybrid multicloud posture and exposure
To provide benchmark context and support improvement planning, not to prove equal business risk.
Hybrid multicloud posture and exposure
Business impact and actual exposure; point gain alone should not determine the remediation order.
Hybrid multicloud posture and exposure
Microsoft 365 identities, applications, and devices across the supported Microsoft security estate.
Hybrid multicloud posture and exposure
Defender for Cloud secure score. It is a different score system from Microsoft Secure Score.
Hybrid multicloud posture and exposure
CSPM for configuration posture and CWPP for workload threat protection.
Hybrid multicloud posture and exposure
Through cloud connectors with required permissions for the AWS accounts and GCP projects being assessed.
Hybrid multicloud posture and exposure
The clouds, accounts, projects, subscriptions, workloads, owners, and required security capabilities in scope.
Hybrid multicloud posture and exposure
They determine required capabilities, onboarding prerequisites, supported environments, and the deployment approach.
Hybrid multicloud posture and exposure
Some runtime protections require endpoint agents or in-cluster components beyond provider-API posture collection.
Hybrid multicloud posture and exposure
Connectivity, permissions, discovered-resource coverage, required protection components, and operational handling of findings.
Hybrid multicloud posture and exposure
It supplies supported snapshot-based findings and does not replace continuous endpoint EDR telemetry.
Hybrid multicloud posture and exposure
An integration must remain complete as the estate changes; a one-time inventory can leave new resources unprotected.
Hybrid multicloud posture and exposure
Accountable resource owners remediate posture; security operations investigate threat alerts, with coordinated workflows.
Hybrid multicloud posture and exposure
It brings supported non-Azure servers into Azure management; native cloud connectors still serve their cloud scopes.
Hybrid multicloud posture and exposure
The workload type, required threat-detection capability, platform support, and deployment prerequisites.
Hybrid multicloud posture and exposure
Endpoint detection and response through integration with Microsoft Defender for Endpoint.
Hybrid multicloud posture and exposure
It includes Plan 1 capabilities and adds server protection features such as supported agentless scanning and just-in-time VM access.
Hybrid multicloud posture and exposure
Supported vulnerability, malware, and exposed-secret findings from machines.
Hybrid multicloud posture and exposure
Defender for Containers, with the required access and runtime components for the environment.
Hybrid multicloud posture and exposure
Defender for Storage, with required features enabled for the supported storage workload.
Hybrid multicloud posture and exposure
Choose the supported Defender for Databases plan matching the actual database engine and hosting model.
Hybrid multicloud posture and exposure
Operating system, environment, and capability support vary; an enabled plan alone does not establish feature parity.
Hybrid multicloud posture and exposure
No. Validate environment-specific support; Azure VM network access controls do not automatically extend to arbitrary on-premises hosts.
Hybrid multicloud posture and exposure
Runtime detection requires in-cluster components; enabling the plan does not prove those components are healthy.
Hybrid multicloud posture and exposure
Registers a supported non-Azure server as an Azure resource and enables Azure management integration.
Hybrid multicloud posture and exposure
No. The server remains in its hosting environment; Arc provides a management bridge.
Hybrid multicloud posture and exposure
Extensions can run as Local System on Windows or root on Linux, making extension deployment a privileged operation.
Hybrid multicloud posture and exposure
Permission to deploy extensions can translate into effective administrative control of the connected host.
Hybrid multicloud posture and exposure
Outbound access to required Azure endpoints; Arc registration does not require a public inbound management port.
Hybrid multicloud posture and exposure
The customer remains responsible for the machine, agent maintenance, access permissions, and extension security.
Hybrid multicloud posture and exposure
Restrict permitted extensions or disable extension operations where they are not needed.
Hybrid multicloud posture and exposure
The Azure Connected Machine Onboarding role at the resource groups or subscriptions actually needed for registration, with later host-administration powers assigned separately.
Hybrid multicloud posture and exposure
Updates address security, reliability, and service compatibility; registering a machine is not the end of maintenance.
Hybrid multicloud posture and exposure
Local access to identity tokens and the permissions granted to that identity; it should not become an escalation path.
Hybrid multicloud posture and exposure
An external, internet-facing perspective on the organization’s online infrastructure.
Hybrid multicloud posture and exposure
A known legitimate organizational asset used to start recursive discovery of related infrastructure.
Hybrid multicloud posture and exposure
It follows observed relationships from known assets and infers connections to additional infrastructure.
Hybrid multicloud posture and exposure
Domains, hosts, IP addresses, and SSL certificates; its inventory also includes web pages and other related infrastructure.
Hybrid multicloud posture and exposure
Relationships are inferred; a discovered asset may belong to a vendor or unrelated organization rather than the customer.
Hybrid multicloud posture and exposure
It can discover related internet-facing infrastructure missing from the acquiring company’s internal inventory.
Hybrid multicloud posture and exposure
No. External surface discovery does not supply complete host EDR or internal operating-system configuration evidence.
Hybrid multicloud posture and exposure
Service disruption or loss of trusted connectivity; certificate findings should reach an accountable owner.
Hybrid multicloud posture and exposure
The online attack surface changes; continuous discovery helps identify new and forgotten exposures.
Hybrid multicloud posture and exposure
Assign ownership, prioritize the risk, remediate through an appropriate workflow, and verify that exposure is reduced.
Hybrid multicloud posture and exposure
Security posture context across devices, identities, cloud resources, and external attack surfaces.
Hybrid multicloud posture and exposure
A connected route from an attacker entry point through weaknesses and permissions to critical assets.
Hybrid multicloud posture and exposure
The Defender portal experience covers cross-workload endpoint, cloud, and hybrid paths; the Azure portal experience focuses on cloud environments.
Hybrid multicloud posture and exposure
Criticality supplies business context so paths leading to important assets can receive suitable priority.
Hybrid multicloud posture and exposure
A weakness or permission whose removal interrupts several feasible attacker routes to critical assets.
Hybrid multicloud posture and exposure
Make paths absent or incomplete; no displayed path does not prove no exposure exists.
Hybrid multicloud posture and exposure
Related security metrics and recommendations around an improvement objective such as ransomware protection.
Hybrid multicloud posture and exposure
They provide contextual metrics and actionable improvement information for prioritizing and tracking exposure reduction.
Hybrid multicloud posture and exposure
Verify that the change interrupts the attacker route; other weaknesses or permissions may preserve access. For endpoint ASR rules, Audit logs risky behavior without blocking it, so an audited rule alone does not establish enforced path reduction.
Hybrid multicloud posture and exposure
It is available in the public cloud; validate suitability for sovereign or national-cloud requirements.
Server client IoT and OT security
Detection, investigation, and response for advanced threats on the running endpoint.
Server client IoT and OT security
Supported operating systems and protection features differ; validate each platform against the support matrix.
Server client IoT and OT security
A defined minimum configuration for that resource type, established and assessed through configuration management.
Server client IoT and OT security
To reduce the attack surface and the components that require patching and monitoring.
Server client IoT and OT security
Integrate alerts with the SIEM and security-operations process so they are investigated and acted on.
Server client IoT and OT security
When it needs Plan 1 EDR plus supported additional protections such as agentless scanning or just-in-time VM access.
Server client IoT and OT security
Scanning identifies weaknesses; prioritized corrective action and verification reduce the resulting exposure.
Server client IoT and OT security
No. The customer still secures and maintains the host and controls administrative access.
Server client IoT and OT security
As a residual-risk exception needing compensating controls and a remediation or replacement plan, rather than assumed secure.
Server client IoT and OT security
The feature’s operating-system and environment support, prerequisites, and deployment method.
Server client IoT and OT security
Configure focused security controls such as antivirus, firewall, encryption, EDR, and attack surface reduction on supported platforms.
Server client IoT and OT security
Compliance primarily evaluates requirements and reports status; configuration policies set device security settings.
Server client IoT and OT security
Intune reports compliance to Microsoft Entra ID, and Conditional Access can require appropriate compliance for access.
Server client IoT and OT security
Intune app protection policies, which govern apps and data rather than full-device settings.
Server client IoT and OT security
Its threat-level signal can feed Intune compliance and app protection policies, which can support access decisions.
Server client IoT and OT security
Security settings against unauthorized changes that could weaken endpoint protection.
Server client IoT and OT security
Target risky software behavior on supported Windows devices, such as Office child processes, obfuscated scripts, and code injection, using applicable ASR rule modes.
Server client IoT and OT security
The same setting may fail to apply or show a conflict requiring manual resolution.
Server client IoT and OT security
No. Capabilities vary by platform and supported policy type.
Server client IoT and OT security
The resulting device configuration, compliance, and protection health reported after delivery and evaluation.
Server client IoT and OT security
A compromise of that key can let an attacker impersonate many devices and compromise the fleet.
Server client IoT and OT security
X.509 certificates, TPM attestation, and symmetric keys, selected according to hardware and operational requirements.
Server client IoT and OT security
Protected cryptographic key generation and storage, with supported attestation for provisioning.
Server client IoT and OT security
Certificate lifecycle management, including issuance, renewal, replacement, and trust management.
Server client IoT and OT security
Exposed keys enable impersonation; secure hardware storage reduces extraction risk.
Server client IoT and OT security
The agent validates the signed update manifest and checks the binary hashes recorded in that trusted manifest.
Server client IoT and OT security
Encryption protects the channel; signatures and trusted hashes establish that the intended update content is authentic and unchanged.
Server client IoT and OT security
Assets, connections, edge infrastructure, and cloud services each need protection.
Server client IoT and OT security
Device identity and credentials, active access, and sensitive retained data as required by the lifecycle process.
Server client IoT and OT security
Agentless network monitoring with Defender for IoT, subject to traffic visibility and environment requirements.
Server client IoT and OT security
Specialized industrial devices often cannot run ordinary endpoint agents; network monitoring provides visibility without modifying them.
Server client IoT and OT security
Through a configured SPAN port or network TAP at an appropriate monitoring location.
Server client IoT and OT security
Data collection, processing, analysis, and alerting occur on the sensor; selected telemetry and insights can reach Azure.
Server client IoT and OT security
Device inventory, communication patterns, vulnerabilities, and suspicious or unauthorized activity.
Server client IoT and OT security
Deviations from expected operations, such as unauthorized function codes, access, or configuration changes.
Server client IoT and OT security
Use locally managed sensors with sensor-console visibility rather than mandatory cloud connectivity.
Server client IoT and OT security
They must be uploaded manually; cloud-connected sensors can receive packages automatically.
Server client IoT and OT security
Integrate with Microsoft Sentinel or other supported SOC, SIEM, SOAR, and API workflows.
Server client IoT and OT security
Site-specific operational safety processes and applicable industry requirements, not a cloud dashboard alone.
Server client IoT and OT security
A sensor can analyze only traffic it receives; incomplete mirroring leaves devices or communications invisible.
Server client IoT and OT security
A group of preconfigured recommended Windows security settings that can be customized and deployed to managed devices.
Server client IoT and OT security
No. Customize it for justified environment requirements and evaluate new baseline versions as guidance changes.
Server client IoT and OT security
Supported Windows devices; it is not a universal baseline for every mobile or Linux platform.
Server client IoT and OT security
They focus on specific control areas; a baseline groups recommended settings across a broader posture.
Server client IoT and OT security
Different values for the same setting can cause configuration conflicts or unexpected effective state.
Server client IoT and OT security
Configuration requirements suited to each resource type, established through deployment and configuration management.
Server client IoT and OT security
To test business compatibility and resulting security settings before potentially disruptive fleet-wide deployment.
Server client IoT and OT security
A compliance policy, using the resulting device state to evaluate the required conditions.
Server client IoT and OT security
Changed settings, assignments, conflicts, and the actual resulting configuration on targeted devices.
Server client IoT and OT security
Settings can drift or new resources can bypass the intended baseline; continuous assessment detects deviations.
Server client IoT and OT security
The password of a local administrator account on supported joined Windows devices, and supported DC DSRM account passwords.
Server client IoT and OT security
It rotates unique per-device local administrator passwords rather than leaving a reusable password across the fleet.
Server client IoT and OT security
Microsoft Entra ID or Windows Server Active Directory, according to the selected backup policy and join scenario.
Server client IoT and OT security
Windows Server 2016 domain functional level or later.
Server client IoT and OT security
LAPS-capable Windows Server 2019 or later domain controllers; Server 2016 and earlier DCs do not support this feature.
Server client IoT and OT security
No. DSRM password backup requires Windows Server Active Directory and enabled password encryption.
Server client IoT and OT security
No. The reader must also be an authorized decryption principal.
Server client IoT and OT security
Update the Active Directory schema for Windows LAPS, then configure required computer and administrator permissions.
Server client IoT and OT security
It rotates the managed local account password after a configurable grace period to limit continued reuse.
Server client IoT and OT security
No. Password reset after authentication is not supported for the DSRM account on domain controllers.
SaaS PaaS IaaS containers and AI services
Protecting customer data, configuring controlled settings, and managing identities and access.
SaaS PaaS IaaS containers and AI services
The customer manages guest OS security, updates, and configuration.
SaaS PaaS IaaS containers and AI services
Microsoft manages the underlying platform OS; the customer still secures its applications, data, and controlled settings.
SaaS PaaS IaaS containers and AI services
No. Customers still manage accounts, permissions, access controls, and the security settings they control.
SaaS PaaS IaaS containers and AI services
Define controls suited to each service’s capabilities and the customer’s actual responsibilities rather than copying one OS baseline everywhere.
SaaS PaaS IaaS containers and AI services
They translate common security principles into configuration requirements for the particular cloud service.
SaaS PaaS IaaS containers and AI services
Microsoft operates the underlying physical cloud infrastructure.
SaaS PaaS IaaS containers and AI services
Use infrastructure and configuration automation with appropriate policy guardrails to establish the baseline from the start.
SaaS PaaS IaaS containers and AI services
Guardrails for new deployments do not prove previously deployed resources meet the baseline.
SaaS PaaS IaaS containers and AI services
Control responsibilities vary by service model, and unmanaged customer settings can leave exposure even when the provider secures its platform.
SaaS PaaS IaaS containers and AI services
Rotation limits how long a compromised credential can be reused and supports long-lived device operation.
SaaS PaaS IaaS containers and AI services
Per-device authorization and revocation reduce the impact of a compromised device credential.
SaaS PaaS IaaS containers and AI services
They can grant more service access than a single device needs; use scoped device credentials and permissions.
SaaS PaaS IaaS containers and AI services
Use Microsoft Entra identities and appropriate least-privilege RBAC rather than broadly distributing shared secrets.
SaaS PaaS IaaS containers and AI services
TLS with trustworthy certificate validation and securely managed authentication credentials.
SaaS PaaS IaaS containers and AI services
The edge handles local data, identities, and management operations that remain attack targets outside the cloud service.
SaaS PaaS IaaS containers and AI services
They restrict supported service access through private network paths; they do not replace authentication or permissions.
SaaS PaaS IaaS containers and AI services
To limit reachable control paths and prevent one compromised boundary from freely reaching the others.
SaaS PaaS IaaS containers and AI services
Device metadata, desired configuration, and reported state used to target and verify management operations.
SaaS PaaS IaaS containers and AI services
Monitoring data and control commands have different trust and safety implications; command authority must be explicitly constrained.
SaaS PaaS IaaS containers and AI services
Each path has different users, permissions, reachability, and threat exposure; one ingress control does not secure all of them.
SaaS PaaS IaaS containers and AI services
Inbound access from private networks through Private Link using an address from the virtual network.
SaaS PaaS IaaS containers and AI services
Disable public network access and verify the intended private access path.
SaaS PaaS IaaS containers and AI services
No. Outbound access uses other features such as virtual network integration; private endpoints serve inbound access.
SaaS PaaS IaaS containers and AI services
Clients must resolve the application name to the private endpoint’s address rather than an unsuitable public path.
SaaS PaaS IaaS containers and AI services
A web application firewall on a supported web ingress service; it complements secure application code.
SaaS PaaS IaaS containers and AI services
They avoid storing application passwords while allowing scoped service permissions.
SaaS PaaS IaaS containers and AI services
A compromised deployment identity or artifact can alter production code and inherit application access.
SaaS PaaS IaaS containers and AI services
DDoS protection addresses supported volumetric availability threats; WAF inspects web application traffic for application-layer attacks.
SaaS PaaS IaaS containers and AI services
No. The application still must authenticate callers and authorize each operation and data access.
SaaS PaaS IaaS containers and AI services
A smaller approved software set reduces unnecessary packages and the vulnerabilities that must be maintained.
SaaS PaaS IaaS containers and AI services
Supported registry or running-image software packages for known vulnerabilities.
SaaS PaaS IaaS containers and AI services
No. Image assessment and runtime activity collection are distinct capabilities.
SaaS PaaS IaaS containers and AI services
It increases the permissions available after compromise and can weaken isolation from the host.
SaaS PaaS IaaS containers and AI services
A compromised workload may reach host resources and affect other workloads, extending its blast radius.
SaaS PaaS IaaS containers and AI services
Image copies and registry readers can expose credentials; use an appropriate secret or workload-identity mechanism.
SaaS PaaS IaaS containers and AI services
The supported Defender sensor collects runtime telemetry on cluster nodes.
SaaS PaaS IaaS containers and AI services
It supports verification of artifact provenance and integrity, complementing vulnerability scanning rather than replacing it.
SaaS PaaS IaaS containers and AI services
Fix or rebuild the image, deploy the corrected artifact, and verify the running workload uses it.
SaaS PaaS IaaS containers and AI services
Registry permissions control who can read or replace executable artifacts that production workloads will run.
SaaS PaaS IaaS containers and AI services
Administrative control-plane access to the cluster API; it is separate from workload ingress.
SaaS PaaS IaaS containers and AI services
It limits administrative and workload access to the required cluster resources rather than granting cluster-wide authority.
SaaS PaaS IaaS containers and AI services
No. Use appropriate network policies and enforcement to control permitted pod communication.
SaaS PaaS IaaS containers and AI services
Constrain allowed pod traffic according to selectors and policy rules when enforced by the supported network implementation.
SaaS PaaS IaaS containers and AI services
It supports admission-time configuration enforcement through the Kubernetes admission-control integration.
SaaS PaaS IaaS containers and AI services
Deployment should not automatically grant authority to alter every workload or security control in the cluster.
SaaS PaaS IaaS containers and AI services
It provides scoped service authentication without embedding long-lived cloud credentials in workload configuration.
SaaS PaaS IaaS containers and AI services
Supported process, network, and Kubernetes event telemetry from cluster nodes.
SaaS PaaS IaaS containers and AI services
Compromised workloads can contact malicious destinations or exfiltrate data even when inbound access is constrained.
SaaS PaaS IaaS containers and AI services
They use different collection paths and prerequisites; discovery alone does not establish runtime protection.
SaaS PaaS IaaS containers and AI services
Discover the AI workloads and usage so the required service, data, identity, and dependency boundaries are known.
SaaS PaaS IaaS containers and AI services
Defender CSPM provides supported AI workload discovery, security recommendations, and attack-path analysis.
SaaS PaaS IaaS containers and AI services
It avoids stored API keys while allowing scoped service access through Entra authentication.
SaaS PaaS IaaS containers and AI services
Supporting services such as Storage, Key Vault, and registries, not only the AI endpoint.
SaaS PaaS IaaS containers and AI services
Clients and dependencies must resolve service names to the intended private addresses.
SaaS PaaS IaaS containers and AI services
To limit unauthorized exfiltration while preserving approved model-training and inference dependencies.
SaaS PaaS IaaS containers and AI services
Malicious or harmful prompts, including supported prompt-injection and jailbreak patterns.
SaaS PaaS IaaS containers and AI services
Delivery of harmful model responses, subject to supported filtering and configuration.
SaaS PaaS IaaS containers and AI services
To constrain resource consumption and abusive API usage alongside identity and content controls.
SaaS PaaS IaaS containers and AI services
The model’s proposed action should not automatically authorize sensitive transfers or system changes; an approval workflow limits impact.
Network security and Security Service Edge
Inbound and outbound network flows using rules based on sources, destinations, ports, and protocols.
Network security and Security Service Edge
No. Use a suitable WAF for web attack inspection; NSGs control network flows.
Network security and Security Service Edge
Azure Firewall Premium; validate certificate, routing, and feature requirements.
Network security and Security Service Edge
FQDN filtering identifies the destination host; full URL filtering can also distinguish the path, with supported TLS inspection for HTTPS.
Network security and Security Service Edge
They address different application-layer and volumetric availability threats.
Network security and Security Service Edge
The service name must resolve to the intended private endpoint IP from the calling network.
Network security and Security Service Edge
Lateral workload traffic can carry compromise between segments even when internet ingress is restricted.
Network security and Security Service Edge
The security appliance protects only traffic that actually follows its inspected path; bypass routes defeat the control.
Network security and Security Service Edge
Lower numeric priorities are processed first; the first matching rule ends evaluation for that flow.
Network security and Security Service Edge
Yes. The inspection architecture creates separate TLS connections and requires a trusted inspection certificate configuration.
Network security and Security Service Edge
An identity-centric secure web gateway for SaaS applications and other internet traffic.
Network security and Security Service Edge
Web categories and fully qualified domain names, with supported URL visibility depending on traffic and inspection.
Network security and Security Service Edge
An ordered grouping of filtering policies that can be applied through user-aware Conditional Access.
Network security and Security Service Edge
Unique priority numbers; lower numbers have higher priority.
Network security and Security Service Edge
A lowest-priority catch-all profile for all Internet Access traffic routed through the service, even without a linked Conditional Access policy.
Network security and Security Service Edge
It can use Server Name Indication; encrypted full URL paths require additional supported inspection visibility.
Network security and Security Service Edge
Conditional Access integration can use user, device, location, risk, and compliance context.
Network security and Security Service Edge
The relevant traffic must be acquired and routed through the Global Secure Access service.
Network security and Security Service Edge
Microsoft Entra Suite or a standalone Internet Access license, with the required Entra ID P1/P2 prerequisite for users.
Network security and Security Service Edge
They show actual destinations and enforced policies, helping verify expected acquisition, allowed access, and blocked access.
Network security and Security Service Edge
The Microsoft traffic profile in Global Secure Access.
Network security and Security Service Edge
No. Microsoft-profile traffic is acquired only by the Microsoft traffic profile.
Network security and Security Service Edge
Assign the profile to the relevant users and groups, then verify the client receives its forwarding rules.
Network security and Security Service Edge
Microsoft Entra ID P1 or P2; this differs from the full Internet Access product licensing.
Network security and Security Service Edge
Tenant restrictions v2 policy information so supported services can enforce allowed and blocked tenant access.
Network security and Security Service Edge
In the tenant restrictions v2 policy under cross-tenant access settings, including default and partner-specific settings.
Network security and Security Service Edge
Enable universal tenant restrictions signaling for relevant acquired authentication traffic.
Network security and Security Service Edge
The user connects through Global Secure Access for the specific tenant whose access policy requires the network signal.
Network security and Security Service Edge
The signal is tenant specific; the required tenant’s Global Secure Access service must supply it.
Network security and Security Service Edge
Existing sessions may not be interrupted immediately; evaluation occurs when a new sign-in is required.
Network security and Security Service Edge
Identity-aware access to specified private resources through Global Secure Access without requiring broad legacy VPN network access.
Network security and Security Service Edge
A primary grouping of private FQDNs, IP addresses, or ranges intended to be tunneled through the service.
Network security and Security Service Edge
When a subset of private resources needs separate user assignment, Conditional Access, or time-limited access.
Network security and Security Service Edge
It brokers connections from the cloud service to reachable private backend resources through outbound service connections.
Network security and Security Service Edge
The connector initiates outbound connections and uses the established channels for bidirectional traffic.
Network security and Security Service Edge
At least two, with suitable backend reachability and required service connectivity.
Network security and Security Service Edge
To route applications through the appropriate locations and provide segmentation, load balancing, and high availability.
Network security and Security Service Edge
Assign users or groups to the app and apply appropriate Conditional Access policies.
Network security and Security Service Edge
Connector-side DNS resolution, routing, destination connectivity, and the backend’s own access requirements.
Network security and Security Service Edge
No. It adds identity-aware access controls around resource access; backend authentication and authorization still require design.
Microsoft 365 Intune Purview and Copilot
Adoption of recommended security actions across supported identities, apps, and devices; a higher score reflects more actions taken.
Microsoft 365 Intune Purview and Copilot
No. It is a posture metric, not an audit certification or guarantee against compromise.
Microsoft 365 Intune Purview and Copilot
They expose configuration and practice gaps, provide remediation guidance, and help track improvements.
Microsoft 365 Intune Purview and Copilot
Use asset sensitivity, exposure, likely attack paths, business impact, and remediation feasibility.
Microsoft 365 Intune Purview and Copilot
Some actions are scored in proportion to the users or devices protected rather than only complete or incomplete.
Microsoft 365 Intune Purview and Copilot
Yes. Supported recommendations can be recorded as addressed through a non-Microsoft solution or alternate mitigation.
Microsoft 365 Intune Purview and Copilot
Deployment coverage, exceptions, incident evidence, and validation of the controls behind the score.
Microsoft 365 Intune Purview and Copilot
Relative posture and improvement targets; they do not establish the organization's individual risk tolerance.
Microsoft 365 Intune Purview and Copilot
A recommendation may be visible even when its specific implementation capability requires a different edition or plan.
Microsoft 365 Intune Purview and Copilot
Capabilities including attack simulation training, deeper hunting and investigation, and automated investigation and response.
Microsoft 365 Intune Purview and Copilot
They provide sender authentication and alignment signals that complement phishing and malware protection.
Microsoft 365 Intune Purview and Copilot
Microsoft Defender for Cloud Apps, using supported discovery signals and its cloud application catalog.
Microsoft 365 Intune Purview and Copilot
Security configuration and recommended hardening in supported connected SaaS applications.
Microsoft 365 Intune Purview and Copilot
OAuth-enabled applications with permissions and behavior that can expose or misuse organizational data.
Microsoft 365 Intune Purview and Copilot
Conditional Access App Control with appropriate supported session policies and integration.
Microsoft 365 Intune Purview and Copilot
An application can use granted API permissions independently of an interactive browser session.
Microsoft 365 Intune Purview and Copilot
Visibility and enforcement depend on the application's integration and supported access paths.
Microsoft 365 Intune Purview and Copilot
Managing enrolled device configuration, compliance, applications, and supported device-wide controls.
Microsoft 365 Intune Purview and Copilot
Organizational data within supported managed applications, including scenarios without full device enrollment.
Microsoft 365 Intune Purview and Copilot
An app protection policy with supported data transfer restrictions.
Microsoft 365 Intune Purview and Copilot
Configuration policies apply settings; compliance policies evaluate whether a device meets required conditions.
Microsoft 365 Intune Purview and Copilot
It uses the evaluated compliance signal to make an access decision; compliance evaluation alone is not the access enforcement step.
Microsoft 365 Intune Purview and Copilot
Organizational data from protected apps while preserving personal data within supported scenarios.
Microsoft 365 Intune Purview and Copilot
The app must support the relevant Intune app protection capabilities and platform behavior.
Microsoft 365 Intune Purview and Copilot
It can require an app PIN or biometric access and apply supported conditional launch requirements.
Microsoft 365 Intune Purview and Copilot
No. Its boundary is protected organizational data in participating apps, not all personal content.
Microsoft 365 Intune Purview and Copilot
To require the intended protected access path and help ensure application data protection is enforced.
Microsoft 365 Intune Purview and Copilot
Data security, data governance, and data compliance.
Microsoft 365 Intune Purview and Copilot
An organization's classification and supported handling or protection settings for content.
Microsoft 365 Intune Purview and Copilot
No. Encryption depends on the label's configured protection settings; some labels only classify or mark content.
Microsoft 365 Intune Purview and Copilot
Sensitive information to detect, supported locations, matching conditions, and actions to take.
Microsoft 365 Intune Purview and Copilot
Retention governs preservation and deletion over time; DLP governs inappropriate use or movement of sensitive data.
Microsoft 365 Intune Purview and Copilot
Finding, preserving, reviewing, and producing relevant content for investigations and legal processes.
Microsoft 365 Intune Purview and Copilot
Providing records of supported user and administrator activities for investigations and compliance.
Microsoft 365 Intune Purview and Copilot
No. Container settings and file-level labeling are separate scopes; file protection must be configured as required.
Microsoft 365 Intune Purview and Copilot
To confirm scope, matches, user impact, false positives, and exceptions before blocking business activity.
Microsoft 365 Intune Purview and Copilot
Labels express classification and protection; DLP can use classification and context to restrict risky actions.
Microsoft 365 Intune Purview and Copilot
The permissions of the user initiating the prompt; Copilot does not automatically repair excessive permissions.
Microsoft 365 Intune Purview and Copilot
Identify owners and exposure, reduce inappropriate sharing, and remediate source permissions.
Microsoft 365 Intune Purview and Copilot
Yes. Processing exclusion and ordinary source authorization are separate controls.
Microsoft 365 Intune Purview and Copilot
Yes. The documented label-based control excludes content processing, but the item can still appear in citations.
Microsoft 365 Intune Purview and Copilot
It supports emails sent on or after January 1, 2025.
Microsoft 365 Intune Purview and Copilot
No. The documentation lists calendar invites as unsupported.
Microsoft 365 Intune Purview and Copilot
Preview and rolling out; verify that the feature is available in the target tenant and experience.
Microsoft 365 Intune Purview and Copilot
Sender-domain metadata against the tenant's accepted domains; it does not inspect the email body.
Microsoft 365 Intune Purview and Copilot
External web search is blocked for that prompt, while responses can still use permitted internal Microsoft 365 sources.
Microsoft 365 Intune Purview and Copilot
Supported Audit, eDiscovery, and retention capabilities help investigate and preserve AI interactions.
Application lifecycle workload identities and APIs
Applications, owners, business criticality, data sensitivity, dependencies, exposed endpoints, identities, and deployed versions.
Application lifecycle workload identities and APIs
They can retain exposed endpoints, permissions, secrets, or vulnerable components and increase attack surface.
Application lifecycle workload identities and APIs
By exploitability, exposure, business impact, affected data, and compensating controls rather than counts alone.
Application lifecycle workload identities and APIs
Identification of affected workloads when a library or framework vulnerability is disclosed.
Application lifecycle workload identities and APIs
Code analysis finds implementation risks; runtime assessment finds deployed behavior, exposure, drift, and operational weaknesses.
Application lifecycle workload identities and APIs
Inventory, API posture findings, sensitive-data classification, and threat detection for supported onboarded APIs.
Application lifecycle workload identities and APIs
So remediation, risk acceptance, deadlines, and validation have accountable decision makers.
Application lifecycle workload identities and APIs
An application can retain access to organizational data even when users no longer actively use it.
Application lifecycle workload identities and APIs
The running workload may differ from current source and contain older or unexpected components.
Application lifecycle workload identities and APIs
Retesting the affected attack path and confirming the corrected code or configuration is deployed.
Application lifecycle workload identities and APIs
Identify, evaluate, and mitigate threats to a system early and revisit them as the architecture evolves.
Application lifecycle workload identities and APIs
Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege.
Application lifecycle workload identities and APIs
They reveal where data or identities cross assumptions and where authentication, authorization, validation, and protection are required.
Application lifecycle workload identities and APIs
The affected asset or flow, risk, mitigation, owner, validation, and response if the control fails.
Application lifecycle workload identities and APIs
During planning and design alongside business and functional requirements.
Application lifecycle workload identities and APIs
Revisit it after material architecture, dependency, privilege, or data-flow changes.
Application lifecycle workload identities and APIs
Source code, bytecode, or binaries without executing the application.
Application lifecycle workload identities and APIs
A running application using simulated attack interactions and runtime observations.
Application lifecycle workload identities and APIs
Previously acceptable components can acquire newly disclosed vulnerabilities.
Application lifecycle workload identities and APIs
A defined check that prevents or controls promotion when a security requirement is not met.
Application lifecycle workload identities and APIs
A compromised workstation can tamper with source, credentials, or build access before production deployment.
Application lifecycle workload identities and APIs
Gradual rollout limits the affected population and supports controlled response if a defect appears.
Application lifecycle workload identities and APIs
Feed verified causes and fixes back into requirements, threat models, tests, and secure coding practices.
Application lifecycle workload identities and APIs
Remove unused workloads, endpoints, credentials, permissions, and retained assets according to lifecycle requirements.
Application lifecycle workload identities and APIs
To define repeatable approved practices and reduce avoidable vulnerabilities across development teams.
Application lifecycle workload identities and APIs
Teach the threats and prevention techniques relevant to each developer's work before privileged source access.
Application lifecycle workload identities and APIs
Least privilege, strong identity controls, structured peer review, and accountable approval workflows.
Application lifecycle workload identities and APIs
They execute inside privileged build workflows and can introduce supply-chain compromise.
Application lifecycle workload identities and APIs
Treat it as exposed, revoke or rotate it, remove the unsafe usage, and add preventive controls.
Application lifecycle workload identities and APIs
Deny access unless explicitly authorized.
Application lifecycle workload identities and APIs
To limit lateral movement and prevent lower-trust development or testing from exposing production assets.
Application lifecycle workload identities and APIs
Build agents can access valuable source, credentials, and deployment capabilities.
Application lifecycle workload identities and APIs
They reduce persistence opportunities and the operational burden of maintaining reusable self-hosted agents.
Application lifecycle workload identities and APIs
Copying production data into lower environments can move sensitive information beyond its intended protection boundary.
Application lifecycle workload identities and APIs
Azure Key Vault, with restricted access, audit, network controls, and lifecycle management.
Application lifecycle workload identities and APIs
Managed identities combined with the necessary least-privilege resource authorization.
Application lifecycle workload identities and APIs
Azure API Management policies at the gateway.
Application lifecycle workload identities and APIs
Application or data-layer authorization using trusted identity and resource context.
Application lifecycle workload identities and APIs
Azure WAF on a supported service such as Application Gateway or Front Door.
Application lifecycle workload identities and APIs
Always Encrypted with appropriate client-side keys and supported drivers.
Application lifecycle workload identities and APIs
Transparent Data Encryption; it does not by itself hide query plaintext from an authorized administrator.
Application lifecycle workload identities and APIs
Microsoft Defender for APIs.
Application lifecycle workload identities and APIs
Private endpoints and appropriate public access restrictions, with working DNS; identity authorization is still required.
Application lifecycle workload identities and APIs
Identity, authorization, network restriction, encryption, detection, and recovery address different failure modes.
Application lifecycle workload identities and APIs
A workload identity represents software such as an application, service, script, or container rather than a person.
Application lifecycle workload identities and APIs
The global application definition or template used to create tenant-local service principals.
Application lifecycle workload identities and APIs
The tenant-local representation of an application, defining its access and capabilities in that tenant.
Application lifecycle workload identities and APIs
The need for developers to store and manually manage workload authentication credentials.
Application lifecycle workload identities and APIs
It is tied to one Azure resource and is deleted when that resource is deleted.
Application lifecycle workload identities and APIs
It is an independent Azure resource that can be assigned to multiple resources and must be explicitly managed.
Application lifecycle workload identities and APIs
No. The identity still needs the appropriate permissions on the target resource.
Application lifecycle workload identities and APIs
Stored application secrets or certificates with trusted token exchange from an external identity provider.
Application lifecycle workload identities and APIs
Issuer, subject, and audience must case-sensitively match the configured trust values.
Application lifecycle workload identities and APIs
To reduce the data and resources an attacker can reach if the workload is compromised.
Application lifecycle workload identities and APIs
The API gateway, management plane, and developer portal.
Application lifecycle workload identities and APIs
Accept API requests and consistently apply configured routing, credential checks, quotas, transformations, and observability.
Application lifecycle workload identities and APIs
The expected issuer, audience, validity, signature, and required claims according to the authentication design.
Application lifecycle workload identities and APIs
They identify subscription access rather than proving each user's identity and authorization to individual business objects.
Application lifecycle workload identities and APIs
A caller can access or modify a business object they are not authorized to use, often by changing an identifier.
Application lifecycle workload identities and APIs
A caller can invoke an operation outside their permitted role or capabilities.
Application lifecycle workload identities and APIs
Excessive consumption and some abuse patterns; they do not establish object-level permissions.
Application lifecycle workload identities and APIs
To reject malformed or unexpected input and reduce the accepted attack surface.
Application lifecycle workload identities and APIs
Otherwise callers may bypass gateway authentication, validation, throttling, or monitoring policies.
Application lifecycle workload identities and APIs
Posture findings and supported threat detection for onboarded APIs; it complements preventive policies.
Application lifecycle workload identities and APIs
Supported HTTP threats such as SQL injection and cross-site scripting.
Application lifecycle workload identities and APIs
Monitors and logs matched threats without blocking incoming requests.
Application lifecycle workload identities and APIs
Blocks requests identified as attacks by the enforced rules and records them in WAF logs.
Application lifecycle workload identities and APIs
To observe real traffic, investigate false positives, and tune rules before enforcement.
Application lifecycle workload identities and APIs
Managed rules, custom rules, exclusions, and supported service-specific settings.
Application lifecycle workload identities and APIs
Avoid false positives for a specific request attribute while retaining the rest of the intended inspection.
Application lifecycle workload identities and APIs
Custom rules express application-specific matching and actions; managed rule sets provide maintained predefined protections.
Application lifecycle workload identities and APIs
Azure Front Door with the appropriate WAF tier and capabilities.
Application lifecycle workload identities and APIs
No. The application still must enforce trusted user, tenant, object, and function permissions.
Application lifecycle workload identities and APIs
No. Standard supports custom rules; Premium provides the full integrated WAF capabilities including managed rules.
Data classification encryption databases and storage
Locate data assets and processing paths so the organization knows what needs protection.
Data classification encryption databases and storage
Sensitivity, information type, and obligations guide access, segmentation, encryption, monitoring, retention, and handling.
Data classification encryption databases and storage
Shared categories and definitions so teams classify and handle information consistently.
Data classification encryption databases and storage
Sensitive content can be replicated outside its primary store and still requires appropriate protection.
Data classification encryption databases and storage
Configured patterns and evidence associated with sensitive data, shared across supported Purview solutions.
Data classification encryption databases and storage
Identifying categories of content through machine learning and examples rather than only fixed patterns.
Data classification encryption databases and storage
Metadata about scanned assets and sources for data governance.
Data classification encryption databases and storage
No. Data Map and Unified Catalog roles govern metadata and do not themselves grant underlying data access.
Data classification encryption databases and storage
Determine business meaning, approve appropriate classifications and access, and maintain accountable handling.
Data classification encryption databases and storage
Tools can suggest classifications, but coverage, false positives, missed sensitive data, and business context still need review.
Data classification encryption databases and storage
Data sensitivity, business impact, exposure, likely abuse, affected scope, obligations, and available controls.
Data classification encryption databases and storage
An authorized principal can usually receive plaintext through the service, so permissions and use still need controls.
Data classification encryption databases and storage
Contain the exposure, assess impact, and correct the access boundary before lower-impact posture improvements.
Data classification encryption databases and storage
Exports, caches, backups, and test datasets can expose the same sensitive information through weaker boundaries.
Data classification encryption databases and storage
Reduce unnecessary sensitive information collected, processed, copied, or retained.
Data classification encryption databases and storage
Loss or corruption of critical data can cause severe business harm even without disclosure.
Data classification encryption databases and storage
Affected data and impact, rationale, accountable owner, compensating controls, review date, and validation.
Data classification encryption databases and storage
It helps identify high-value affected data and scope likely business and regulatory consequences.
Data classification encryption databases and storage
Unauthorized disclosure, modification, and loss require different complementary mitigation and validation.
Data classification encryption databases and storage
Evidence that the targeted access, transfer, integrity, or recovery path now meets the requirement.
Data classification encryption databases and storage
Stored data such as service files, disks, or backups; it does not by itself authorize or restrict service-mediated plaintext queries.
Data classification encryption databases and storage
Appropriately configured TLS or another suitable secure transport, including correct endpoint and certificate validation.
Data classification encryption databases and storage
Cryptographic keys, certificates and private keys, and secrets such as passwords or connection strings.
Data classification encryption databases and storage
To limit shared secret access and reduce the blast radius of a compromise.
Data classification encryption databases and storage
The customer has key-control and lifecycle responsibilities, with the service using the configured key-management integration.
Data classification encryption databases and storage
A second encryption layer with a different key and algorithm, separate from service-level encryption.
Data classification encryption databases and storage
At storage account creation; it cannot be enabled or disabled for that account afterward.
Data classification encryption databases and storage
Yes. The documented scope setting is selected when the scope is created and cannot be changed afterward.
Data classification encryption databases and storage
To reduce irreversible loss or malicious destruction of keys that dependent services need.
Data classification encryption databases and storage
Permission misuse, expired or unavailable keys, rotation failures, deletion, audit gaps, and recovery dependencies.
Data classification encryption databases and storage
Only content the authenticated user is authorized to use should reach the model's grounding context.
Data classification encryption databases and storage
A string filter is not authentication; allowing users to assert arbitrary groups can bypass the intended document boundary.
Data classification encryption databases and storage
It allows supported retrieval-time access checks or security filters to exclude unauthorized content.
Data classification encryption databases and storage
No. Prompt attack detection and document authorization address different threats.
Data classification encryption databases and storage
Adversarial user inputs that try to override model instructions or safety behavior.
Data classification encryption databases and storage
Malicious instructions embedded in retrieved documents, emails, or pages that attempt to hijack model behavior.
Data classification encryption databases and storage
No. The calling application decides how to act on detection results; supported Foundry blocking configuration behaves separately.
Data classification encryption databases and storage
A manipulated agent can otherwise perform privileged actions or retrieve more information than its task requires.
Data classification encryption databases and storage
Derived and operational artifacts can retain sensitive information and require appropriate handling.
Data classification encryption databases and storage
Source trust, data quality, provenance, ownership, and lifecycle so unreliable or poisoned content is not treated as trusted.
Data classification encryption databases and storage
Database files and backups at rest; an authorized query can still return plaintext.
Data classification encryption databases and storage
Keeping supported sensitive column plaintext unavailable to the database engine or administrators without client key access.
Data classification encryption databases and storage
Row access through configured security predicates using trusted execution or identity context.
Data classification encryption databases and storage
The sensitive values displayed in query results for applicable users; it does not change stored data or encrypt it.
Data classification encryption databases and storage
Privileged users can see original data and determined querying can undermine limited masking; authorization must remain sound.
Data classification encryption databases and storage
Azure resource roles, Synapse workspace roles, SQL permissions, Git permissions, and relevant storage access.
Data classification encryption databases and storage
A user able to execute code or pipelines may use an identity or credential with broader data access than their own.
Data classification encryption databases and storage
Control-plane roles manage resources; native data-plane roles authorize operations on items and containers.
Data classification encryption databases and storage
Managed identity and appropriately scoped Entra data-plane roles instead of embedded account keys.
Data classification encryption databases and storage
They constrain the network path; callers still need valid authentication and authorization.
Data classification encryption databases and storage
Microsoft Entra authentication with a managed identity and least-privilege data permissions.
Data classification encryption databases and storage
Management permissions and direct data operations are separate authorization needs.
Data classification encryption databases and storage
A bearer credential delegating specified resource access, permissions, and validity within supported Storage services.
Data classification encryption databases and storage
Use the narrowest supported resource and permissions, short expiry, secure transport, and a planned revocation strategy.
Data classification encryption databases and storage
With Microsoft Entra credentials and the SAS permissions; verify target service, API version, and client support.
Data classification encryption databases and storage
A service SAS can use a stored access policy; user delegation and account SAS do not use them.
Data classification encryption databases and storage
The embedded bearer token can grant access to anyone who obtains it while it remains valid.
Data classification encryption databases and storage
No. Each required subresource endpoint and access path must be planned and validated.
Data classification encryption databases and storage
Disallow public Blob access and validate that intended identity and network paths remain functional.
Data classification encryption databases and storage
Immutability restricts supported modification or deletion for retention; soft delete, versions, and backup support recovery and must be selected and tested appropriately.
Data classification encryption databases and storage
Supported data-plane and control-plane activity to detect suspicious storage behavior.
Data classification encryption databases and storage
No. It is an agentless cloud-native protection solution.
Data classification encryption databases and storage
Activity monitoring, sensitive-data threat detection, and malware scanning in supported scenarios.
Data classification encryption databases and storage
On-upload scans supported newly uploaded or modified content; on-demand evaluates selected existing content or stores.
Data classification encryption databases and storage
Content can be accepted before scanning completes, so downstream release must await the intended validated result.
Data classification encryption databases and storage
Scanning halts under the documented cap behavior; subsequent files can remain unscanned until scanning resumes.
Data classification encryption databases and storage
Keep them outside the approved download path until the defined security validation and release policy is satisfied.
Data classification encryption databases and storage
Supported vulnerability assessment and alerts for anomalous or suspicious database activity.
Data classification encryption databases and storage
Azure Cosmos DB for NoSQL; the documented table excludes MongoDB, Cassandra, Table, and Gremlin APIs.
Data classification encryption databases and storage
Detections need accountable triage, investigation, containment, and remediation; enabling detection is not the response itself.
These are original study questions. Multiple-response practice uses exact-set scoring in the app, with no partial credit.
Business resilience and ransomware
✓ Correct answer
Business impact determines criticality. Server replacement cost omits disruption, highly available placement is a control rather than intrinsic business importance, and a runbook does not measure the consequences of service loss.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
The exposed administrative path threatens concentrated enterprise control. Severity alone ignores exposure/impact, unvalidated antivirus coverage does not establish path containment, and replacement cost misses indirect influence over critical services.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Unauthorized modification violates integrity. The service remains available; the scenario concerns changed data rather than viewing alone, and authenticating an identity does not establish that payment instructions remain correct.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
The complete business service depends on identity. A file restore and database redundancy do not restore sign-in, and excluding the failed dependency from measurement hides rather than repairs the recovery gap.
Open this question’s page →Business resilience and ransomware
✓ Correct answers
The production design repository containing irreplaceable intellectual property: Its intrinsic business value makes disclosure or destruction highly damaging. The deployment identity that can replace code in every production application: Its administrative influence creates concentrated risk across high-value assets. Every disposable lab VM at the same priority as production control identities: Uniform priority ignores differences in business impact and influence. Only resources with the highest monthly Azure bill: Cost alone does not identify high-value data or privileged control. Only internet-facing resources, excluding internal administrators: An internal privileged identity can still control critical systems.
Open this question’s page →Business resilience and ransomware
✓ Correct answers
Recovery exercises and enforced privileged-path controls demonstrate service-risk reduction. Job success omits usable restoration, inventory existence omits effective protection, and an aggregate score may hide the relevant critical-service gaps.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
80 minutes: The interval from 09:00 to 10:20 is 80 minutes, exceeding the 30-minute target. 30 minutes: The target does not establish the age of the actual recovery point. 50 minutes: This is the amount by which the interval exceeds the target, not the full potential loss. Zero minutes because a backup exists: Backup existence does not establish zero data loss.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
The measured 135-minute sequence exceeds the RTO: Sequential durations add to 135 minutes, so the required service restoration time is not met. The RTO is met because each step is below 120 minutes: The target applies to complete service restoration, not each separate component. The RPO must be 135 minutes: Data-loss tolerance and restoration duration are different measurements. The target is met if the last step starts before 120 minutes: Business operations must be restored, not merely started on their final recovery step.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Protected point-in-time recovery with validated clean restoration: Earlier recovery states address data corruption that replication propagates. More frequent replication of the same current state: More frequent copying still propagates malicious changes. A lower DNS TTL without historical recovery points: DNS helps traffic failover but does not reconstruct earlier data. A larger secondary VM without recoverable history: Compute capacity does not reverse copied data corruption.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Design and test independent access to the required keys and recovery identities: Recoverability requires usable encryption keys and authorization under the incident conditions. Assume successful backup jobs prove the keys will be available: Backup completion does not prove key access during a tenant outage. Remove encryption from all backups permanently: Removing confidentiality protection is not required to design a secure recovery path. Increase replication frequency without changing key access: Frequency does not resolve the authorization dependency.
Open this question’s page →Business resilience and ransomware
✓ Correct answers
Business transactions and dependency exercises validate usable recovery. Backup jobs do not measure RTO, replica compute omits service dependencies/data trust, and operational decisions are part of the planned recovery process.
Open this question’s page →Business resilience and ransomware
✓ Correct answers
Use supported recovery mechanisms for each platform under common business recovery targets: Platform-specific capability is necessary even when governance is unified. Validate allowed recovery locations and data movement against residency requirements: Cross-region or cross-cloud recovery can change where data is stored or processed. Assume Azure Site Recovery protects every SaaS and cloud database: Support matrices restrict eligible sources, targets, and workloads. Choose the cheapest remote region before checking legal constraints: Cost cannot override mandatory location requirements. Define recovery success solely as infrastructure deployment completion: Business-service restoration and validation must also succeed.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
It assumes compromise and prioritizes reducing business impact quickly: Survivable recovery and limited administrative blast radius reduce the consequences of successful entry. It proves initial-access controls are unnecessary: Entry-point protection remains a required part of the plan. It is an unavoidable technical deployment dependency: The published order is risk prioritization and allows parallel work. It applies only to workloads with no sensitive data: The guidance is relevant to sensitive and business-critical environments.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Proceed in parallel without delaying recovery and privileged-access work: Quick later-stage improvements can be completed while preserving the recommended priority. Stop all endpoint work until every backup task is complete: The guidance allows different teams to work simultaneously. Cancel backup work because phishing controls are available: Preventive improvements do not replace resilience under assumed compromise. Treat the priority list as permission to skip privileged access: Privileged-access protection limits an attacker who gets through entry defenses.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Standing MUA operational authority defeats the intended independent check. Resource Guard can be separately hosted, Reader is not the critical-operation authority, and MFA strengthens authentication without separating the administrator’s permissions.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Recovery protection is valuable, but disclosure and access risks require additional controls: Backups restore data; they do not undo prior theft or prevent unauthorized disclosure. Immutability was necessarily misconfigured because exfiltration occurred: Vault immutability addresses recovery-point destruction, not every production data access. A successful restore removes all confidentiality consequences: Restoration cannot revoke knowledge of data already stolen. Data protection is unnecessary after recovery succeeds: The incident demonstrates why disclosure prevention and detection are still needed.
Open this question’s page →Business resilience and ransomware
✓ Correct answers
Separate ownership and absent standing MUA authority support independence. Permanent Owner can bypass the intended separation, hosting separation is insufficient when effective rights remain, and Resource Guard does not govern arbitrary production-source operations.
Open this question’s page →Business resilience and ransomware
✓ Correct answers
Validate required retention and operating behavior before irreversible locking: Locking cannot be undone, so the supported workload and retention design must be correct. Validate recovered systems in a controlled environment before reconnecting them: Recovery should confirm trusted operation rather than restore into ongoing compromise. Grant production administrators permanent rights to delete recovery data: Shared destructive authority undermines ransomware resilience. Assume the newest recovery point cannot contain attacker persistence: Recent backups can contain malicious changes and require validation. Treat locked immutability as a substitute for all recovery drills: Protected storage does not prove usable data, dependencies, or restoration time.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Update Manager and Arc support the described server environments. SIEM collection and policy assessment alone do not install patches, and Windows client mechanisms do not establish Linux server coverage.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
The current Azure Update Manager has no dependency on those legacy components: It uses native VM or Arc integration and Resource Manager operations. An Automation account is mandatory for every Arc machine: That claim confuses current Update Manager with legacy update-management architecture. A Sentinel workspace substitutes for every server agent requirement: SIEM ingestion does not replace supported machine patching integration. Removing server onboarding requirements is the only alternative: Supported VM or Arc integration still needs to be present.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Halt wider rollout, initiate recovery, and investigate the failed health checks: Progressive exposure limits impact by stopping expansion when the pilot fails. Continue to all production servers to finish the schedule: Continuing expands the known failure blast radius. Disable monitoring so the deployment can complete without alerts: Removing evidence does not make the release healthy. Declare success because the patch installer exited successfully: Installer success does not prove workload health.
Open this question’s page →Business resilience and ransomware
✓ Correct answer
Apply a governed temporary exception, restrict reachable attack paths, and accelerate an approved remediation plan: This balances exploitation risk with service safety while retaining ownership and a deadline. Exclude the server permanently from compliance reporting: Hiding the exception removes visibility without reducing risk. Install the patch blindly despite a known unacceptable failure: Ignoring the verified dependency can create a damaging outage. Assume endpoint monitoring has repaired the vulnerable code: Monitoring can detect attacks but does not remove the underlying weakness.
Open this question’s page →Business resilience and ransomware
✓ Correct answers
Actual installation/reboot and post-update health/security results validate effectiveness. Schedules and available-update assessment do not prove application, and excluding failures conceals gaps.
Open this question’s page →Business resilience and ransomware
✓ Correct answers
Defined approval and a recoverable rollout with targeted health checks: Urgency changes timing but does not remove the need for controlled change and recovery. Monitoring that can halt expansion when failures occur: A rapid release still needs evidence and a way to contain deployment impact. Permanent disabling of all release gates: Removing controls beyond the immediate need creates ongoing risk. One unrestricted patching identity shared by all contractors: Broad shared privileges increase the management-plane attack surface. A commitment never to deploy urgent patches outside the normal cadence: A rigid cadence can leave actively exploited critical workloads exposed.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Microsoft Cybersecurity Reference Architectures: MCRA explicitly maps integrated security capabilities across the hybrid technology estate. Only the Well-Architected Cost Optimization pillar: That pillar evaluates workload cost decisions rather than enterprise cybersecurity integration. Only the CAF migration plan: A migration plan organizes adoption activities but is not the required security capability reference. Only a service-specific security baseline: A baseline provides controls for that service, not the complete cross-estate architecture.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Microsoft Cloud Security Benchmark: MCSB supplies cloud-centric control and baseline guidance. Only an MCRA product capability diagram: The diagram explains relationships but does not replace detailed service control guidance. Only the CAF business strategy phase: Strategy sets organizational direction rather than detailed cloud control baselines. Only a workload performance benchmark: Performance measurements do not define the requested security controls.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Use the assessment as control evidence and separately validate the required implementation and obligations: A control mapping and configuration assessment do not establish complete legal or operational assurance. Accept the claim if every mapped resource is green: Assessment status alone omits unmeasured controls, scope, and operating evidence. Remove all automated assessment because it has no compliance value: Automated assessment can provide useful evidence even though it is not an attestation. Replace the initiative with an MCRA diagram to gain certification: A reference diagram is also guidance and does not certify compliance.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Map the attack path to controls, verify telemetry and enforcement integrations, and assign response ownership: The gap is in effective end-to-end coverage and response, not merely product ownership. Treat product licenses as proof that the path is covered: Ownership does not establish functioning integration or enforcement. Remove identity controls because endpoint software already exists: The attack path spans identity and data, requiring complementary controls. Increase the SIEM retention period as the sole remedy: Retention helps later investigation but does not by itself add missing containment or authorization.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answers
Define an enterprise target state for cybersecurity capabilities: MCRA provides a starting architecture to adapt to the organization. Compare existing capabilities and integrations with recommended coverage: The reference helps identify missing capabilities and integration gaps. Treat every depicted technology as a mandatory purchase: A reference is adapted to requirements and existing investments. Use it as a substitute for service-specific implementation guidance: Detailed configurations and support requirements still need service documentation. Use it as automatic proof of a legal compliance certification: Architecture guidance does not establish formal attestation.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answers
Check current preview status and actual service support for the chosen controls: Benchmark recommendations and platform implementation availability are distinct. Test required security outcomes and keep implementation evidence with responsible owners: Control alignment must be demonstrated in the deployed workload. Assume every recommendation has a generally available automated policy: Some controls require application logic, processes, or preview features. Treat policy assignment as proof that agent tools cannot be abused: Agent authorization and runtime behavior require specific enforcement and validation. Omit operational and human controls because the benchmark has cloud guidance: Cloud guidance does not remove organizational responsibilities.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Insider Risk Management correlates the relevant insider activity with privacy-oriented investigation. DLP alone does not provide the full requested workflow, external inventory misses internal handling, and sign-in risk does not by itself assess employee document behavior.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Combine least-privilege review, data-loss controls, and a governed investigation: Legitimate credentials do not make every data-handling action permitted or safe. Allow the activity automatically because authentication succeeded: Authentication establishes identity, not approval for every data action. Investigate only the external firewall configuration: Perimeter configuration alone misses activity using permitted internal access. Treat backup availability as prevention of disclosure: Recoverability does not prevent exfiltration or its confidentiality consequences.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Separate trust/execution and scoped release authority restrict attacker-controlled builds. Encryption is insufficient when untrusted jobs can decrypt, retained logs do not remove deployment privilege, and familiar hosting does not establish trustworthy contributions.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Signature verification alone is insufficient; protect the signing and release process and evaluate the artifact: A compromised trusted signing system can produce a valid signature on malicious content. A valid signature proves every dependency is vulnerability-free: Signatures do not establish complete code safety. The package must be safe because its file was not modified after signing: Post-signing integrity does not prove the original signed content was benign. All artifact verification should be abandoned permanently: Verification remains useful within a protected provenance and release process.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answers
Use privacy-preserving access controls and audited investigator permissions: This supports authorized investigation while reducing unnecessary exposure of personal data. Correlate activity and context before deciding an appropriate response: Risk indicators can arise from inadvertent or legitimate behavior as well as malicious actions. Publish all flagged employees to every administrator: Broad disclosure conflicts with privacy-oriented investigation controls. Treat a single risk alert as conclusive proof of deliberate theft: An alert is a signal for assessment, not a final judgment. Disable all logging of investigator activity: Auditing helps govern access and accountability.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answers
Limit deployment identity permissions and permitted release contexts: Restricted authority reduces the resources and workflows an attacker can control. Require verified artifacts and a protected approval path before production release: The release boundary reduces unchecked movement from build inputs to production. Give build jobs production Owner rights to avoid deployment failures: This expands rather than reduces the potential compromise impact. Store the deployment credential in the repository history: Repository disclosure can expose production credentials. Rely only on perimeter filtering around the production web endpoint: Attackers with deployment authority can change the application behind that perimeter.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
AI-1 use of approved models: The gap is model verification, trusted provenance, and deployment approval. Only AI-5 human approval of business actions: Action approval does not establish that the deployed model itself was reviewed. Only AI-6 runtime monitoring: Monitoring is complementary but does not replace model approval before deployment. Only ordinary backup retention: Backup history does not verify model origin or approval.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Validate external content and outputs as well as prompts while retaining independent authorization: Multiple entry and output paths need safeguards; filtering still does not replace permissions. Trust partner webpages automatically because they are not typed by users: External content can carry indirect prompt injection. Remove output checks because prompt filtering has already run: A filtered input does not guarantee safe output. Give the model more data permissions to reduce false positives: Increasing privileges expands exposure rather than adding content controls.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Independent tool and identity permissions enforce read-only scope. System instructions, logging, and output filtering do not remove the granted destructive API authority.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Collect sufficient investigation evidence with restricted access, appropriate minimization, and retention: Monitoring must be useful without creating an uncontrolled secondary sensitive-data store. Grant all developers unrestricted access to every raw interaction: Broad access increases confidentiality and privacy exposure. Disable all AI monitoring to avoid retaining any information: Eliminating monitoring removes needed detection and investigation capability. Assume logs are harmless because they are not the primary database: Copies of sensitive prompts remain sensitive information.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answers
Constrain the agent identity and tool to specifically permitted subscription operations: Least privilege limits what the agent can do independently of its generated instructions. Enforce human approval before designated consequential changes are executed: Approval must guard the action, not merely document it afterward. Allow all operations but add a disclaimer after each change: A disclaimer does not constrain or approve the action. Replace permissions with a safety system prompt alone: Meta-prompts are not an authorization boundary. Log human review only after irreversible changes finish: Post-action review cannot provide the required pre-action checkpoint.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answers
Repeat adversarial tests covering the new content and tool paths: New inputs and capabilities change the attack surface and can invalidate old findings. Revalidate tool permissions, data boundaries, monitoring, and approval requirements: Safety depends on enforcement and visibility across the changed application. Reuse the original evaluation without considering the new connector: The original assessment did not cover the changed input path. Assume a trusted model makes every integration safe: Integration permissions and content introduce independent risks. Remove the old restrictive controls to simplify the new tool: Simplification must not silently broaden authorization.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Verify explicitly directly addresses the missing identity/context checks. Network-only trust is insufficient, limited permissions do not authenticate the caller, and assumption of compromise does not justify omitting authentication.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Limit eligible roles, scope, activation duration, and approval to the actual administrative need: This reduces standing and excessive authority while supporting required work. Keep permanent broad roles and add a policy reminder: A reminder does not constrain authority. Assign a separate broad role to every developer: Different names do not reduce the effective privilege. Require only a corporate network connection: Network context alone does not correct excess permissions.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Secure leadership sponsorship, define outcomes, assess maturity, and assign a phased roadmap: Adoption requires organizational alignment and measurable implementation. Declare the program complete because the products are licensed: Purchasing capabilities does not establish working controls. Add more dashboards before agreeing who acts on them: Visibility without ownership does not resolve the adoption gap. Use the vendor product list as the entire business strategy: A technology inventory omits outcomes, responsibilities, and change management.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answer
Supported client/resource and session behavior must be tested. Disablement is not universal instant revocation, future sign-in frequency alone does not establish termination of an existing session, and role eligibility removal does not prove all active tokens are revoked.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answers
Denied-access tests and verified attack-path/response outcomes demonstrate behavior. Enabled state can be mis-scoped, one administrator journey does not cover every identity/client, and aggregate scores may conceal critical gaps.
Open this question’s page →MCRA MCSB and Zero Trust
✓ Correct answers
Independent protection of recovery data and recovery authority: The organization should retain a recovery path despite production compromise. Segmentation and constrained administrative access between critical systems: These controls restrict lateral movement and the impact of existing compromise. Automatic trust for all traffic originating inside the LAN: Internal origin does not establish safe or authorized access. One shared unrestricted administrator for every service: Shared broad authority increases the compromise blast radius. Removal of investigation telemetry to reduce complexity: Reduced visibility undermines detection and containment.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Define use cases, data boundaries, business impact, and accountable owners: These requirements determine a suitable approved platform and controls. Select the largest model before documenting data access: Model capacity does not establish the business and security requirements. Grant the assistant tenant-wide data access for its pilot: Broad access increases exposure before boundaries are validated. Treat vendor model approval as approval for every organizational use: A provider decision does not evaluate the organization-specific data and impact.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Reassess the new autonomy and enforce scoped tool authorization with independent approval for sensitive changes: The new ability changes business state and needs controls outside generated instructions. Retain all original controls because the model is unchanged: Risk changes when tool capability and impact change even with the same model. Allow database administrator access to avoid tool failures: Administrative rights exceed the approved transaction scope. Replace action audit logs with a more detailed system prompt: Instructions do not provide accountability or enforce authorization.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Network isolation is present, but data permissions must be reduced to the approved workload scope: Private endpoints do not narrow the identity authorization boundary. Private endpoints make the broad identity assignment harmless: An authorized private connection can still access excessive data. Remove identity authentication and embed a shared key in prompts: This weakens credential handling and access governance. Use only content filtering to authorize individual database rows: Content classification does not replace database authorization.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Evaluate inclusiveness, fairness, reliability, and the use-case impact with accountable human review: Responsible AI includes these outcomes alongside privacy and security. Declare the system responsible because its firewall rules passed: Network controls do not evaluate the described decision quality. Restrict evaluation to whether prompts contain credentials: Credential detection does not assess inclusion or fairness. Measure only inference throughput before approving rollout: Performance alone cannot assess responsible AI behavior.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Use identity-based authentication instead of keys where supported: This reduces reliance on stored shared credentials. Give each agent only the downstream permissions required for its approved tools: Least privilege constrains the agent access boundary. Place a shared privileged key in the system prompt: Prompts are not a protected credential store. Let every agent inherit the platform owner role: Owner rights create excessive authority unrelated to task needs. Treat model-provider trust as data-access permission: Model approval does not grant an agent authorization to data.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Validate that retrieval enforces approved data-access boundaries: Retrieval must respect authorized scope. Test prompt-injection defenses against user input and external content: Both can carry adversarial instructions. Evaluate model provenance and the provider against organizational requirements: Model approval should account for provider and intended use. Assume a pilot model requires no review after adding production write tools: New autonomy changes risk and needs reassessment. Use a successful deployment as the sole evidence of responsible AI: Resource creation does not validate safety, privacy, fairness, or accountability.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
CAF addresses organizational adoption and platform operations. A single workload review, service baseline, and capability diagram are useful inputs but do not supply the whole adoption roadmap.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Azure Well-Architected Framework: Its five pillars assess workload quality and tradeoffs. Only CAF Strategy business motivation: That phase establishes enterprise direction rather than the detailed workload review. Only MCRA enterprise capability mapping: MCRA supports integrated cybersecurity architecture but does not replace the five-pillar workload assessment. Only an Azure Policy compliance export: Configuration evidence supports assessment but omits several workload quality dimensions.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Owned onboarding and verification close the control gap. A written standard, unowned central collection, and undefined delegation leave responsibility or operation unvalidated.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Evaluate the security and reliability tradeoff and design an approved approach that meets the stated requirements: Well-Architected requires consideration of interacting quality pillars. Ignore reliability because only Security is a Well-Architected pillar: Reliability is also a pillar and the business requirement remains relevant. Disable all authorization permanently to meet availability: This discards the security requirement rather than resolving the tradeoff. Assume a CAF landing zone automatically settles application failure behavior: The workload still needs an explicit design and assessment.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Govern controls the Azure environment, Secure protects it, and Manage operates and optimizes it. Plan prepares the organization for adoption and Ready designs the landing-zone foundation; these are real CAF phases, but not the three phases most directly addressing ongoing control and operation.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Check whether the enterprise foundation and operating responsibilities support workload teams: CAF addresses organizational standards and the platform foundation. Assess workload security choices against the other four quality pillars: Well-Architected evaluates workload quality and tradeoffs. Conclude that deploying a landing zone proves every application is secure: Workload-specific security still needs implementation and validation. Rank designs solely by the number of purchased security products: Product count is not evidence of required security outcomes. Remove workload owners from reviews because all security is centralized: Central guardrails and workload responsibilities must work together.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
An Azure Policy deny assignment for the allowed-location requirement: Policy can enforce the applicable resource configuration boundary. A Reader role assignment for the deployment identity: Reader limits actions but does not define which regions are allowed for authorized deployers. A billing tag documenting the preferred region: A tag alone does not prevent a deployment. A policy audit assignment with no enforcement change: Audit reports violations without blocking the matching request.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Existing-resource remediation requires a task and authorized assignment identity. The creator’s role does not replace the remediation identity, Deny does not deploy missing settings retroactively, and Audit reports without deployment.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Approve a scoped, documented exemption with compensating controls, ownership, and an expiry or review date: This preserves the baseline while governing the particular risk. Remove the baseline assignment from the whole management group: This weakens control for unrelated workloads. Move the application outside monitoring without recording why: That hides risk and creates an accountability gap. Give the application Owner on every subscription: More access does not address the configuration requirement.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Configuration compliance does not grant database authorization; assign the required supported data-access permissions: Policy and access authorization serve different purposes. Policy compliance should automatically grant all data-plane rights: It does not establish a principal entitlement to query data. Disable database authentication because Policy is already green: This removes a necessary control. Apply an extra audit policy to grant SQL query rights: Audit assesses configuration rather than granting query permissions.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Group related requirements in policy initiatives and assign at suitable hierarchy scopes: This supports consistent control application and assessment. Stage enforcement changes and validate their impact on representative workloads: This reduces unintended deployment or operational failures. Use tags as a replacement for all authorization decisions: Tags do not provide the required principal access boundary. Treat noncompliance reports as proof that deny enforcement already runs: Reporting and enforcement effects differ. Give exemptions indefinite scope without an accountable owner: Exceptions require governance and review.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
A named owner and remediation process: Accountability turns findings into work. Repeatable implementation through governed deployment patterns: Consistent deployment reduces configuration drift. Evidence that the expected control outcome actually occurs: Testing and monitoring validate implementation. A diagram with no implementation or operating responsibility: A diagram alone does not operate the control. A high posture score used to waive all workload threat assessments: A score is a useful signal rather than complete workload assurance.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
A platform landing zone with governed workload landing zones: This combines shared foundation controls with workload ownership. One unrestricted subscription where all teams are Owners: This removes the requested ownership and authority boundaries. Independent subscriptions with no common governance structure: That lacks the required consistent guardrails. Only separate billing tags for production resources: Tags do not establish platform services or access boundaries.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Changing the resource group does not remove applicable inherited policy assignments: The subscription and applicable descendant resources remain under the hierarchy scope. A new resource group automatically cancels management-group policy: Inheritance is not cancelled by that resource organization change. Resource-group creation grants tenant-wide policy administrator authority: It does not grant that access. All policies apply only to the management-group object itself: Applicable assignments govern descendant subscriptions and resources.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Vending makes creation and baseline onboarding repeatable and verifiable. Naming does not configure controls, undefined delegation retains inconsistency, and one accelerator run does not ensure future subscription compliance.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Validate the platform and add the workload-specific model, data, identity, and tool controls: The foundation supports the workload but does not prove its individual security outcomes. Accept the claim because deployment success proves authorization works: Resource deployment does not validate agent and data access. Move the agent outside the landing-zone hierarchy to avoid AI governance: New technology still needs common guardrails and additional applicable controls. Give the agent platform-wide Owner so it can handle any workload dependency: This violates scope and least privilege.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Hierarchy/guardrails and justified shared services belong to the foundation. Application authorization and workload operations still need workload owners; the platform does not justify unrestricted shared access.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Place subscriptions in a suitable hierarchy to inherit common requirements: Inheritance supports consistent governance. Provide repeatable workload subscription requests and distribution: Subscription vending scales onboarding. Scope workload-team authority to its approved resources: Scoped access separates workload and shared-platform control. Allow workload administrators to remove central guardrails without review: This defeats the governance foundation. Assume network peering automatically routes every path through a central firewall: Inspection needs an explicit routing and path design.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Embed threat modeling and security requirements early, then validate through build, release, and runtime: This integrates security throughout delivery rather than only at the end. Move all security decisions to the final production approval meeting: That retains the late discovery problem. Treat successful compilation as proof of safe authorization: Compilation does not validate application access boundaries. Remove developers from remediation ownership: DevSecOps requires development engagement and accountable fixes.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Separate scoped deployment identities with supported federation and restrictions on the authorized workflow or environment: This removes shared standing secrets and constrains authority. Store the same Owner secret in an encrypted repository file that all test jobs can decrypt: Shared access still lets test jobs obtain production authority. Give all build agents tenant-wide administrator rights: This increases privilege rather than reducing it. Keep the shared secret and rely only on application SAST: Code scanning does not constrain deployment credentials.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
SCA focuses on components and known dependency vulnerabilities. First-party static analysis, runtime behavior testing, and IaC scanning evaluate different surfaces and do not replace dependency inventory/security analysis.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answer
Owned mitigation, a scoped exception, and a tested fix balance exploitation and service risk. Permanent gate removal creates recurring exposure, signatures do not remove code flaws, and an indefinite unowned block lacks a managed remediation process.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Protected branches with peer review and governed workflow changes: These reduce unauthorized source and release modifications. Least-privilege deployment access separated by environment: This limits the effect of compromised automation. Security findings with accountable remediation and risk-based release gates: These make checks actionable. Production secrets available to every pull-request test job: This exposes production authority to less-trusted execution. An assumption that runtime monitoring is unnecessary after a clean scan: Pre-release scanning cannot establish future runtime safety.
Open this question’s page →CAF Well Architected and secure adoption
✓ Correct answers
Rotation/revocation invalidates exposed authority and safe storage prevents recurrence. Deleting one line leaves history/copies, private repository exposure is still credential compromise risk, and waiting for every clone delays invalidation.
Open this question’s page →Security operations detection and response
✓ Correct answer
Sentinel expands data scope to third-party sources. Log ingestion does not replace endpoint sensors, correlation does not grant or restrict application rights, and no detector guarantees complete threat visibility.
Open this question’s page →Security operations detection and response
✓ Correct answer
Overlapping creation paths can produce two incidents for correlated alerts. Shorter raw-event retention affects evidence availability, ownership automation changes handling rather than creating the duplicate correlation path, and raw-table selection is distinct from incident duplication.
Open this question’s page →Security operations detection and response
✓ Correct answer
Tags or suitable stable properties avoid dependence on correlation-generated titles. Manual renaming is fragile, duplicate creation reintroduces noise, and an empty owner does not identify the intended attack class.
Open this question’s page →Security operations detection and response
✓ Correct answer
Verify supported raw-table ingestion first: TVM tables can appear in the Sentinel schema without ingested data. Incident synchronization does not copy every advanced-hunting table, selecting a schema table does not enable collection, and longer retention cannot create unsupported or uncollected data.
Open this question’s page →Security operations detection and response
✓ Correct answers
Arriving context and synchronized status/owner validate the integration. Raw-table coverage is separate, deleting source incidents damages investigation, and Global Administrator is excessive and does not verify synchronization.
Open this question’s page →Security operations detection and response
✓ Correct answers
The tenant-based connector supplies synchronized cloud alert/entity details, and removing legacy overlap prevents duplicates. A title omits evidence, broad Owner permissions are unnecessary, and empty details indicate an integration gap rather than absence of alerts.
Open this question’s page →Security operations detection and response
✓ Correct answer
Purview Audit records supported user operations. Policy evaluates resource configurations, PIM controls privileged activation, and route tables direct network traffic rather than preserving these audit operations.
Open this question’s page →Security operations detection and response
✓ Correct answer
Standard defaults to 180 days. It is not indefinite; content labels and administrator roles do not establish audit retention duration or retroactively extend committed records.
Open this question’s page →Security operations detection and response
✓ Correct answer
Ten-year audit retention needs the add-on and matching policy. Standard is insufficient, document retention governs content rather than audit records, and Premium alone does not grant the ten-year entitlement.
Open this question’s page →Security operations detection and response
✓ Correct answer
Non-user records have fixed one-year retention under the documented exception. A sponsor’s user license does not transfer that user retention entitlement, custom policies do not apply to these records, and Premium does not make every record ten-year.
Open this question’s page →Security operations detection and response
✓ Correct answers
Premium adds custom retention and intelligent insights. Licensing and scope still matter, auditing observes activity rather than replacing authorization, and product use does not certify legal compliance.
Open this question’s page →Security operations detection and response
✓ Correct answers
Validate event availability/licensing and supported collection into a retained destination. Expired records cannot be recovered by a new policy, incident summaries omit audit detail, and broad search access exposes sensitive evidence.
Open this question’s page →Security operations detection and response
✓ Correct answer
Azure Monitor Agent collects guest telemetry. Access packages govern access, retention labels govern content, and assigning a role alone installs no telemetry collector.
Open this question’s page →Security operations detection and response
✓ Correct answer
IAM policy changes belong to the AWS control plane. Repeating guest collection or enlarging its buffer does not collect CloudTrail; PIM for the VM owner does not ingest AWS audit events.
Open this question’s page →Security operations detection and response
✓ Correct answer
Application Insights instrumentation captures request traces. Host metrics lack request-level context, provider audits describe control-plane activity, and Arc management alone does not instrument application requests.
Open this question’s page →Security operations detection and response
✓ Correct answer
Different source types need appropriate paths. Arc guest monitoring does not automatically collect all cloud API audits, a REST source requires an integration, and Update Manager performs patch assessment and installation.
Open this question’s page →Security operations detection and response
✓ Correct answers
Agent/rules collect guest telemetry and connectors ingest provider audit data. Windows events alone do not collect CloudTrail, IAM audits do not instrument request execution, and collection rules do not install updates.
Open this question’s page →Security operations detection and response
✓ Correct answers
The ingestion API handles custom log integration and cluster-specific monitoring handles Kubernetes telemetry. VM metrics omit cluster and business context, access reviews assess entitlement justification, and duplicating CloudTrail does not create cluster metrics.
Open this question’s page →Security operations detection and response
✓ Correct answer
Automation rules perform basic incident handling. Storage retention preserves data, routes direct traffic, and authentication strength controls sign-in methods rather than assigning incidents.
Open this question’s page →Security operations detection and response
✓ Correct answer
A playbook can call ITSM and enrichment APIs. A workbook visualizes, a scheduled detection query does not itself execute those API workflows, and tagging alone cannot perform the required integration.
Open this question’s page →Security operations detection and response
✓ Correct answer
The connector identity needs authorization for endpoint action. Incident-view permission does not necessarily grant workflow execution rights, query thresholds concern detection, and tags do not authorize connector API calls.
Open this question’s page →Security operations detection and response
✓ Correct answer
Conditions and an execution marker prevent recursive reprocessing. Increasing severity does not stop the loop, deleting history removes evidence, and more permissions do not fix trigger logic.
Open this question’s page →Security operations detection and response
✓ Correct answers
Least privilege and approval/failure handling constrain impact. Broad analyst rights, absent failure evidence, and indiscriminate triggering increase risk rather than ensure safe response.
Open this question’s page →Security operations detection and response
✓ Correct answers
Alert-triggered rules support enrichment while incident criteria/approval govern impact. Workbooks are not unrestricted response engines, uniform destruction ignores context, and silent failure is not a containment strategy.
Open this question’s page →Security operations detection and response
✓ Correct answer
Hunting tests hypotheses for undetected threats. Alert waiting is reactive, temporary roles concern access, and archiving alone provides no analysis.
Open this question’s page →Security operations detection and response
✓ Correct answer
Rarity warrants contextual investigation. Universal isolation is disproportionate, rarity is not proof, and omitting evidence prevents reasoned validation.
Open this question’s page →Security operations detection and response
✓ Correct answer
The experiences have different bookmark support. Global Administrator is not the explanation, disappearance from that interface does not prove deletion, and incident count is unrelated.
Open this question’s page →Security operations detection and response
✓ Correct answer
A tested analytics rule operationalizes repeatable behavior. Repeated manual hunts leave the detection gap, alerting indiscriminately increases noise, and an indicator alone may miss behavior that does not depend on a stable IOC.
Open this question’s page →Security operations detection and response
✓ Correct answers
Hunts can create incidents and rules. They do not certify legal compliance, replace endpoint sensors, or justify stopping the evidence collection they need.
Open this question’s page →Security operations detection and response
✓ Correct answers
Missing telemetry weakens the test and calls for restored collection/reassessment. An empty result under a data gap disproves neither the threat nor proves complete coverage; benign classification needs evidence.
Open this question’s page →Security operations detection and response
✓ Correct answer
ATT&CK mappings help evaluate behavior coverage. They neither certify compliance nor assign permissions, and mapped rules still require source evidence.
Open this question’s page →Security operations detection and response
✓ Correct answer
Effective coverage depends on working data and logic. Color or additional tags cannot replace telemetry, and adversary behavior remains relevant during an outage.
Open this question’s page →Security operations detection and response
✓ Correct answer
The solution includes OT analytics, workbooks, playbooks, and ICS mappings. Enterprise endpoint rules alone miss OT context, access packages govern access, and blanket benign classification destroys detection value.
Open this question’s page →Security operations detection and response
✓ Correct answer
A mapped rule is not proof of effective detection or coverage of other environments. Recounting and names add no behavioral evidence; ignoring difficult dependencies preserves blind spots.
Open this question’s page →Security operations detection and response
✓ Correct answers
Data and behavioral testing validate capability. Templates may be inactive, tags do not prevent attacks, and deleting useful unmapped rules merely manipulates presentation.
Open this question’s page →Security operations detection and response
✓ Correct answers
Environment-specific matrices/data and OT coordination make evaluation relevant and safe. Desktop results do not prove other coverage, alert count ignores quality, and indiscriminate shutdown can harm physical operations.
Open this question’s page →Identity authentication and access
✓ Correct answer
The app-only token subject is the agent identity. A report viewer is not represented, ordinary-user scope does not cover it, and a subnet is not its identity subject.
Open this question’s page →Identity authentication and access
✓ Correct answer
The identity and linked account are separate subjects needing their own scope. Blueprint policies cover identities, ordinary Users policies exclude agent users, and sponsor targeting does not protect the agent’s own tokens.
Open this question’s page →Identity authentication and access
✓ Correct answer
API-key access bypasses Entra evaluation. Keys do not become user tokens, group targeting does not change the authentication path, and the API still needs its own credential and authorization controls.
Open this question’s page →Identity authentication and access
✓ Correct answer
Blueprint scope includes future agent identities but not linked agent user accounts. Password sharing weakens security, and removing audience validation would admit inappropriate tokens rather than correct policy scope.
Open this question’s page →Identity authentication and access
✓ Correct answers
Delegated tokens represent the user/caller and must fit the audience. Tokens are not universally reusable, linked subjects do not inherit each other’s policies, and autonomous app-only flows have no human to complete interactive MFA.
Open this question’s page →Identity authentication and access
✓ Correct answers
OBO evaluates the represented user and linked-account access evaluates Agent Users. Blueprint-only coverage misses these subjects, current group scoping is unsupported, and keys bypass Conditional Access.
Open this question’s page →Identity authentication and access
✓ Correct answer
The application role/permission model governs record editing. First-factor authentication and MFA establish authentication assurance; tenant integration alone does not authorize every user action.
Open this question’s page →Identity authentication and access
✓ Correct answer
Data authorization must limit which workloads can read the data. Private reachability, transport encryption, and a compliant-device sign-in each protect a different boundary and do not independently reduce the granted data permissions.
Open this question’s page →Identity authentication and access
✓ Correct answer
Federation can remove reusable credentials while resource permissions constrain access. Password sharing and broad roles increase risk; network location is not sufficient identity proof.
Open this question’s page →Identity authentication and access
✓ Correct answer
Federated authentication does not prove narrow native permissions. Redirect success establishes the sign-in path, region concerns placement, and mailbox retention does not govern the third-party role.
Open this question’s page →Identity authentication and access
✓ Correct answers
Network reachability and data authorization protect different boundaries. Shared accounts weaken accountability, IP-only trust omits identity, and display-name conventions do not enforce access.
Open this question’s page →Identity authentication and access
✓ Correct answers
The application lifecycle and both mediated/direct paths must be tested. Gateway sign-in does not necessarily delete local accounts, encryption does not reduce rights, and disabling logs weakens accountability.
Open this question’s page →Identity authentication and access
✓ Correct answer
PHS enables cloud validation. PTA, federation, and an AD FS proxy all retain a live dependency on their on-premises sign-in infrastructure.
Open this question’s page →Identity authentication and access
✓ Correct answer
PTA depends on available agents. It does not imply clear-text cloud storage, grant Azure Owner, or remove application authorization requirements.
Open this question’s page →Identity authentication and access
✓ Correct answer
PHS can reduce dependency and complexity where it meets requirements. More rules can add complexity, removing synchronization does not remove authentication risk, and broad admin rights are excessive.
Open this question’s page →Identity authentication and access
✓ Correct answer
Recovery requires planned and tested operation. Enabling PHS is not proof of universal automatic fallback; federation keys remain critical and synchronized hybrid identities remain security-sensitive.
Open this question’s page →Identity authentication and access
✓ Correct answers
Authentication dependencies and tested recovery matter. The choice does not assign application permissions, synchronization servers influence trust, and a diagram alone does not validate recovery.
Open this question’s page →Identity authentication and access
✓ Correct answers
Cloud password validation can use PHS while synchronization remains critical. PHS does not remove source-directory responsibilities; PTA retains live dependency, and compromised source identities can still affect hybrid security.
Open this question’s page →Identity authentication and access
✓ Correct answer
Inbound settings govern external entry. Outbound settings govern your users going elsewhere; locks and storage lifecycle rules do not establish partner identity access policy.
Open this question’s page →Identity authentication and access
✓ Correct answer
Application assignments and resource authorization are separate from trusting the partner’s MFA. Repeating MFA cannot create rights, another partner’s inbound settings do not apply, and your employees’ outbound settings govern a different direction.
Open this question’s page →Identity authentication and access
✓ Correct answer
Outbound controls apply to your organizational identities accessing external organizations. Inbound is the reverse direction; locks and content retention do not govern that identity path.
Open this question’s page →Identity authentication and access
✓ Correct answer
The verifier validates evidence and the application decides authorization. Displayed claims are not unrestricted roles, password sharing defeats the credential model, and removing resource checks overgrants access.
Open this question’s page →Identity authentication and access
✓ Correct answers
Inbound claim trust affects authentication assurance while assignments govern rights. Outbound is the wrong direction, lifecycle governance remains necessary, and verified claims are not automatic directory roles.
Open this question’s page →Identity authentication and access
✓ Correct answers
Credential validation establishes evidence; access-package policy governs rights/lifecycle. A credential does not justify broad permanent roles or prevent all misuse, and a valid external account does not imply ongoing project authorization.
Open this question’s page →Identity authentication and access
✓ Correct answer
Sign-in risk estimates request compromise. User risk evaluates the account more broadly, compliance evaluates the device’s configuration, and authentication strength describes allowed methods rather than an estimated compromise probability.
Open this question’s page →Identity authentication and access
✓ Correct answer
Authentication strength restricts allowed methods. Ordinary MFA need not meet phishing resistance; the policy does not inherently remove an app role or change token audience.
Open this question’s page →Identity authentication and access
✓ Correct answer
CAE is bounded by compatible clients/resources; unsupported apps need their session behavior assessed. It is not universal instant revocation, disablement does not delete data, and tags do not revoke tokens.
Open this question’s page →Identity authentication and access
✓ Correct answer
Protected actions impose checks on supported sensitive operations. PIM eligibility controls activation rather than every action, longer token life weakens rechecking, and mailbox retention does not guard directory operations.
Open this question’s page →Identity authentication and access
✓ Correct answers
The risk scopes differ and licensing matters. Risk does not grant authorization, MFA does not disinfect devices, and remediation support varies—for example current adaptive user-risk remediation excludes guests.
Open this question’s page →Identity authentication and access
✓ Correct answers
Activation and action-time checks differ; CAE depends on support. PIM does not satisfy every action requirement, CAE does not reduce assigned rights, and Conditional Access has no priority rule that overrides an applicable block.
Open this question’s page →Identity authentication and access
✓ Correct answer
Report-only observes without enforcement. It does not block matching requests, grant temporary exceptions, or partially enforce grant controls while observing session controls.
Open this question’s page →Identity authentication and access
✓ Correct answer
Identity/device assurance cannot be inferred from location alone. A larger trusted range does not add verification, indefinite MFA bypass weakens assurance, and VPN transport does not prove endpoint integrity.
Open this question’s page →Identity authentication and access
✓ Correct answer
Actual journeys and logs validate practical behavior beyond a simulated check. Immediate untested rollout risks disruption, removing recovery can cause lockout, and deleting evidence weakens validation.
Open this question’s page →Identity authentication and access
✓ Correct answer
Scopes differ, particularly agent user exclusions from ordinary Users policies. Sponsors do not represent all agent requests, current group targeting is unsupported, and keys bypass Entra evaluation.
Open this question’s page →Identity authentication and access
✓ Correct answers
Observed allowed/denied behavior and owned exclusions support validation. Simulation alone can miss operational paths, one administrator journey does not prove guest/client coverage, and enabled state does not establish correct scope or outcomes.
Open this question’s page →Identity authentication and access
✓ Correct answers
Allowed methods and recovery validate readiness. SMS is not phishing-resistant, blanket permanent exclusion removes the protection, and device compliance does not substitute for authentication strength.
Open this question’s page →Identity authentication and access
✓ Correct answer
Defender for Identity evaluates relevant AD misconfigurations. Endpoint signatures detect malware, PIM controls privileged activation, and Azure resource-property checks alone do not evaluate the directory’s identity configuration.
Open this question’s page →Identity authentication and access
✓ Correct answer
LDAP signing protects the stated unsigned traffic boundary. Backup encryption, cloud MFA, and service-password rotation can be useful controls but do not require signatures on the LDAP connection.
Open this question’s page →Identity authentication and access
✓ Correct answer
Verify the documented AD CS sensor prerequisite: certificate-authority assessments require the sensor on the AD CS server. Template assessment availability does not establish identical authority prerequisites. Generic Azure VM onboarding and a sensor only on a domain controller do not replace the required AD CS sensor coverage.
Open this question’s page →Identity authentication and access
✓ Correct answer
Delegation changes need dependency review and safer design. Constrained configurations can still expose sensitive entries, indefinite broad delegation retains risk, and content labels do not enforce Kerberos delegation.
Open this question’s page →Identity authentication and access
✓ Correct answers
Delegation/account controls and AD CS are identity hardening priorities. Synchronization affects trust, sensors do not repair all settings, and untested protocol removal can break required services.
Open this question’s page →Identity authentication and access
✓ Correct answers
Configuration and entity reassessment verify the change while score/status can lag. Immediate rollback based only on score is unsupported, one correction does not assure the forest, and disabling collection undermines assessment.
Open this question’s page →Identity authentication and access
✓ Correct answer
Identity-based access can remove the credential; a protected store handles unavoidable secrets. Comments and encoding leave it exposed, while administrator password reuse increases impact.
Open this question’s page →Identity authentication and access
✓ Correct answer
Separate boundaries and limited data access reduce cross-environment exposure. Admin MFA, private networking, and rotation protect other risks while leaving broad application secret access intact.
Open this question’s page →Identity authentication and access
✓ Correct answer
Rotation must coordinate consumer adoption and safe retirement. Creation alone proves no adoption, deleting historical keys can break recovery/decryption, and automatic switching is service-dependent.
Open this question’s page →Identity authentication and access
✓ Correct answer
Customer-managed-key actions affect data availability, so dependency and recovery matter. Encryption does not permit keyless reading; broader admins or incident labels do not restore the cryptographic dependency.
Open this question’s page →Identity authentication and access
✓ Correct answers
Soft delete enables recovery and purge protection prevents early permanent deletion. Plaintext logs, broad access administration, and shared credentials increase compromise or deletion exposure.
Open this question’s page →Identity authentication and access
✓ Correct answers
Managed HSM is key-focused; general passwords need an appropriate secret store. Treating HSM as a general password database is a product-boundary error, unsafe recovery material exposes keys, and premature disablement can break services.
Open this question’s page →Privileged access and governance
✓ Correct answer
The control plane governs enterprise trust and access. Workloads store business value; a productivity desktop and content-delivery layer are not the enterprise trust authority.
Open this question’s page →Privileged access and governance
✓ Correct answer
Deployment authority creates management-plane impact. Being outside a DC does not make it low privilege, cost is irrelevant to authority, and HTTPS does not reduce its granted control.
Open this question’s page →Privileged access and governance
✓ Correct answer
Credential-reset authority can enable control of the executive identity. A missing direct role, MFA, and unrelated VM restrictions do not eliminate that indirect privileged path.
Open this question’s page →Privileged access and governance
✓ Correct answer
Controlling privileged group membership can enable broad access. A narrow assignment does not cancel other grants, obscurity is not authorization, and retained logs do not prevent elevation.
Open this question’s page →Privileged access and governance
✓ Correct answers
Impact-based classification and limited task/scope align. Management and backup tools can be highly powerful; access administration should not be universal, and nested groups can carry real privilege.
Open this question’s page →Privileged access and governance
✓ Correct answers
Segregated approval/evidence and protected deployment paths address the impact. Short duration alone preserves self-approval/evidence abuse, direct-role-only reviews miss indirect paths, and excluding deployment identities ignores their production authority.
Open this question’s page →Privileged access and governance
✓ Correct answer
PIM provides eligible activation. Audit retains activity, monitoring collects telemetry, and a network security group filters traffic rather than granting time-limited roles.
Open this question’s page →Privileged access and governance
✓ Correct answer
Access packages govern the bundle’s request, assignment, and expiry. PIM governs activation, reviews reassess existing rights, and session controls do not create the resource bundle lifecycle.
Open this question’s page →Privileged access and governance
✓ Correct answer
Access reviews recertify existing access. Token duration changes sessions, patches fix devices, and unrestricted app registration adds risk rather than reviewing entitlements.
Open this question’s page →Privileged access and governance
✓ Correct answer
Weak permanent eligibility can still lead to broad active privilege. It is not zero activation capability, devices remain important, and PIM is not universal third-party cloud governance.
Open this question’s page →Privileged access and governance
✓ Correct answers
Eligibility and limited activation reduce standing privilege. Permanent Owner retains it, suppressed notifications reduce oversight, and unrestricted self-approval weakens sensitive access control.
Open this question’s page →Privileged access and governance
✓ Correct answers
PIM controls privileged activation and reviews recertify rights. Access packages do not remove malware, PIM scope is not every local privilege, and reviews do not configure routing.
Open this question’s page →Privileged access and governance
✓ Correct answer
Pass-the-hash reuses NTLM material. Pass-the-ticket reuses Kerberos tickets, Kerberoasting gathers service-ticket material for offline cracking, and access review is a governance process.
Open this question’s page →Privileged access and governance
✓ Correct answer
DCSync abuses directory replication authority to obtain credential material. Ordinary LDAP reads do not grant replication of password secrets; Kerberoasting requests service tickets, and pass-the-hash uses an NTLM hash for authentication rather than directory replication.
Open this question’s page →Privileged access and governance
✓ Correct answer
Kerberoasting enables offline cracking of service-ticket material. Tickets do not inherently disable services or grant Enterprise Admin, and human MFA does not rotate service-account secrets.
Open this question’s page →Privileged access and governance
✓ Correct answer
The backup may preserve an already compromised directory state, so trusted recovery material must be assessed. The newest backup is not inherently safe. Encryption protects backup confidentiality but does not prove the restored state is uncompromised, and a read-only DC backup cannot restore writable domain controllers across every domain.
Open this question’s page →Privileged access and governance
✓ Correct answers
Kerberos ticket reuse and credential replication are the stated mechanisms. Kerberoasting is credential cracking, pass-the-hash uses NTLM material, and malicious certificates from AD CS can enable authentication.
Open this question’s page →Privileged access and governance
✓ Correct answers
Trusted material/credentials and all-domain planning support recovery. One snapshot is not a validated forest plan, compromised credentials retain risk, and recentness alone does not establish a safe restored state.
Open this question’s page →Privileged access and governance
✓ Correct answer
Separate the privileged identity and use a secure administration workstation to reduce exposure to daily email and browsing. A single account combines those exposures. A shorter timeout does not separate the privileged identity or trusted device; monitoring can reveal misuse but leaves the exposed administration path in place.
Open this question’s page →Privileged access and governance
✓ Correct answer
Cloud-only accounts avoid the failed federation dependency. Synchronized/federated recovery repeats it, relying solely on one live agent adds fragility, and retention does not restore authentication.
Open this question’s page →Privileged access and governance
✓ Correct answer
Microsoft recommends permanent active emergency roles to avoid activation dependency. Unavailable approval repeats lockout, deleting recovery removes resilience, and an unprivileged user cannot recover tenant administration.
Open this question’s page →Privileged access and governance
✓ Correct answer
The enterprise model evaluates all impactful paths. Federation does not necessarily disable native access, rare use is not protection, and privileged native activity still needs monitoring.
Open this question’s page →Privileged access and governance
✓ Correct answers
Cloud-only independent authentication supports recovery. Microsoft recommends multiple accounts, avoiding expiry/cleanup, and permanent active emergency privilege rather than unavailable activation approval.
Open this question’s page →Privileged access and governance
✓ Correct answers
Exclusions preserve recovery while strong authentication and monitoring constrain its use. Removing authentication is unsafe, routine use expands exposure, and deleting audit evidence prevents accountability.
Open this question’s page →Privileged access and governance
✓ Correct answer
CIEM analyzes infrastructure entitlement risk. Stronger authentication, PIM activation, and project package governance contribute other controls but do not themselves discover and assess multicloud infrastructure permissions.
Open this question’s page →Privileged access and governance
✓ Correct answer
Native CIEM is part of Defender CSPM. The standalone permissions product is deprecated; auditing and patching do not replace entitlement analysis.
Open this question’s page →Privileged access and governance
✓ Correct answer
Effective reach determines privilege impact. Role names and sign-in count do not bound actions, and group-based assignment may still grant excessive effective permissions.
Open this question’s page →Privileged access and governance
✓ Correct answer
Usage-based recommendations need dependency validation and safe narrowing. Blind removal can break recovery, ignoring all findings preserves excess, and broader rights worsen the problem.
Open this question’s page →Privileged access and governance
✓ Correct answers
Effective analysis and contextual attack paths are documented. CIEM does not certify legal status, replace every IAM engine, or guarantee safe autonomous removal without dependency review.
Open this question’s page →Privileged access and governance
✓ Correct answers
Nonhuman identities can be overprivileged and MFA does not narrow authorization. CIEM is multicloud and includes application identities; absence of human sign-in does not make permissions harmless.
Open this question’s page →Privileged access and governance
✓ Correct answer
An access review recertifies entitlement need. Sign-in frequency governs sessions, updates fix operating systems, and certificate renewal maintains trust material.
Open this question’s page →Privileged access and governance
✓ Correct answer
Denied decisions change reviewed access only when results are applied. Check manual application and the automatic-application setting. Deadline completion, reviewer notifications, and recommendations alone do not confirm that the denied grants were removed.
Open this question’s page →Privileged access and governance
✓ Correct answer
Fallbacks and deliberate nonresponse policy keep decisions accountable. Indefinite silence preserves risk, universal self-review can be inappropriate for privilege, and absent audits undermine evidence.
Open this question’s page →Privileged access and governance
✓ Correct answer
The source is on-premises AD, requiring an appropriate source-side action. Review denial does not automatically override synchronization, names are irrelevant, and retention does not edit group membership.
Open this question’s page →Privileged access and governance
✓ Correct answers
Reviewer/fallback and outcome behavior define control accountability. Frequency alone omits enforcement, universal privileged self-attestation lacks risk-based oversight, and recommendations alone do not prove source-side removal.
Open this question’s page →Privileged access and governance
✓ Correct answers
Scope-aware inventory and effective-access checks test actual removal. The report can omit direct grants, completion is not proof of enforcement, and blind deletion ignores dependencies.
Open this question’s page →Privileged access and governance
✓ Correct answer
Device compromise can undermine the session. Remote desktop does not guarantee a safe source, portals do not require unpatched devices, and encryption does not assign roles.
Open this question’s page →Privileged access and governance
✓ Correct answer
The compromised origin can undermine credentials and interaction. The jump server and transport encryption protect other boundaries; MFA alone does not neutralize source malware after authentication.
Open this question’s page →Privileged access and governance
✓ Correct answer
Approved applications and sites reduce exposure. More browsing and local administration expand it, while stopping alerts removes detection.
Open this question’s page →Privileged access and governance
✓ Correct answer
The clean-source principle limits assurance when the origin is compromised. MFA and gateways strengthen parts of the path but do not eliminate device compromise or replace device controls.
Open this question’s page →Privileged access and governance
✓ Correct answers
Management and execution restrictions support trust. General browsing, personal email with privilege, and unrestricted local admin expand compromise exposure.
Open this question’s page →Privileged access and governance
✓ Correct answers
The full path includes device/account and intermediary/interface. Transport-only protection, MFA-only protection, and target-only compliance each omit parts that can compromise the privileged session.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Owned, scoped, tested controls turn obligations into action. Product purchase does not prove implementation, provider certification does not cover all customer duties, and a score alone omits control evidence.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Shared controls require defined contributions. Assigning everything to Microsoft ignores customer configuration, no owner prevents accountability, and purchase does not implement the required settings.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Action records connect implementation, testing and evidence. Configuration alone does not show effectiveness, provider reports may not cover customer access controls, and score changes omit the test’s accountable scope.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Scoped customer/shared controls need evidence. Certified hosting covers provider scope, provider-only review omits customer duties, and technical benchmark results cannot establish all organizational obligations.
Open this question’s page →Regulatory compliance and controls
✓ Correct answers
Responsibility/scope and tested evidence make assurance assessable. Scores assist prioritization, unowned exceptions retain risk, and automation cannot be assumed to prove all organizational duties.
Open this question’s page →Regulatory compliance and controls
✓ Correct answers
Ownership and relevant manual evidence cover different obligations. A firewall does not demonstrate training, a template does not deliver it, and one technical check cannot prove all control types.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Sensitivity labels classify and can encrypt content. Scores track progress, PIM controls privilege, and routes do not protect document content.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
DLP addresses sensitive-sharing behavior. Audit retention observes it, markings alone do not enforce the required action, and content preservation does not stop a permitted share.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
A case hold preserves relevant content. Audit records describe operations rather than preserving the source content, a marking does not impose retention, and a search without a hold does not ensure preservation.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Content preservation is separate from audit record retention and its licensing/policy rules. Labels do not change all licensing, and retention does not remove resource access controls.
Open this question’s page →Regulatory compliance and controls
✓ Correct answers
Compliance Manager manages compliance work and eDiscovery manages evidence. DLP does not elevate Azure roles, labels do not patch servers, and content retention is not CIEM.
Open this question’s page →Regulatory compliance and controls
✓ Correct answers
Channel-specific enforcement and correctly scoped evidence/access validate the intended controls. Labels do not guarantee every channel, broad case access exposes evidence, and scores do not prove preservation.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Azure Policy evaluates and can enforce configuration rules. PIM governs privilege timing, eDiscovery handles evidence, and access packages manage entitlement lifecycle.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Audit exposes impact without blocking. Immediate Deny risks disruption, unrelated Modify does not test the restriction, and a blanket exemption bypasses it rather than evaluates it.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Remediation uses a task and authorized assignment identity. Deny does not repair existing resources, caller rights do not substitute for the deployment identity’s rights, and definition changes alone do not remediate the estate.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Changing a definition does not automatically update the identity’s role grants. Broad directory administration is unnecessary, and removing checks conceals noncompliance rather than authorizes deployment.
Open this question’s page →Regulatory compliance and controls
✓ Correct answers
Audit observes and Deny blocks requests. Deny is not automatic repair, broad RBAC does not inherently bypass policy, and initiatives group policy definitions rather than grant a user role.
Open this question’s page →Regulatory compliance and controls
✓ Correct answers
The inherited applicable Deny still blocks the request. A governed exception must address that denying assignment through appropriate scope, assignment changes, or an applicable exemption. The most permissive assignment does not win; Contributor cannot ignore Deny, and adding an unrelated tag does not convert the effect to Audit.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
The dashboard shows control assessments and gaps. It does not grant auditor approval, replace all organizational work, or store employee credentials.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
AWS scope, onboarding and standard/plan support must be explicit. Azure assignment alone, guest log collection, and MFA do not establish AWS resource compliance coverage.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
Resource drilldown connects the failing assessment to remediation. Suppression and standard removal hide the gap; provider-only actions do not correct the customer resources.
Open this question’s page →Regulatory compliance and controls
✓ Correct answer
The actual state and next assessment determine whether remediation is reflected. Updates are periodic, an overall score can obscure the resource result, and manipulating standard assignment is not validation.
Open this question’s page →Regulatory compliance and controls
✓ Correct answers
Manual evidence and centralized compliance workflows broaden assurance. Automated checks do not prove all procedures, one resource does not certify an organization, and customer duties remain.
Open this question’s page →Regulatory compliance and controls
✓ Correct answers
The report summarizes assessed scope while remaining obligations need evidence. It is not universal certification, provider actions do not remove customer duties, and ongoing assessment is needed to detect drift.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Foundational CSPM supplies these basic posture capabilities without cost. Defender CSPM adds advanced paid posture features. Defender for Servers Plan 2 protects server workloads. Defender for Office 365 protects collaboration threats, not cloud resource posture.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
MCSB directly provides shared cloud security principles with platform-specific implementation guidance. CIS Benchmarks are useful platform-specific hardening standards, but are not the requested Microsoft cloud-neutral foundation. NIST CSF supports risk-management outcomes, and ISO/IEC 27001 defines management-system requirements rather than detailed Azure and AWS implementation controls.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Defender CSPM adds contextual risk prioritization and cloud attack-path analysis. Foundational assessments or a workbook can expose configuration findings but do not enable those paid analysis capabilities. Servers Plan 1 primarily adds endpoint detection and response for servers.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Technical assessment is evidence for supported controls, while remaining obligations still need review. Mapping to industry standards does not confer legal certification. Posture checks are not complete runtime incident evidence. Manual process controls remain necessary where automation cannot assess them.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
CSPM addresses configuration and CWPP addresses runtime threat activity. MCSB assessments and secure score do not provide continuous process detection. External discovery observes the internet-facing surface rather than internal VM execution.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Defender CSPM does not automatically activate all CWPP plans, and advanced feature coverage varies by environment. Recommendations for supported configurations, environment-specific support validation, and Foundational CSPM secure score are valid expectations. Plan selection must follow required controls and support matrices.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Microsoft Secure Score consolidates recommended improvements for supported Microsoft 365 identities, apps, and devices. Defender for Cloud secure score focuses on assessed cloud resources. Compliance Manager evaluates compliance improvement actions, while the vulnerability-management exposure score focuses on vulnerability exposure rather than this broader Microsoft 365 posture view.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Secure Score indicates recommended actions taken but does not guarantee security. It is not a legal certification or an exact attack forecast. Recovery testing verifies business resilience and cannot be replaced by a posture score.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Benchmarks provide context; exposure, critical assets, coverage, and recovery can differ. A similar score does not imply identical attack surfaces, licensing, or recovery capabilities. Interpret the measurement alongside the actual control environment.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Business risk should drive remediation while Secure Score tracks recommended improvements. Maximizing points can miss urgent exposure. Waiting for a benchmark delays protection. A posture metric is not an incident-response queue.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Secure Score supports trends and posture KPIs with comparison context. It does not prove complete access review coverage, replace vulnerability assessments, or guarantee freedom from compromise. Those require separate evidence and controls.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Alternate protection should be documented and verified, and the score should be presented with residual-risk context. Unverified completion creates misleading evidence. Removing identity findings hides exposure. A score benchmark cannot establish that an alternate implementation works.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Inventory and requirements determine scope and suitable collection methods. One agent cannot protect every resource type. Exempting external clouds removes coverage. A score target without owners does not identify what must be protected or remediated.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Reconcile connector scope and permissions with the restructured account inventory to restore provider-API resource visibility. EDR onboarding concerns endpoint telemetry; standards assignments concern assessment of discovered resources. Log retention preserves collected records but does not grant discovery access to missing accounts.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Owners and remediation workflows convert posture findings into fixes. Healthy collection does not require replacing the connector. The SOC investigates threats but cannot be the sole accountable owner for every configuration change. Waiting for feature parity by exempting findings abandons available protection.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
EDR supports continuous process telemetry, while agentless scanning provides complementary supported findings. Snapshots do not record every real-time process. Compliance checks evaluate posture, and EASM observes the external surface rather than internal process execution.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Expected visible resources with valid collection and delivery of findings demonstrate operational coverage. Plan billing does not prove sensor health. A connector object can omit scope. Dashboard availability does not establish completeness.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Automated scoped onboarding and inventory reconciliation with health monitoring maintain coverage. A fixed rollout drifts over time. Unrestricted administration adds risk without proving necessity. Delaying alerts for feature parity suppresses protection that can already operate.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Plan 1 emphasizes server EDR through Defender for Endpoint. Foundational CSPM assesses configuration. Storage protection targets storage threats. Defender for Office 365 targets collaboration threats.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Defender for Servers Plan 2 combines Plan 1 EDR with supported agentless server scanning. Plan 1 alone and Foundational CSPM do not supply the requested combination. Defender CSPM can supply agentless posture capabilities, but the stated alternative omits the required EDR coverage.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Defender for Containers supplies the requested combination when its components and access are configured. Node EDR is useful defense but does not by itself establish container image assessment and Kubernetes runtime coverage. Posture-only assessment or pipeline image scanning leaves the runtime requirement unmet.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
The support matrix establishes capability applicability. Matching plan names do not imply parity. Public management exposure creates risk and does not extend service support. Billing settings do not replace host firewall controls.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Database protection must fit the engine and host, while storage detection and scanning address the upload workload. Office 365 protection does not provide database runtime protection. EASM is external discovery. Secure Score does not quarantine files.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Runtime protection depends on its components, health, permissions, and connectivity. Billing proves plan activation, not telemetry. Registry scanning and runtime protection are separate capabilities. A score export cannot replace a runtime sensor.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Azure Arc-enabled servers registers supported machines as Azure resources while they remain in place. Site Recovery handles recovery replication, Azure Migrate supports migration assessment and discovery, and Azure Monitor Agent collects telemetry; these alone do not provide the Arc resource-management bridge.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Extensions can execute as root, so extension deployment is an administrative capability. It exceeds read-only inventory, application-user access, and recommendation viewing. Scope and protect the role accordingly.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Provide the required ongoing outbound connectivity. Arc agent communication does not depend on opening public inbound SSH or HTTPS to the host. Allowing endpoints only during installation breaks subsequent agent operation and management.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Use scoped onboarding permissions and separate later administration. Owner and Contributor contain powers beyond enrollment, including sensitive management actions. Reader is insufficient to create the Arc resource. The role should match the operation rather than default to a broad administrator or a read-only role.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Customers retain access-control and machine/agent security duties. Microsoft operates its cloud service infrastructure. Resource visibility is not a security guarantee, and local administrative activity still needs monitoring.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Reducing extension operations and protecting management roles limit administrative reach. Inventory readers do not need host-administration powers. Azure delivery does not make every extension appropriate. Unrestricted token access exposes the managed identity’s permissions.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Defender EASM follows public infrastructure relationships to find external assets beyond the known estate. Resource Graph covers existing Azure resource scope, endpoint inventory covers discovered or onboarded devices, and a connected-account cloud inventory is bounded by its onboarded cloud scope.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Known legitimate public assets such as company domains seed recursive discovery. Subscription identifiers, a private-only address range, and an internal OU tree do not by themselves establish the public infrastructure relationships needed for this external discovery.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Inferred relationships need ownership validation and appropriate classification. Deletion is not justified by discovery. A relationship alone does not prove ownership. Automatically ignoring third-party links can conceal relevant external dependencies.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
External observation cannot establish internal sensor health. A certificate does not prove EDR deployment, and DNS ownership does not prove patch state. Endpoint inventories provide complementary evidence and should remain.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
EASM discovers and evaluates the external surface. Local password rotation is LAPS, process telemetry is EDR, and Kubernetes admission enforcement belongs to cluster policy controls. Those may complement the program but are not EASM functions.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Ownership and business risk guide remediation, which must be verified. Unrelated score improvements do not close this exposure. Discovery does not automatically patch the host. Blanket approval ignores the uncertainty of inferred asset relationships.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
An attack path models a potential end-to-end route to critical assets through connected weaknesses and permissions. A flat vulnerability ranking lacks relationships. A network route alone lacks exploitation and privilege context. The modeled path does not require a confirmed incident.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Path context connects weakness, permissions, and critical data to potential impact. It does not establish a confirmed compromise, eliminate ownership, or prove unrelated vulnerabilities harmless. Context supports priority and response.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
A security initiative groups metrics and recommendations around ransomware protection to track preventive improvement. An OS inventory, one saved path query, and incident severity reporting can provide useful inputs, but none by itself organizes coordinated posture progress against that objective.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answer
Incomplete data can suppress paths, so collection and inventory need verification. Absence is not proof of safety or remediation. Deleting the connector preserves the blind spot rather than reducing risk.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Restricting the unnecessary entry point and reducing excessive identity privilege directly changes the modeled route. Certificate rotation unrelated to the exploited weakness, patching an unrelated asset, and additional logging do not remove the stated exposure or permission path. Reassess feasibility after remediation.
Open this question’s page →Hybrid multicloud posture and exposure
✓ Correct answers
Criticality and ownership align remediation with business risk, while metrics and verification show progress. Raw finding count ignores impact. Missing telemetry creates uncertainty. Permanent unreviewed exceptions allow exposure to persist.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
EDR detects and investigates endpoint execution behavior. Configuration assessment examines posture, vulnerability scanning identifies known weaknesses, and EASM observes external assets. These complementary controls do not replace runtime process telemetry.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Platform support and prerequisites establish which controls work. Policy assignment and a plan name do not prove feature support or effective enforcement. Windows-only settings cannot be assumed to work across Linux distributions.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Ownership, deadlines, and verification close assessed weaknesses. More scans alone refresh evidence. Suppression hides unresolved exposure. A paid plan can surface findings but does not implement a remediation process by itself.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Arc is a management bridge and customers retain host security and access duties. It does not make Microsoft the administrator of local accounts or prove application patching. Inventory visibility is not a substitute for monitoring.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Secure configurations and prioritized vulnerability remediation reduce exploitable conditions. Unsupported software without review retains risk. Universal host administration broadens compromise impact. A score target does not patch systems.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Operational EDR requires actual telemetry and a functioning response path. Installation and inventory records alone do not prove detection. Disabling integration suppresses evidence rather than fixing delivery or tuning legitimate noise.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Compliance policies evaluate requirements and report status. Configuration profiles and firewall policies set device settings. App protection policies protect supported app data and do not replace full device compliance assessment.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
App protection policies govern corporate data in supported apps and can pair with suitable access requirements. A compliance-only policy does not supply app-data controls on these unmanaged phones. Full-device configuration requires enrollment beyond the stated scope. MFA authenticates users but does not govern copying or handling corporate app data.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Risk signals can feed compliance or app protection and access evaluation. A static firewall rule cannot consume the dynamic device-risk decision. Policy assignment does not establish cleared risk. Disabling compliance removes a needed enforcement input.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Conflicting configuration values need deliberate resolution and effective-state verification. Creation time is not a universal precedence rule. Marking compliance without state evidence is misleading. Adding another contradiction worsens the conflict.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Tamper protection guards settings and cloud-delivered protection strengthens threat prevention. Shared administrator credentials enable lateral movement. Disabling network protection and excluding all downloads weaken coverage rather than strengthening it.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Platform support and actual resulting state establish effective coverage. Windows settings do not map universally to mobile systems. Assignment alone does not prove receipt or enforcement. Removing risk signals weakens the ability to make informed access decisions.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Unique protected credentials limit the identity blast radius. Shared secrets and shared certificate private keys let compromise spread across devices. An unauthenticated endpoint cannot establish a trustworthy device identity.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
TPM or suitable hardware protects device key material and supports attestation. Cloud-only storage does not address credentials on the device. A shared fleet key expands compromise impact. TLS protects transport and does not by itself provide hardware key storage.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
A trusted signed manifest authenticates the expected hashes, which the agent then compares with downloaded binaries. A hash from the same unauthenticated location could be replaced with the malicious binary. TLS certificate verification secures the connection but does not by itself authorize the intended firmware content.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
X.509 authentication needs issuance, renewal, replacement, and trust lifecycle management for long-lived devices. Initial trust alone omits later change, long validity does not handle compromise or eventual expiry, and connectivity tests do not renew or replace credentials.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
A complete design protects assets and credentials as well as the data path. Cloud-only protection leaves the device boundary exposed. Possession is not trustworthy authentication. Low bandwidth does not remove confidentiality and integrity requirements.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Retirement must remove identity/access and address retained data. Reusing active old credentials defeats isolation. Unplugging does not revoke cloud authorization. Removing inventory before verification loses evidence of successful decommissioning.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Defender for IoT network monitoring provides agentless OT-aware visibility. The controller cannot host the endpoint agent. VM disk scanning targets supported compute disks, while firewall connection logs do not by themselves supply industrial protocol and behavior analysis.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
SPAN or TAP supplies the industrial packets needed by the OT sensor. A connector or license alone does not supply observed traffic. An agent on another workstation does not guarantee visibility of controller communications.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Locally managed sensors provide analysis and console access on premises without mandatory Azure connectivity. Cloud-connected sensors or cloud-only console operations violate the stated data boundary. EASM observes public infrastructure rather than internal OT traffic.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Safety-critical actions need operational validation and coordinated response. Blanket shutdown can create physical harm. Ignoring alerts retains compromise risk. A dashboard supplies information rather than replacing industrial safety or control systems.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Network sensors analyze observed traffic agentlessly, and local management requires manual intelligence updates. Analysis and alerting occur on the sensor rather than requiring all raw packets in Azure. Visibility depends on the feed. Cloud connectivity does not authorize unsafe control actions.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Feed-path comparison and expected-inventory validation determine observed coverage. A healthy sensor may receive incomplete traffic. Unsupported agents can be infeasible or disruptive. Dashboard availability does not establish visibility of every segment.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
An Intune security baseline groups recommended Windows configuration settings and allows customization. A compliance policy evaluates conditions, and an EDR policy configures a focused protection area. A baseline is not immutable or equally appropriate unchanged for every role.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Baselines support customization where justified, with risk and compatibility assessment. Immediate broad deployment repeats the disruption. Blanket permanent disablement abandons useful controls. One incompatible setting does not invalidate the whole baseline.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Compliance policies assess required device-state conditions and supply that status to appropriate Conditional Access enforcement. Another configuration profile sets values rather than providing that evaluation. EDR onboarding and a location-only access rule do not establish the full required device compliance state.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Effective device settings and status prove rollout better than template version alone. Offline devices may have stale settings. Deleting profiles without comparison can remove needed configuration or obscure differences.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Piloting and justified tailoring manage compatibility, while overlap review prevents conflicts. Different roles can require different controls. Guidance evolves and must be reassessed. Assignment alone does not prove effective enforcement.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Deployment guardrails prevent new gaps, and ongoing assessment detects drift. Old reports do not describe current resources. Permanent exemptions preserve risk. Inventory tags identify resources but do not enforce hardening.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Windows LAPS directly manages and rotates each device local administrator password. PIM governs privileged role activation, BitLocker escrow supports disk recovery, and Windows Hello for Business changes user sign-in authentication. Those controls do not alone rotate the shared local administrator passwords.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
AD LAPS encryption requires DFL 2016 or later; clear-text attributes protected by ACLs remain possible below that level. Entra ID does not support DSRM backup. DSRM management also requires suitable DC operating-system support.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
Encrypted LAPS passwords target a designated user or group for decryption. A caller must be authorized by that principal as well as able to read the attribute. Expiration-write rights, OU policy-link editing, and legacy clear-text attribute access do not authorize ciphertext decryption.
Open this question’s page →Server client IoT and OT security
✓ Correct answer
At DFL 2016+, supported Server 2019+ DCs can use LAPS DSRM management with AD encryption. Server 2016 DCs do not support that feature. Entra ID backup and clear-text DSRM backup are unsupported.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
DSRM backup is supported in AD with encryption enabled. Entra ID is not a DSRM backup destination. Post-authentication reset is not supported for DSRM. Shared passwords conflict with managed per-device credentials and create reuse risk.
Open this question’s page →Server client IoT and OT security
✓ Correct answers
Encrypted AD-backed deployment requires the domain prerequisite, schema preparation, and scoped access/decryption configuration. Broad read rights expose sensitive data. Entra-only backup does not require the AD schema steps. Ciphertext-read permission is distinct from decryption authority.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
The customer retains responsibility for IaaS guest OS patching. Microsoft maintains the underlying physical platform, while Defender for Cloud and Arc can support assessment or management. Enabling either service does not automatically transfer the guest-OS patching responsibility to Microsoft.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
PaaS moves underlying OS and physical infrastructure duties to Microsoft, while customer application settings, identities, and data remain customer responsibilities. Host firmware, platform OS operation, and datacenter access are provider responsibilities.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Service-specific requirements enforced through deployment automation and policy establish the approved configuration from the start. Audit-only assessments and runtime alerts identify issues but do not establish the initial configuration. An OS template does not express the relevant cloud-storage access, network, and data settings.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
The customer retains identity, access, data, and configuration governance. Provider infrastructure security does not determine customer user entitlements. Physical-access review and OS patch reports do not establish SaaS access appropriateness.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
Customer identity/access and data governance remain necessary across models. Datacenter power, physical hypervisors, and provider backbone operation are underlying provider infrastructure responsibilities.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
Existing-resource remediation and ongoing drift/ownership processes close the full lifecycle. New-deployment guardrails need not retroactively fix existing assets. Services require tailored controls. Template approval does not establish effective live configuration.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Distinct identities permit targeted revocation. A shared hub-owner secret grants excessive service authority and creates fleet-wide exposure. Anonymous ingestion cannot reliably identify a device. A shared administrator account prevents proper per-device isolation.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Use supported Entra authentication with a role and scope matching the required service operation. A full hub-owner key or unnecessarily broad Data Contributor scope grants excess authority. A management-plane Reader role does not automatically authorize IoT Hub data-plane operations.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Private connectivity controls reachability, not device identity or allowed operations. DNS resolution and IP reachability do not establish a trustworthy device. Hub-wide administration violates least privilege.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Cloud monitoring should not be the sole safety authority; validated operational processes must govern critical control. Telemetry presence does not authorize shutdown. Reader roles should not imply unrestricted commands. Monitoring remains useful alongside safety systems.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
Renewable device credentials and scoped backend operations reduce compromise and privilege risks. Shared service-owner keys enlarge the blast radius. Private paths do not replace authorization. Managed services still require customer security monitoring and access governance.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
The local operational path and cloud connection both carry sensitive data and authority. Securing only the subscription leaves gateway risk. Telemetry encryption does not authorize commands. Device names do not compensate for shared credentials.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
WAF inspects web application patterns. DDoS protection addresses volumetric availability threats. An NSG allows or denies network flows without application attack inspection. DNS supplies name resolution rather than HTTP payload inspection.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
A private endpoint, disabled public access, and working private DNS establish the intended private-only ingress. A private endpoint can coexist with public access. VNet integration controls outbound connectivity. Public-IP access restrictions narrow public ingress but retain a public path rather than implementing the requested private-only connection.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
The app’s private endpoint serves ingress, so outbound connectivity and authorization need separate review. It does not guarantee dependency routes. WAF inspection does not build private routing. A network address does not grant database permission.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Deployment authority can become access through code running as the app identity. Direct secret-reading permission is not the only route. Private ingress does not constrain trusted code’s service permissions. WAF does not establish deployment provenance.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
WAF and DDoS protection address distinct web and volumetric threats. TLS secures the channel rather than application input. NSGs filter flows instead of payloads. A private endpoint serves a private path and does not supply public ingress attack inspection.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
Positive private-path testing and negative public-path testing verify ingress. DNS resolution should not confer application administration. Untested creation is insufficient. Outbound integration is a separate direction and cannot prove inbound isolation.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Image vulnerability assessment checks software packages for known vulnerabilities. Signing verifies trusted provenance and integrity, runtime sensing observes execution behavior, and registry network and access restrictions protect artifact access. Those alone do not assess package vulnerability.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Remove the unnecessary privilege and host access to reduce post-compromise reach. Image signing and scanning are valuable artifact controls, while ingress restrictions narrow entry paths; none of the stated alternatives removes the excessive host authority available after the container is compromised.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Image assessment and runtime telemetry address different conditions. A scan is not a continuous execution record, does not justify host-administrator trust, and does not automatically enforce all admission policies.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Deploy the corrected image digest and verify that running pods use it. A fixed but unused registry image does not change existing workloads. Scanning only the replacement artifact misses running exposure. Restarting with the old pinned digest continues to execute the vulnerable artifact.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
Registry write protection and avoiding embedded credentials limit supply-chain and secret exposure. Shared secrets broaden compromise. Read access should not imply deployment authority. Unverified mutable changes weaken artifact traceability.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
Image vulnerability assessment and healthy runtime telemetry supply known-package findings and suspicious-execution detection. Signature checks verify integrity and provenance, admission checks enforce configuration, and private registry access restricts artifact paths. Those alone do not provide both required detection capabilities.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Namespace-scoped RBAC binds permitted operations to the resources the team needs. Namespace separation alone does not define user permissions. Cluster-wide bindings exceed the scope, and network policy constrains workload traffic rather than administrative operations.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Network policies constrain pod flows when enforced. Namespaces alone do not guarantee network separation. API privacy secures administration rather than all workload traffic. RBAC controls operations and is not a substitute for pod packet filtering.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Azure Policy admission enforcement can reject disallowed configuration before deployment. Audit-only policy reports violations without denying admission. Image findings assess packages, and runtime sensors observe execution after admission. Those do not provide the requested rejection at admission.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Control-plane privacy and workload ingress are separate boundaries. Private API access does not make every Service private or provide WAF inspection. Kubernetes administrative RBAC does not replace application authorization for external users.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
RBAC controls operations while network policies constrain traffic. Names do not automatically firewall namespaces. Image tags are not authentication. Universal cluster-admin grants excessive deployment authority.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
A supported runtime sensor and admission enforcement provide the two missing capabilities. Image assessment identifies package weaknesses, RBAC governs authorized operations, and network policy constrains traffic. Those controls complement the design but do not themselves supply suspicious runtime detection and configuration rejection at admission.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
A managed identity provides supported service tokens with scoped permissions and avoids a stored API key. A service principal client secret introduces another stored credential. Private connectivity does not change API-key authentication, and frontend authentication alone can leave the static backend key in place.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
AI security includes supporting services, DNS, egress, and permissions. A private endpoint does not automatically secure all dependencies. Disabling private DNS can break the intended path. Content filtering is not a substitute for storage network controls.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Rate limiting constrains consumption and schema validation rejects malformed requests. WAF rules alone do not define API usage quotas. Network isolation can still allow abusive authenticated calls. Output filtering occurs after request processing and does not replace gateway request controls.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answer
Human approval for high-risk operations and scoped permissions control authority independently of the model. System prompts guide behavior but do not confer safety guarantees. Private networking and output format do not establish transfer authorization.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
Private paths with DNS and approved egress constrain network exposure. Cloud management does not eliminate exfiltration risk. WAF complements rather than replaces authentication. At-rest encryption does not control network reachability.
Open this question’s page →SaaS PaaS IaaS containers and AI services
✓ Correct answers
Layered content filtering and adversarial testing with monitoring address AI interaction threats beyond the existing identity and network controls. Another private endpoint or additional service-role scoping strengthens those same boundaries, while rate limits constrain volume. These alone do not detect malicious prompt content or test adversarial model behavior.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
NSG rules directly filter permitted subnet flows and ports. WAF inspects supported web traffic. An application security group identifies resources for rules but does not enforce a filter by itself. A route table selects paths rather than defining port-based allow and deny decisions.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
Premium provides TLS inspection and IDPS. Standard and Basic do not provide those Premium inspection capabilities. NSGs filter flows and cannot act as an equivalent TLS or signature inspection engine.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
Private DNS and forwarding determine the resolved connection address. Certificate renewal affects TLS trust, role assignments affect authorization, and WAF detection mode affects inspection. None fixes an incorrect public resolution path.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
Security enforcement requires traffic to traverse the intended appliance. Appliance health does not prove routing. Private endpoints do not remove every unrelated public route. NSG flow identification does not provide TLS inspection.
Open this question’s page →Network security and Security Service Edge
✓ Correct answers
NSGs are stateful, and rule changes apply to new connections rather than necessarily interrupting established flows. Return traffic for an allowed established flow does not need a separate explicit opposite-direction rule. Lower numeric priorities are evaluated first. Verify new connections and use suitable session termination when immediate containment is required.
Open this question’s page →Network security and Security Service Edge
✓ Correct answers
Path-specific decisions require URL visibility, and HTTPS visibility requires a supported inspection/trust design. FQDN rules identify hosts, not every path. NSGs inspect flow attributes. Disabling certificate validation weakens security instead of establishing safe inspection.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
Entra Internet Access provides the identity-aware cloud-edge SWG for public internet and SaaS browsing. Private Access targets private resources. Browser session controls apply to their supported app sessions rather than providing this general SWG. An Azure Firewall deployment supplies Azure-network filtering but does not by itself provide the requested Entra user-aware cloud-edge access service.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
Place the specific domain allow at a higher priority than the broad category block. An undifferentiated block omits the exception, and placing the category block first can prevent the domain exception from being reached. A private app definition does not configure the public web filtering exception.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
The baseline applies to all Internet Access traffic routed through the service at the lowest priority. It does not require a linked Conditional Access policy, does not replace higher-priority rules, and does not treat device compliance as universal destination approval.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
SNI identifies a host, so full path inspection requires additional supported visibility. It does not carry every HTTP path. Category assignment does not establish every page’s safety. Policy assignment is not evidence of payload decryption or inspection.
Open this question’s page →Network security and Security Service Edge
✓ Correct answers
Filtering policies are ordered in security profiles, and Conditional Access links the appropriate profiles to user context. Traffic profiles acquire traffic but do not replace filtering policies. Private connector groups route private apps, and device compliance policies evaluate device state rather than containing SWG category rules.
Open this question’s page →Network security and Security Service Edge
✓ Correct answers
The acquisition path determines coverage, and traffic evidence plus positive/negative tests demonstrate enforcement. Licensing alone does not route traffic. Private connector health does not prove public SWG acquisition. Missing logs may reflect bypass and must be investigated.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
The Microsoft traffic profile acquires its supported Microsoft services. The Internet Access profile cannot replace that acquisition, and a private application profile targets internal resources. The compliant-network named location is an enforcement signal rather than the traffic acquisition profile.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
Tenant restrictions v2 defines permitted external tenant access; universal restrictions signaling makes that policy available on acquired authentication traffic. Inbound B2B policies address entry into the company tenant rather than all external-tenant authentication. Forwarding alone does not define tenant restrictions. Geographic location does not identify which external tenant is permitted.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
The compliant network requirement is tenant specific. Another tenant’s service does not automatically satisfy it. Guest status does not inherently bypass policy, and a public IP match is not equivalent to the tenant-bound network signal.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
Compliant-network checks are reevaluated when sign-in is required, so a fresh session is needed. Existing access does not prove the next authentication outcome. Geographic locations are a different signal. Deleting the requirement abandons validation rather than testing it.
Open this question’s page →Network security and Security Service Edge
✓ Correct answers
The restrictions policy defines the decision and signaling delivers the policy context on acquired authentication traffic. Forwarding alone does not define allowed tenants. Private connectors serve private resources, and EASM asset discovery is not an Entra tenant policy.
Open this question’s page →Network security and Security Service Edge
✓ Correct answers
Source IP restoration is a documented prerequisite, and fresh sign-in tests verify the tenant-bound path. Compliant network does not require maintaining egress IP ranges. Existing sessions may persist until reevaluation. Other-tenant paths do not automatically satisfy the required signal.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
Entra Private Access supports identity-aware access to designated private TCP resources such as this file share. Internet web filtering protects public destinations. Application proxy web publishing and browser session controls target web applications rather than brokering the stated SMB connection.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
A separate per-app definition provides its own resource scope, user assignment, and Conditional Access boundary. A broad Quick Access app with identical permissions cannot differentiate finance. Connector placement and DNS aliases do not by themselves create a separate enterprise-application policy boundary.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
The connector uses outbound cloud connections and private backend reachability. Inbound NAT is not required for that channel. A site-to-site route alone does not establish the Private Access connector service. Direct public backend access bypasses the intended private-access boundary.
Open this question’s page →Network security and Security Service Edge
✓ Correct answer
The failure is connector specific after user policy succeeds, so inspect its backend path. User assignment and sign-in success validate identity stages rather than this route. A peer connector’s health does not prove the failing connector shares its reachability.
Open this question’s page →Network security and Security Service Edge
✓ Correct answers
At least two connectors in the relevant group plus verified cloud and backend reachability provide a usable failover path. Current single-connector health does not remove that failure point. An unmapped backup group does not participate in the app group failover, and a larger sole VM adds capacity without connector redundancy.
Open this question’s page →Network security and Security Service Edge
✓ Correct answers
Per-app scope with explicit users and Conditional Access reduces the network-access boundary. Broad tunnel access does not establish data authorization. Payroll authorization remains necessary. Connector administration should not imply business-data entitlements.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Microsoft Secure Score covers recommended improvements for supported Microsoft 365 identities, apps, and devices. Defender for Cloud secure score concerns cloud-resource posture. Vulnerability severity and mail delivery success are narrower measures and do not replace the requested tenant posture metric.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Some Secure Score actions award proportional points, so coverage must be checked. An increase does not prove universal assignment, regulatory compliance, or the absence of successful attacks.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Secure Score supports non-Microsoft solutions and alternate mitigations. Duplicating protection solely for points is unnecessary; accepting unrelated risk misrepresents posture, and removing a working control increases exposure.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Business impact and exposure should drive priority, so the merger workspace deserves attention. Point totals alone cannot rank local risk, waiting for a benchmark leaves exposure open, and peer performance does not justify accepting access to critical data.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
Coverage and validation connect the posture metric to effective protection. Policy-object counts do not prove enforcement. Approved exceptions need validation rather than mere counting. A point increase cannot guarantee freedom from compromise.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
An accountable exception and practical access testing expose residual risk. A peer benchmark does not justify permanent acceptance, excluded sessions need their own coverage evidence, and posture scoring does not replace incident detection.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Safe Links protects supported link clicks. Safe Attachments analyzes attachments, SaaS posture management assesses app configuration, and device configuration does not provide this email link service.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Plan 2 adds attack simulation and automated investigation capabilities. Built-in filtering and Plan 1 do not provide the requested complete feature set, while SaaS discovery addresses application usage.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Supported session controls can restrict downloads while retaining approved unmanaged-browser use. Blocking all unmanaged devices violates the availability requirement. SaaS posture assessment addresses configuration, and OAuth consent review addresses app permissions rather than interactive browser downloads.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
App governance and consent controls address app-to-app permissions and behavior. Browser timeouts do not govern offline API access, Safe Attachments focuses on malicious attachments, and discovery alone does not govern the granted permissions.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
Sender authentication complements Safe Attachments. Authentication alone does not prove benign content, SaaS posture scoring is not attachment analysis, and disabling user reporting weakens response.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
App and client support determine session coverage, and OAuth API access requires appropriate app governance. Connected apps do not all offer identical enforcement, discovery is not proof of blocking, and email protection does not replace consent governance.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
App protection policies protect corporate information in supported apps without full enrollment. Full MDM exceeds the stated management boundary. Device-wide wipe risks personal data. Compliance evaluation alone does not provide in-app data-transfer protections.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Conditional Access makes the resource-access decision using compliance. A local app PIN protects app entry, configuration sets device state, and EDR onboarding enables endpoint protection. None alone implements the required cloud access decision.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Selective app wipe removes supported corporate app data while preserving personal content. Factory reset exceeds that boundary. Compliance evaluation does not itself remove local corporate data. Mail retention preserves server content rather than wiping the protected mobile app.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Supported client validation and access enforcement close the bypass path. App protection does not automatically govern every app, abandoning all protection is unnecessary, and a PIN in one app leaves the other route open.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
App PINs and supported transfer restrictions are app protection controls. OS patching and universal device-wide configuration exceed the app-data boundary. Mobile app protection does not classify all SharePoint content.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
Compliance evaluates state and Conditional Access enforces supported access requirements. Evaluation alone does not guarantee cloud access blocking, apps must participate in the protection framework, and selective app wipe targets organizational rather than all personal data.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Configured sensitivity labels can attach classification and encryption rights to supported files. Retention addresses lifecycle, audit supplies activity evidence, and peer comparison measures posture rather than protecting the file.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
DLP detects sensitive content and context and applies supported transfer actions. A marking-only label does not enforce the required audience restriction. Retention governs preservation/deletion. eDiscovery investigates and preserves content rather than providing the stated transfer-policy enforcement.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
eDiscovery supports the complete preservation, review, and production workflow. Retention supports lifecycle preservation but not the full legal review and production case. Audit searches activity records rather than producing the relevant mail corpus. Label publishing classifies/protects content rather than conducting the case.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Container labels and file protection have different scopes, so actual file-level labeling and encryption must be tested. Container sharing restrictions do not automatically encrypt downloaded files, retention addresses lifecycle, and an activity record alone is not proof of encryption.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
DLP and retention solve the two distinct requirements. A watermark does not enforce all transfers, cloud discovery does not preserve records for a period, and disabling audit weakens evidence.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
Testing file rights and DLP behavior validates actual enforcement. Container labels do not automatically encrypt each file, retention does not remove readers, and catalog metadata is not proof of DLP enforcement.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Copilot uses the initiating user's existing permissions. License assignment, device compliance, and a posture score do not repair broad SharePoint source access.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
Copilot DLP can exclude supported labeled content while ordinary source access remains. Revoking source access violates the requirement. Retention controls lifecycle. A marking-only label without the supported processing rule does not establish the requested Copilot exclusion.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
The label-based control explicitly allows excluded items to appear in citations without using their content. Citation visibility alone does not prove processing failure; retention is a different control, and this is not evidence that all labels are ignored.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answer
The external-email preview compares sender metadata with accepted domains and excludes matching email from grounding, summarization, and citation. It does not inspect bodies for every injection, revoke ordinary mail access, or govern every externally originated document.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
The documentation gives the email date boundary and excludes calendar invites. It says direct prompt uploads are not content-scanned by this DLP control, file-open evaluation can require reopening after a mid-session label change, and source authorization remains separate.
Open this question’s page →Microsoft 365 Intune Purview and Copilot
✓ Correct answers
Web-search restriction preserves allowed internal grounding, while prompt blocking requires preview availability checks. Neither action inherently revokes source access; directly uploaded file contents are not inspected by this control, and SIT and label conditions cannot be combined in the same rule.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
An accountable inventory supplies scope and context for portfolio assessment. Flat findings without ownership cannot identify responsible remediation. Uniform risk ignores business consequences. Rewriting all applications before assessment is premature and can disrupt dependencies.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Deployed dependency records identify affected runtime versions. Ticket counts and general posture scores do not locate a specific component, and the default branch may differ from production.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Unused assets should be safely decommissioned and unnecessary permissions removed. Lack of recent use does not remove exposure, longer credentials increase persistence risk, and a paper retirement is not operational evidence.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Risk factors and ownership support meaningful prioritization. Counts alone, severity without local exposure or business context, and identical deadlines ignore differences in practical consequences.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Defender for APIs provides endpoint posture findings and API data classification. Its supported API coverage does not imply complete desktop, unrelated SaaS consent, or business-logic analysis.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Deployment verification and targeted retesting connect the fix to the affected workload. A commit or generic build status alone cannot establish runtime remediation, and deleting inventories removes useful evidence.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Spoofing concerns impersonating an identity. Repudiation concerns denial of actions, denial of service concerns availability loss, and information disclosure concerns unauthorized exposure.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Executing an administrator-only operation as an ordinary user illustrates elevation of privilege. Disclosure concerns unauthorized data exposure, repudiation concerns denial of actions, and denial of service concerns availability loss. Those outcomes are not the primary behavior described.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Attributable protected records address repudiation. At-rest encryption protects stored bytes, shorter sessions reduce exposure windows, and schema checks validate input format. None supplies trustworthy evidence of who changed payment details.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
New dependencies and privileged flows require architecture reassessment. An unchanged user interface does not preserve trust assumptions, a vendor scan does not analyze the customer integration, and secretless authentication does not prove appropriate authorization.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Architecture boundaries plus sensitive assets and user flows form the system model. Scanner output and compliance checklists provide useful inputs but cannot replace it. A network-only diagram omits application and identity trust relationships needed for threat analysis.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Ownership, validation, and response turn analysis into operational protection. A diagram does not implement controls, category assignment does not justify acceptance, and reassessment is required as architecture changes.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Continuous lifecycle security addresses design, code, supply chain, and operations. A final test cannot replace earlier controls, WAF cannot implement every requirement, and dependencies can become vulnerable after release.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
DAST evaluates running behavior and complements SAST. Repeating unchanged static analysis may miss the runtime issue. Dependency scans target known component weaknesses. WAF rules provide ingress protection but do not replace testing the deployed endpoint’s behavior.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Continuous scanning and reassessment catch newly disclosed risks. Approval dates and exemptions do not make software permanently safe, and freezing findings prevents timely remediation.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
A controlled emergency path balances speed with accountable validation and recovery. Uncontrolled direct edits and automatic blanket bypass introduce risk, while refusing urgent changes leaves active exposure unresolved.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Design reassessment and operational feedback protect different phases. One-time scans cannot guarantee future safety, broad production access increases attack paths, and unused endpoints should be decommissioned.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Revoking unnecessary access and safely retiring endpoints and data closes residual attack surface. Forgotten credentials, anonymous sensitive publication, and paper-only retirement leave substantial risks.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Default deny requires explicit authorization. Default permit, URL knowledge, and user-interface visibility do not establish server-side permission.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Trusted component review and limited privilege reduce supply-chain risk. Popularity alone is insufficient, shared administrator credentials amplify impact, and removing inventories prevents ongoing assessment.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
An exposed credential requires rotation or revocation and preventive correction. Deleting one line leaves history and copies, private repositories still have compromise risks, and longer validity increases the exposure window.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Environment separation, justified access, and protected test data reduce lateral movement and exposure. Training does not authorize every production action, encryption does not limit every permitted reader, and code review does not establish a network or data-access boundary.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Repository governance and protected trusted builds reduce source and pipeline compromise. Broad rights, unrestricted inbound access, and exempting open-source dependencies enlarge the attack surface.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Hard-coded credentials and weak environment boundaries are material risks. Training, structured review, and trusted component inventories are positive controls rather than weaknesses.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Key Vault is designed for restricted secret management. WAF protects web requests, caching does not provide a secret lifecycle boundary, and plaintext source storage exposes the credential.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
API Management provides the gateway facade and policies for credentials and usage control. Row-level security governs database rows, infrastructure encryption protects stored data, and score benchmarking measures posture.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Always Encrypted addresses supported column plaintext separation from the database engine. TDE protects files at rest, masking is not an adversarial encryption boundary, and a private endpoint limits network paths rather than administrator query rights.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Object-level authorization binds access to the correct user's records. WAF and token validation do not replace it; quotas regulate volume, encryption layers protect stored bytes, and token lifetime does not determine invoice ownership.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
WAF and backend authorization meet distinct web and business-access requirements. TDE encrypts stored database files rather than authenticating callers. Subscription keys do not prove individual object rights. Rate limits constrain volume but do not replace attack inspection or authorization.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Network paths and identity authorization are separate, and managed identity requires explicit permissions. Vault encryption cannot make an authorized reader trustworthy, rate limits do not prove record ownership, and authorized code can still export decrypted data.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Managed identity provides platform-managed authentication credentials. Shared employee credentials and source account keys retain credential-management risks, while anonymous access removes authentication rather than securing it.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
A user-assigned identity has an independent lifecycle and can be preauthorized. System-assigned identities are tied to their resources, image passwords require stored credentials, and personal administrator identities are inappropriate workload access.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
The required data role and scope determine authorization independently of successful token acquisition. Enabling a managed identity does not automatically grant downstream access. Resource-management permissions are not an equivalent replacement for the required data-plane role. Increasing token lifetime does not grant missing permission.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Federation validates the configured trust values against the external token. Broad secrets, disabling validation, and Owner permissions do not safely correct a mismatched trust relationship.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Lifecycle coupling defines system-assigned identities; independent reuse defines user-assigned identities. System-assigned identities are not shared this way, deleting one consumer does not delete the independent identity, and both need authorization.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Federation supplies secretless authentication and scoped authorization permits the intended deployment. Public access and shared humans are poor substitutes, and token exchange does not automatically provide resource permissions.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
API Management provides the API facade and configured gateway policies. WAF supplies web inspection, private endpoints restrict network access, and Defender for APIs adds posture and detection. They complement rather than replace the requested API routing, quota, and policy service.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
The audience binds a token to its intended API. Raising quotas and response caching do not validate that target, while disabling signatures weakens authentication further.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Object-level authorization controls access to each shipment. Key length and cache capacity do not decide ownership, and public backend access can add bypass risk.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
The origin needs an enforced access boundary and suitable identity controls. Gateway policies alone do not block direct calls, undisclosed URLs are not security boundaries, and larger limits do not prevent bypass.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Token validation establishes suitable identity evidence, while backend authorization controls the requested objects. Subscription keys and rate limits are not ownership checks, and untrusted tenant identifiers can enable cross-tenant access.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Validation and limits reduce malformed or excessive requests, protected backend authorization controls business access, and Defender for APIs adds detection. At-rest encryption does not enforce caller object rights, and a subscription key does not replace user identity.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
WAF inspects supported web attack patterns. NSGs admit or deny flows without HTTP attack inspection. DDoS protection addresses volumetric availability threats. Subscription keys identify API subscriptions rather than inspecting SQL injection or XSS payloads.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Detection mode intentionally logs without blocking. Managed-rule matches do not override that mode. Policy attachment does not prove every route or request is enforced. Observation cannot prove absence of backend vulnerabilities.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Targeted evidence-based tuning preserves useful inspection while addressing a false positive. Global disablement and broad allow rules unnecessarily weaken protection, and suppressing logs removes diagnostic evidence.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answer
Premium supplies the required integrated managed-rule capability. Standard custom rules are not Azure-managed sets. Replacing the requirement with custom rules misstates compliance with the design. A separate Application Gateway policy does not change the Front Door tier’s capabilities.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
WAF complements coding and authorization controls. It cannot guarantee all business-logic protection or secure bypass paths, and detection-mode logging does not necessarily deny requests.
Open this question’s page →Application lifecycle workload identities and APIs
✓ Correct answers
Log-based tuning and practical enforcement tests validate the change. Authenticated users can still attack, disabling diagnostics removes evidence, and saving policy does not prove route coverage or runtime behavior.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Discovery and inventory establish the real data footprint. Size and filenames do not determine sensitivity, and undocumented repositories can be important exposure points.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Shared meanings support consistent protection. Production-only scope misses sensitive copies. Incompatible labels without governance can lead to inconsistent handling. Abandoning classification removes needed business context.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Purview governance roles address metadata; actual data permissions remain separate. Public access, encryption status, and blanket Owner access are not appropriate conclusions.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Classification must follow sensitive data through copies and components. Derivation alone does not lower sensitivity, catalog metadata does not implement every protection, and source database encryption does not automatically protect a separate export.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Sensitivity, consequences, information type, and obligations define suitable classification. Size is not sensitivity. Default encryption describes one protection rather than business classification. An unvalidated inherited label can misrepresent the data’s meaning or current handling obligations.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Replicated data and classification quality require explicit review. Connector support does not prove configuration or coverage, metadata alone does not enforce every control, and filenames can conceal sensitive content.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Publicly exposed customer identity data has the higher described risk. Remediation ease and score points alone do not establish priority. Uniform urgency ignores differences in sensitivity, exposure, and consequences.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Permissions and export controls address authorized misuse. Extra at-rest encryption does not prevent service-mediated plaintext exports, higher quotas can increase volume, and encryption alone does not govern permitted reads.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
End-to-end restore testing verifies whether recovery objectives can be met. Encryption status does not establish restorability. Backup success alone does not prove usable restored data and dependencies. Classification identifies importance but is not recovery evidence.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Classification, consequences, and obligations support proportional protection. Public handling can expose health data, encryption alone does not implement access or retention requirements, and platform management does not remove customer data-handling responsibilities.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Minimization and consistent handling of copies reduce exposure. Primary controls do not automatically protect separate copies, indefinite retention increases risk, and unrestricted service access violates least privilege.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
An explicit residual-risk record and tested compensating controls support accountable acceptance. Unsupported closure and point totals conceal the risk, and a management note cannot erase legal obligations.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Key Vault stores and controls secrets with audit and access safeguards. WAF inspects web requests, response caching serves data, and source comments do not establish secure credential storage.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Customer-managed keys control service-level key management; infrastructure encryption adds a distinct layer. It does not disable service encryption, and key ownership does not automatically remove valid service data access.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Account-level infrastructure encryption is fixed at creation. Incident timing and key rotation do not enable it later, and the documented account setting cannot be changed after creation.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
The documentation supports selecting infrastructure encryption for a new scope when account-level infrastructure encryption is absent. Customer-managed service keys change key ownership rather than adding the layer, an existing scope setting is fixed, and secure transfer protects transport rather than adding at-rest encryption.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Constrained audited access and deletion recovery safeguards protect keys. Broad purge rights and disabled logs increase risk, and simply creating a vault does not prove lifecycle operations succeed.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Identity access, key availability across lifecycle events, and secure transport are complementary checks. At-rest encryption does not stop valid plaintext exports, and networking does not grant permissions.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Trusted document authorization constrains content before grounding. Content-safety filtering does not repair source permissions. Broad shared-search authority does not define each user’s rights. A system prompt is not an authorization boundary.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
A security filter is string-based and depends on trusted application context. More results increase potential exposure, a client string is not authentication, and at-rest encryption does not fix forged permission context.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
The application must act on the Content Safety API result according to its handling policy. Repeated detection without enforcement retains the attack path. Prompt Shields does not repair source authorization. A warning that ignores the result does not implement the required response.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Document attack detection and limited grounding/tool authority address the malicious instruction path. It is more than a factual error, broader privilege increases harm, and successful retrieval does not establish source trust.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Permission metadata and trusted retrieval enforcement establish the boundary. Post-retrieval model judgment, arbitrary caller groups, and response formatting do not provide reliable authorization.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Retrieval authorization, enforced attack handling, and least-privilege tool execution address different failures. Subscription Owner expands potential damage, and injection detection does not certify truth or access rights.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Row-level security enforces row predicates. Dynamic masking alters displayed field values, TDE encrypts stored files, and a Storage SAS does not define SQL department row access.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Always Encrypted separates supported column plaintext from the engine through client keys. TDE protects stored files. Masking does not provide a complete adversarial encryption boundary. Row-level security controls rows rather than keeping selected plaintext outside the engine.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Cosmos DB for NoSQL data-plane roles authorize item operations with appropriate scope. Resource management roles have a different purpose, account keys are broad credentials, and directory administrator roles exceed the workload requirement.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Workspace capabilities and SQL data permissions are separate. Notebook editing is not proof of table access, broad workspace administration expands privilege without diagnosing SQL rights, and removing network restrictions before assessing the described permission boundary is unjustified.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
TDE is at-rest protection and masking changes applicable query output. RLS controls rows rather than encrypting them, authorized queries can return TDE plaintext, and masking does not rewrite the stored values.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Execution capability and linked identity permissions can create a separate data path. Personal interactive rights do not automatically limit the execution identity, broad workspace administration increases risk, and Git access is a distinct permission plane.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Managed identity and a scoped data role provide secretless authorized access. Anonymous access removes the protection boundary, Owner is overly broad and not a substitute for a carefully scoped data design, and repository SAS storage exposes a bearer credential.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Narrow scope, permissions, expiry, and secure transport limit token exposure. Broad indefinite access and public token logs increase misuse risk even for a trusted supplier.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
The File subresource and client path need separate planning. Blob encryption does not create a File endpoint. Storage protocols do not universally share one subresource. Endpoint approval establishes connectivity rather than SMB identity permissions.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Stored access policies are supported for service SAS, not account or user delegation SAS. They do not make bearer-token leakage impossible, and revocation behavior remains part of the design.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Protecting the token and limiting its reach reduce risk. Account-wide permissions and indefinite validity expand exposure, and a recipient can forward a bearer URL.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Data authorization, validated network paths, and appropriate lifecycle protection cover distinct risks. Encryption alone does not block authorized exports, and private networking does not replace identity permissions.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
Defender for Storage supplies supported activity and sensitive-data threat detection. Foundational CSPM assesses configuration. SQL protection covers database threats. Service encryption protects stored data rather than detecting suspicious access.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
An isolated release workflow accounts for asynchronous scanning. Upload acceptance does not certify clean content, a longer SAS does not control publication, and removing logs weakens visibility.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
The documented plan supports NoSQL and excludes Gremlin. A product family name does not imply uniform API support, email protection does not supply Cosmos coverage, and encryption does not create the missing detector.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answer
The cap can halt scanning, so missing results must not be treated as clean. Plan enrollment and silence do not prove scanning, and arbitrary timers cannot guarantee completion.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Defender SQL provides assessment and threat alerts. It does not replace authorization or prohibit every legitimate administrator query. TDE is a separate at-rest encryption feature rather than the Defender detection mechanism.
Open this question’s page →Data classification encryption databases and storage
✓ Correct answers
Explicit result states, coverage monitoring, and accountable response make detections useful. Immediate absence of an alert does not prove clean content, and threat detection complements rather than replaces prevention.
Open this question’s page →MCRA MCSB and Zero Trust · CAF Well Architected and secure adoption · Application lifecycle workload identities and APIs
✓ Correct answer
Bind production federation to a protected approved workflow and environment, and narrow its deployment scope: Federation removes a stored secret, but its trust conditions and permissions still need to restrict the production path. Keep the broad federation trust and retain audit events for longer: Evidence is useful but leaves untrusted build execution able to change production. Replace federation with a shared production Owner secret: A standing shared secret does not resolve the broad authority and increases exposure. Add an internet WAF while keeping unrestricted build-to-production access: A web-edge control does not constrain authenticated deployment operations. Permit production access to all pull-request jobs if dependency scanning passes: Dependency findings cannot establish trust in arbitrary workflow code.
Open this question’s page →Business resilience and ransomware · CAF Well Architected and secure adoption · Data classification encryption databases and storage
✓ Correct answer
The full service requires 125 minutes, so redesign the dependency recovery path before declaring the RTO met: The sequential dependency delay and data restoration together exceed the business restoration target. The RTO is met because the database restore took less than 90 minutes: A component estimate is insufficient when the business service is still unusable. The RPO is 125 minutes because key access was delayed: RPO measures tolerated data loss rather than restoration duration. Keep the plan unchanged and remove encryption to make the recovery report simpler: The requirement calls for secure, usable recovery and a tested dependency design. Double replication frequency and assume dependency timing no longer matters: Replication frequency does not repair name resolution or key authorization.
Open this question’s page →MCRA MCSB and Zero Trust · CAF Well Architected and secure adoption · Application lifecycle workload identities and APIs
✓ Correct answer
Authorize customer and refund scope in the tool service and enforce approval before designated high-impact refunds: Independent constraints limit execution even if a model follows malicious retrieved instructions. Repeat the refund limit in the safety prompt without changing the tool: Natural-language instructions leave the underlying excessive authority intact. Approve every tool request automatically if Prompt Shields returned no detection: Detection does not establish transaction authorization or complete safety. Give the agent more data rights so it can independently decide all exceptions: Broader authority increases the consequences of agent manipulation. Review only a daily refund report after irreversible actions finish: Retrospective review does not provide the required pre-action approval boundary.
Open this question’s page →Business resilience and ransomware · MCRA MCSB and Zero Trust · Hybrid multicloud posture and exposure
✓ Correct answer
Prioritize the path to the payment and identity services using exposure, control influence, and business impact: The connected authority can affect multiple high-value functions and should be considered with severity. Treat the two issues as identical because their severity scores match: Severity alone omits the different business impact and administrative influence. Prioritize whichever application uses the most expensive VM size: Compute cost does not establish criticality or attacker impact. Choose only the application with the oldest framework version without evaluating its reachable paths: Version age alone does not resolve the stated business-risk comparison. Wait for the next license renewal before evaluating either attack path: Procurement timing is not a risk-based treatment decision.
Open this question’s page →CAF Well Architected and secure adoption · Regulatory compliance and controls
✓ Correct answer
The configuration assessment is useful evidence; validate the unmeasured operational and access controls against the actual obligations: A policy compliance state does not attest to every organizational control or recovery dependency. The compliant policy result is a complete regulatory attestation: The stated evidence gaps prevent that conclusion. Azure Policy has no governance value because it does not evaluate every control: Automated configuration assessment remains valuable within a broader assurance process. Replace the initiative with a reference-architecture diagram and declare assurance complete: A diagram also cannot establish control operation. Give auditors Owner permissions as the primary remedy for all gaps: Broad resource control does not itself validate access review, response, or recovery.
Open this question’s page →CAF Well Architected and secure adoption · Application lifecycle workload identities and APIs
✓ Correct answer
Reassess consequential decision risks, evaluate fairness and reliability, and enforce accountable approval and scoped execution before rollout: New write capability changes impact; responsible AI and authorization need validation beyond code and performance tests. Reuse the drafting-only approval because no model weights changed: The tool and consequential action path changed even without a different model. Approve release based only on the static code scan result: That does not evaluate decision quality, fairness, or the allowed autonomy. Grant administrator access to reduce failed submissions: Excess permissions increase risk and do not establish responsible decision-making. Add a general user disclaimer as a replacement for transaction approval: A disclaimer does not constrain consequential execution.
Open this question’s page →MCRA MCSB and Zero Trust · CAF Well Architected and secure adoption · Data classification encryption databases and storage
✓ Correct answer
Review and narrow overshared permissions, then validate retrieval and data handling with the approved user population: Correctly applying excessive entitlements can still expose sensitive information through the assistant. Release immediately because authorization checks correctly return allowed: The checks faithfully reflect a scope that is too broad for the business requirement. Replace authorization with a prompt telling users to avoid sensitive documents: Instructions do not remediate the underlying sharing permissions. Block all identity authentication and use an anonymous retrieval service: This removes the access boundary rather than improving it. Treat higher model accuracy as a fix for overshared access: Model accuracy does not reduce existing entitlements.
Open this question’s page →CAF Well Architected and secure adoption · Hybrid multicloud posture and exposure
✓ Correct answer
Evaluate a narrowly scoped, time-bound exemption with an accountable risk owner, compensating controls, and monitored remediation: This treats the justified workload exception without weakening unrelated controls across the estate. Remove the common initiative from all subscriptions until the legacy team finishes: This exposes unrelated workloads to the same governance gap. Move the workload into an unmonitored subscription with no exception record: That avoids governance rather than managing risk. Give the deployment identity broader RBAC and assume it overrides a deny policy: More role permissions do not generally bypass applicable Policy deny enforcement. Rename the blocked resource so the documented exception becomes unnecessary: Naming does not reliably change the requirement or its policy condition.
Open this question’s page →Business resilience and ransomware · Privileged access and governance · Data classification encryption databases and storage
✓ Correct answers
Remove the vault administrator standing rights that satisfy Resource Guard checks and require independent temporary authorization: This restores separation for the configured critical vault operations. Test restoration with approved recovery identities, usable keys, and required dependencies under the compromise scenario: This validates the practical recovery path when production authority is unsafe or unavailable. Increase production administrator rights so the same identity can handle every recovery task: That reinforces the concentrated compromised authority. Treat a successful replication job as proof of clean historical recovery: Replication may copy destructive changes and does not exercise restoration. Retain MUA but give its independent guard permissions back to the vault administrator permanently: Standing guard authority defeats the stated independent boundary. Declare every source-database operation protected automatically by Resource Guard: MUA has a defined vaulted-operation scope rather than every source operation.
Open this question’s page →MCRA MCSB and Zero Trust · CAF Well Architected and secure adoption · Application lifecycle workload identities and APIs
✓ Correct answers
Protect source and workflow changes with review and controlled release permissions: This constrains unauthorized changes before deployment. Scan components and validate artifact integrity and provenance before release: This checks dependency and artifact risks along the delivery path. Deploy threat detection and route actionable runtime findings to accountable owners: Runtime controls address attacks and weaknesses after deployment. Trust a valid artifact signature as proof that all dependencies are vulnerability-free: Signing alone does not establish dependency safety. Give the build runner broad standing production authority to avoid approval delays: That creates an unnecessary compromise path. Remove runtime monitoring once all pre-release tests pass: Pre-release success cannot cover all future runtime threats.
Open this question’s page →MCRA MCSB and Zero Trust · CAF Well Architected and secure adoption · Data classification encryption databases and storage
✓ Correct answers
Test indirect prompt injection from the external connector and verify independent downstream authorization: New untrusted content can manipulate behavior, so authorization must remain enforced. Validate approved data scope, identity permissions, and sensitive-data handling for the new source: Private connectivity and platform guardrails do not automatically set the correct data entitlements. Reuse the fixed-document evaluation without testing the new connector: The new content path was outside the prior evaluation. Assume a landing-zone deployment automatically certifies every model and connector: It provides a foundation rather than complete AI assurance. Make the agent platform Owner so private endpoints cannot cause access errors: This broadens authority without validating the needed data boundary. Let the connector publish secrets into prompts for more reliable authentication: Prompts are not appropriate credential stores.
Open this question’s page →Business resilience and ransomware · MCRA MCSB and Zero Trust · Identity authentication and access · Network security and Security Service Edge
✓ Correct answers
Verify identity and relevant device or risk context for supported access paths: Explicit verification evaluates the requesting principal and context. Restrict administrative permissions and segment access to the specific required systems: Least privilege and segmentation constrain an established compromise. Collect actionable telemetry and retain independently protected recovery capability: Assume breach requires detection, containment, and recoverability. Trust all requests after they pass through a corporate tunnel: Network origin is insufficient trust evidence. Use device compliance to grant unrestricted database access automatically: A posture signal does not establish all resource entitlements. Use one unrestricted administrator for production and all recovery controls: Concentrated authority increases the effect of compromise.
Open this question’s page →Published for public study on StudyByteLearn with the maintainer's permission. No permission for further redistribution is granted. Rights in the supplied source material remain with their respective holders. · Updated 2026-10-21
Original study items created by Codex AI agents for the requester on 2026-10-21 against the Microsoft SC-100 objectives effective 2026-10-21 and freshly retrieved Microsoft Learn documentation. Every item received author self-review and independent AI-agent peer review; no human or Microsoft endorsement is implied. StudyByteLearn schema, importer, answer scoring, objective coverage, and fixed-exam references were separately validated.