ExamworthyExamworthy
Open the appStart free

SC-100 domain - 23% of the exam

Design Security Solutions for Applications and Data

Design Security Solutions for Applications and Data is 23% of the Microsoft Cybersecurity Architect (SC-100) exam. These are the objectives it covers, each with practice questions, with every answer explained.

The domain in numbers

62
Practice questions
3
Objectives
19
Medium
43
Hard

Where people go wrong

  • Placing a security practice at the wrong SDLC phase

    A security practice gets placed at whichever SDLC stage feels closest. Dynamic testing, static analysis, and penetration testing all run against code that is already committed, built, or deployed, so none of them can replace threat modelling at the design phase. The reverse happens too: threat modelling reasons about architecture, not commits, so it does not belong at a build-stage gate such as secret scanning or dependency scanning.

    See it in a sample question

  • Treating a stored secret as credential-free

    A rotated client secret, a certificate shipped inside the deployment package, or a secret moved into Key Vault can look like it removes the standing credential problem. Each of these still requires a secret to be stored, presented, or rotated. A managed identity lets Microsoft Entra ID create and rotate the credential automatically, and workload identity federation lets a pipeline exchange its own short-lived OIDC token for an access token, so no secret is stored. Key Vault is still the right home for a third-party key that no Microsoft identity can replace.

    See it in a sample question

  • Assuming encryption at rest hides data from admins

    Transparent Data Encryption and dynamic data masking look like they stop a database administrator from reading sensitive columns in plaintext. Transparent Data Encryption decrypts transparently for any authorised connection, and dynamic data masking only obscures values in the presentation layer for non-privileged users. Always Encrypted is the design that keeps the database engine, and its administrators, handling ciphertext only, because decryption happens only in the client and the engine never holds the key.

    See it in a sample question

  • Treating Sentinel as a built-in Defender plan

    Microsoft Sentinel, or another general monitoring tool, can look like it covers malware scanning or database threat detection once logs are streamed into it. Sentinel needs custom analytics rules that the team must author, and it has no built-in engine that scans blob content for malware. Microsoft Defender for Storage, Microsoft Defender for Databases, and the other Defender for Cloud workload-protection plans are the built-in, service-specific controls that scan and alert without custom analytics.

Objectives in this domain

What to study

The official documents this domain's practice questions cite most.

  • Microsoft Cybersecurity Reference Architecturescited by 10 questions
  • Microsoft cloud security benchmarkcited by 9 questions
  • Zero Trust Guidance Centercited by 5 questions
  • Microsoft Defender for Cloud Apps documentationcited by 4 questions
  • Microsoft DevSecOps controls guidancecited by 4 questions
  • Azure API Management documentationcited by 3 questions
  • Azure Web Application Firewall documentationcited by 3 questions
  • Microsoft cloud security benchmark data protection controlscited by 3 questions

Sample questions from this domain

Free sampleDesign Security Solutions for Applications and Datahard

A product team is about to begin building a new customer-facing payments service and asks a security architect when, in the application lifecycle, design-level security flaws such as missing authorisation boundaries and unsafe trust assumptions should be identified. The architect wants the practice that surfaces these flaws before code is written, by reasoning about the system's data flows and trust boundaries. Which practice best meets this requirement?

  • APerform threat modeling during the design phase, enumerating data flows and trust boundaries to identify and rank design weaknesses before any code exists. Correct
  • BRun dynamic application security testing against a deployed staging build so that exploitable runtime weaknesses are discovered before the service reaches production traffic.
  • CAdd static application security testing to the build pipeline so that insecure coding patterns are flagged automatically every time a developer commits source.
  • DSchedule an external penetration test ahead of launch so that an independent team validates the service's defences against realistic attacker techniques first.
Threat modeling is the design-phase practice that reveals architectural and trust-boundary flaws before code exists, unlike testing that runs against built software. Threat modeling reasons about a system's data flows, trust boundaries, and assets to enumerate how it could be attacked while the design is still on paper. Because it precedes implementation, it catches authorisation, trust, and exposure flaws when they are cheapest to fix, which testing techniques that need running or committed code cannot do.

Why A is correct: Threat modeling is the design-phase activity that maps data flows and trust boundaries to expose architectural weaknesses such as missing authorisation, so it identifies and ranks design flaws exactly when the requirement demands, before implementation begins.

Why B is wrong: Dynamic testing is valuable and tempting because it finds real exploitable issues, but it runs against built, deployed code and so cannot surface the design-level trust-boundary flaws the requirement targets before code is written.

Why C is wrong: Static analysis catches insecure code patterns and feels like the earliest control, but it operates on committed source rather than the architecture, so it misses design flaws that exist before code and that no scanner reads from a diagram.

Why D is wrong: A penetration test gives independent assurance and is appealing as a gate, but it happens against a near-complete system late in the lifecycle, so it finds design flaws only after they are expensively built rather than before code is written.

Free sampleDesign Security Solutions for Applications and Datahard

An architect is designing how an Azure-hosted web application will authenticate to Azure SQL Database and Azure Key Vault. The design goal is to eliminate any long-lived credential that a developer must store, rotate, or could accidentally commit, while still giving the application a strong identity inside Microsoft Entra ID. Which approach best satisfies this requirement?

  • ARegister an application and use a client secret stored in the app's configuration, rotating the secret on a defined schedule so that exposure windows stay short.
  • BAssign a system-assigned managed identity to the application so that Microsoft Entra ID issues and rotates its credential automatically and the platform retrieves tokens on its behalf. Correct
  • CGenerate a certificate-based service principal and place the private key in the application package so that the credential is bound to the running deployment artefact.
  • DConfigure SQL authentication and a Key Vault access policy keyed to a shared application username and password held in an encrypted configuration store.
A managed identity gives a workload a Microsoft Entra identity with platform-managed, auto-rotated credentials, removing any secret developers must store or rotate. Managed identities are workload identities whose credentials are provisioned and rotated by the Azure platform and never exposed to the application code or its operators. Tokens are retrieved through the platform rather than from a stored secret, which removes the credential storage, rotation, and accidental-commit risks inherent in client secrets, certificates, or shared passwords.

Why A is wrong: A registered app with a rotated client secret is a familiar pattern and feels safe with short rotation, but it still introduces a long-lived credential the team must store and protect, which is precisely the exposure the requirement aims to remove.

Why B is correct: A system-assigned managed identity gives the app a Microsoft Entra identity whose credential the platform creates and rotates automatically, so no developer ever stores or rotates a secret, which is exactly the credential-free design the requirement demands.

Why C is wrong: A certificate credential is stronger than a password and is tempting for that reason, but shipping the private key inside the package still creates a secret the team must protect and rotate, leaving the storable-credential problem unsolved.

Why D is wrong: An encrypted store for a shared username and password sounds protective and is a common reflex, but it still relies on a long-lived secret the application must read and someone must rotate, so it fails the requirement to eliminate storable credentials.

Free sampleDesign Security Solutions for Applications and Datahard

An Azure SQL Database stores customer national identity numbers, and a compliance requirement states that database administrators and anyone querying the server must never see those values in plaintext, even though the application must still process the real values. Which protection design satisfies this requirement?

  • AEnable Transparent Data Encryption on the database so that the identity number column is encrypted at rest and protected from administrators reading the underlying files.
  • BApply a dynamic data masking rule to the identity number column so that the values are obfuscated when administrators query the database.
  • CConfigure Always Encrypted on the identity number column with the column master key in Azure Key Vault so the values are decrypted only inside the client application. Correct
  • DEnforce TLS for all connections to the server so that the identity numbers are encrypted in transit and cannot be read by administrators on the network.
Use Always Encrypted with keys in Azure Key Vault to keep sensitive Azure SQL columns as ciphertext to the engine and administrators while the client decrypts. Always Encrypted performs encryption and decryption inside the client driver using a column encryption key protected by a column master key in Azure Key Vault, so the Azure SQL engine, the host, and high-privilege administrators only ever see ciphertext, which is the separation of data from key custodians that a never-in-plaintext requirement needs.

Why A is wrong: Transparent Data Encryption protects the data files at rest and is a sensible baseline, but it decrypts transparently for any authorised connection, so a database administrator running a query still sees the identity numbers in plaintext.

Why B is wrong: Dynamic data masking is tempting because it hides values in query results, but it only masks the presentation layer for unprivileged users, leaves the real data readable to privileged principals, and can be bypassed, so it does not meet a never-in-plaintext mandate.

Why C is correct: Always Encrypted encrypts the column so that the database engine and administrators only ever handle ciphertext while the keys, held in Azure Key Vault, allow decryption solely in the trusted client, which exactly meets the requirement that no one querying the server sees plaintext.

Why D is wrong: Enforcing TLS protects the data in transit and is a necessary control, but it does nothing for data sitting in the database, so administrators querying the server would still read the identity numbers in clear text.

Other domains in this exam

See also the SC-100 cert hub, the study guide, and the cheat sheet.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.