How do you protect applications and APIs from attackers without slowing down the teams that build them? This problem—balancing speed with safety—is the heart of designing security solutions for modern software. For the SC-100 exam, you need to understand how security shifts from a final checklist to an integrated, automated part of how software is built and delivered, a practice called DevSecOps.
Jump to a section
A simple way to picture Designing Application Security and DevSecOps Solutions
A commercial kitchen's exhaust hood must filter grease before air leaves the building, just like an API gateway must validate every request before it reaches application code.
In this kitchen, the head chef (developer) builds a menu and prepares recipes (application code). The fresher (operations) preps ingredients and cleans stations. The health inspector (security) shows up unannounced, checking preparation temperatures, cross-contamination risks, and allergen handling. Older kitchens treated security like the inspector—they cleaned frantically before visits, then went back to sloppy habits. Modern kitchens embed safety into every step: colour-coded chopping boards (input sanitisation), dated labels (dependency scanning), and hand-wash stations at every sink (secrets management).
The fire suppression system above the grill is not an afterthought—it is plumbed during construction, tested during service, and maintained by the same team that cooks. This is DevSecOps: security is not a final gate or a separate team; it is a pipe, a knife block, a timer. When the kitchen opens a second location (scales), the fire system, colour-coding, and labelling must multiply automatically, not require new training for each chef.
To understand application security and DevSecOps, start with how software used to be built.
In the traditional model, called the 'waterfall' approach, a team would spend months writing all the code for an application. When the code was finished, they handed it to a separate security team for a final review. The security team would find problems, the developers would fix them, and then the whole thing would go through another review. This process could take weeks or months. Security was a bottleneck.
Modern software development uses a different model called 'DevOps'. In DevOps, the people who write the code (developers) and the people who run the software in production (operations) work together as one team. They release small updates frequently—sometimes many times a day—instead of one big release every year. This speed makes the old security-review-at-the-end model impossible.
'DevSecOps' adds 'Sec' (Security) into this mix. It means security is not a separate phase or a separate team. Security practices are automated and integrated into every step of the software lifecycle. The three core ideas of DevSecOps are 'shift left', 'automation', and 'shared responsibility'.
'Shifting left' means moving security activities earlier in the development process—to the left on a timeline diagram. Instead of testing security at the end, you test it when a developer writes the first line of code. This catches problems when they are cheap and easy to fix.
Automation is essential because humans cannot keep up with the speed of modern releases. Automated tools scan code for vulnerabilities, check for hardcoded secrets (like passwords), and test for common web application flaws. These tools run every time a developer submits new code, not just once before a release.
Shared responsibility means that everyone in the team—developers, operations, and security specialists—owns security. Developers learn to write secure code and fix vulnerabilities. Operations teams configure environments securely. Security experts build the automated tools and set the policies.
Now, what are you actually securing? You secure applications (the programs users interact with) and APIs (Application Programming Interfaces). An API is how different software components talk to each other. For example, when you log into a website using your Google account, the website's code uses Google's API. APIs are everywhere, and they are a favourite target for attackers because they often expose sensitive data and functions.
Key security controls for applications and APIs include:
Authentication: verifying who the user is. Modern applications use OAuth 2.0 and OpenID Connect, often managed through Microsoft Entra ID (formerly Azure AD).
Authorisation: verifying what a user is allowed to do. This uses a concept called 'RBAC' (Role-Based Access Control) or more fine-grained 'ABAC' (Attribute-Based Access Control).
Input validation: making sure that incoming data is safe. Attackers can send malicious data that, if not checked, can crash the application or steal data (SQL injection, cross-site scripting).
Encryption: protecting data in transit (using HTTPS/TLS) and at rest (using encryption algorithms).
API security: using API gateways to throttle requests, validate tokens, and log activity. Every API endpoint must be treated as a potential entry point for attackers.
Secrets management: never hardcoding passwords, API keys, or connection strings in code. Use a vault service like Azure Key Vault to store secrets securely.
In Azure, the services you use to implement these controls include Azure API Management, Microsoft Entra ID, Azure Key Vault, and Azure Policy. You also use Azure DevOps or GitHub with integrated security scanning tools.
DevSecOps replaces the old model where security was a gate at the end. It reduces risk, speeds up releases, and makes security everyone's job. For the SC-100 exam, you must understand both the principles (shift left, automate, share responsibility) and the specific Azure services that enable them.
Threat Model the Application
Before writing any code, map the application's architecture, data flows, and trust boundaries. Identify where sensitive data enters, leaves, and is stored. This step, often done using the STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), tells you what to prioritise in later steps.
Establish Security Baselines with Policy
Use Azure Policy to define mandatory security rules—for example, 'All API endpoints must use HTTPS' and 'Storage accounts must be encrypted at rest'. These policies are enforced automatically whenever a developer creates a new resource, preventing configuration drift.
Integrate Security Scanning into the CI/CD Pipeline
Configure the build pipeline (e.g., in Azure DevOps or GitHub Actions) to run credential scanning, static code analysis, and dependency scanning on every code commit. If any scanner finds a critical issue, the build fails and the developer gets immediate feedback. This ensures security is tested continuously, not at the end.
Implement Centralised Secrets Management
Configure Azure Key Vault to hold all secrets, including database connection strings, API keys, and certificates. The deployment pipeline accesses the vault to inject secrets at runtime, ensuring they never appear in code. Developers use separate development vaults with test credentials so they never see production secrets.
Secure API Endpoints with a Gateway
Deploy all public APIs behind Azure API Management. Configure rate limiting, IP whitelisting, and OAuth 2.0 token validation. Enable logging to a central location (e.g., Azure Monitor) so that suspicious patterns—like a single user hitting the API thousands of times—trigger alerts.
Monitor and Plan for Incident Response
Set up monitoring with Microsoft Defender for Cloud to detect runtime threats. Create a playbook for responding to a vulnerability found after deployment—using a hotfix branch that bypasses normal testing but adds extra peer review. Continuously review and update the threat model as the application evolves.
A mid-size bank called 'NorthStar Finance' builds a mobile banking application for its customers. The development team is adopting a new microservices architecture, where the app is broken into many small services—one for user login, one for payments, one for transaction history. Each service has its own API.
The bank's IT security lead, Priya, is tasked with designing the security and DevSecOps solution. Here is what she actually does, step by step:
First, Priya maps the data flows. She identifies that the payment API handles personally identifiable information (PII) and financial data, making it the highest-risk component. The login API handles password verification, which is also critical. The transaction history API only reads non-sensitive cached data. This risk assessment determines where to invest security effort.
Second, she implements a security baseline using Azure Policy. She creates policies that enforce HTTPS-only traffic, require that all API endpoints use API Management, and block the creation of storage accounts without encryption. These policies are applied to every new resource automatically.
Third, she sets up DevSecOps pipelines in Azure DevOps. When a developer commits new code, the pipeline automatically runs:
Credential scanning: a tool checks the code for hardcoded passwords or API keys. If found, the build fails and alerts the developer.
Static application security testing (SAST): the tool analyses the source code for common vulnerabilities like SQL injection or buffer overflows.
Dependency scanning: the tool checks all third-party libraries for known vulnerabilities, using public databases (CVEs).
Software composition analysis (SCA): to manage open-source software licenses and vulnerabilities.
Only if all these scans pass is the code allowed to be deployed to a staging environment.
Fourth, for the APIs, Priya configures Azure API Management. She sets up rate limiting to prevent denial-of-service attacks. She integrates API Management with Microsoft Entra ID so that every API call requires a valid OAuth 2.0 token. She also enables logging and monitoring to detect unusual patterns, such as a single user making 1000 API calls per second.
Fifth, she implements a secrets management workflow. The development team cannot see production secrets. Instead, the deployment pipeline uses Azure Key Vault to pull the database connection string and third-party API keys at deployment time. If a developer needs to test locally, they use a separate development vault with test credentials.
Finally, Priya establishes an incident response plan. If a vulnerability is found in production (a 'zero-day' attack), the pipeline has a 'hotfix' branch that fast-tracks security fixes. The team can deploy a critical patch within hours, bypassing normal testing schedules but with extra scrutiny.
The result: the bank's development velocity remains high—they deploy updates daily. But the security posture is far stronger than the old model, where security was a manual review every three months. The automated scanning catches over 95% of vulnerabilities before they reach production.
The SC-100 exam tests your ability to design solutions, not just recall facts. For the 'Designing Application Security and DevSecOps Solutions' objective, you must demonstrate that you can choose the right Azure service for a given scenario.
Here are the exact concepts you must master:
The difference between shift left and shift right. The exam loves to test this. Shift left means testing security early in development. Shift right means testing security in production (e.g., using canary deployments or chaos engineering). A scenario might describe a team that wants to test how their API handles malicious traffic; the correct answer is to 'shift right' with a live testing tool like Azure Chaos Studio, not a static analysis tool (shift left).
The three pillars of DevSecOps: People (culture, training), Process (pipeline gates, workflow), and Technology (tools, automation). The exam often gives a scenario where a team has all the tools but still has security incidents; the root cause is likely a missing 'people' or 'process' element.
Specific Azure services and their security roles:
Azure API Management: secures and manages APIs. Provides throttling, IP filtering, token validation.
Azure Key Vault: stores secrets (passwords, keys, certificates).
Microsoft Entra ID: identity provider, handles authentication and authorisation for apps.
Azure Policy: enforces compliance rules (e.g., 'all APIs must use HTTPS').
Azure DevSecOps (in Azure DevOps or GitHub): scanning tools (Credential Scanner, CodeQL).
Azure Security Center / Microsoft Defender for Cloud: provides a unified view of security posture across all resources.
Common exam traps:
Trap: The question describes a vulnerability found in a third-party library. The answer is to use 'dependency scanning' (or Software Composition Analysis), not static code analysis (which scans your own code).
Trap: The question mentions a developer accidentally committing a password to a Git repository. The answer is to use 'credential scanning' in the pipeline, and rotate the credentials immediately using Key Vault.
Trap: The question asks about securing an API that external partners will use. The answer is to use Azure API Management with OAuth 2.0, not just a firewall.
Trap: The question describes a team that wants to automate security checks without slowing developers. The answer emphasises 'automation' and 'integration into the CI/CD pipeline', not manual review gates.
What the exam will NOT ask: you do not need to memorise every API endpoint or syntax of Azure Policy. The exam is about design decisions: which service, which approach, which principle.
Key definitions to memorise: 'SAST' (Static Application Security Testing—looking at source code), 'DAST' (Dynamic Application Security Testing—testing a running application), 'IAST' (Interactive Application Security Testing—a hybrid), and 'SCA' (Software Composition Analysis—checking open source libraries).
Finally, the exam frequently uses 'Microsoft Entra ID' in scenarios. Always assume that modern applications use OAuth 2.0 and OpenID Connect, not older protocols like SAML unless explicitly stated.
DevSecOps is a cultural shift that integrates security into every phase of software development, not a toolset added at the end.
Shift left means moving security testing earlier in the development lifecycle to catch vulnerabilities when they are cheapest to fix.
APIs require dedicated security controls including rate limiting, token validation, and logging because they are high-value automated targets.
Azure API Management is the primary Azure service for securing, managing, and monitoring APIs at scale.
Automated security scanning in the CI/CD pipeline must include credential scanning, static analysis, dependency scanning, and software composition analysis.
Secrets such as passwords and API keys must never appear in code, config files, or environment variables; they belong in a vault like Azure Key Vault with access controls and rotation policies.
The SC-100 exam tests design decisions—choosing the right service or principle for a given scenario—not memorising tool syntax.
A common exam trap is confusing Static Application Security Testing (SAST) with Software Composition Analysis (SCA); SAST scans your own code, SCA scans third-party libraries.
These come up on the exam all the time. Here's how to tell them apart.
SAST (Static Application Security Testing)
Analyses source code or binary without executing it
Catches vulnerabilities early in development (shift left)
Cannot detect runtime issues like configuration errors or authentication logic flaws that depend on state
DAST (Dynamic Application Security Testing)
Tests a running application by sending inputs and observing responses
Detects vulnerabilities that only appear when the application is running, like insecure cookies or server misconfiguration
Slower than SAST and requires a deployed environment, making it a 'shift right' activity
Role-Based Access Control (RBAC)
Permissions are assigned based on predefined roles (e.g., Admin, User, Viewer)
Simpler to implement and manage for small or predictable user populations
Can lead to 'role explosion' when you need fine-grained permissions
Attribute-Based Access Control (ABAC)
Permissions are based on attributes (e.g., department, location, security level)
More flexible and granular, allowing complex policies like 'allow access if user is in HR and document is confidential'
Requires a policy engine and careful attribute management
Azure Key Vault
Centralised, audited, and encrypted storage for secrets
Supports automatic rotation and access policies based on Microsoft Entra ID
Requires an API call to retrieve secrets at runtime — slightly more complex to set up
Environment Variables for Secrets
Easy to set up — just export a variable in the shell or a pipeline
No built-in auditing or rotation; anyone with access to the process or server can read them
Secrets can persist in log files, build artifacts, or be accidentally committed to version control
OAuth 2.0
Modern protocol designed for API and mobile app authentication
Uses JSON-based tokens (JWTs) which are lightweight and easy to validate programmatically
Supports delegation (e.g., a service acting on behalf of a user)
SAML (Security Assertion Markup Language)
Older protocol designed for web browser single sign-on
Uses XML-based assertions which are larger and more complex to parse
Not designed for API or mobile scenarios; works best with browser redirects
Mistake
DevSecOps means you add a security tool to your existing DevOps pipeline and you're done.
Correct
DevSecOps is a cultural and process change, not just a tool addition. You must also train the team, define policies, and shift responsibility for security to developers, not just add a scanner.
People assume that because they bought a tool, they have 'done DevSecOps'. Tools are necessary but not sufficient; the human and process elements are the harder part.
Mistake
If an application passes all automated security scans, it is completely safe to deploy.
Correct
Automated scans catch known vulnerability patterns, but they miss business logic flaws (e.g., allowing a user to transfer money to anyone without approval) and zero-day vulnerabilities. Security is about risk reduction, not perfection.
Beginners want a definitive 'pass/fail' checklist. Security is probabilistic, and threat actors find creative ways around controls that no automated scanner detects.
Mistake
APIs are just internal plumbing, so they don't need as much security as a user-facing website.
Correct
APIs are often more valuable targets than web pages because they handle structured data and automate actions. Attackers can use an API to batch-dump databases or trigger fund transfers without ever seeing a login page.
People think of APIs as just 'connections' between systems, forgetting that automated access is exactly what attackers want. An unprotected API is a goldmine.
Mistake
Using Microsoft Entra ID (Azure AD) automatically secures your application.
Correct
Microsoft Entra ID provides authentication (who you are), but you must still implement authorization (what you can do) correctly in your application code. A common mistake is trusting the identity token without checking permissions.
Beginners think 'I used Azure AD, so I'm secure'. But Entra ID only handles the front door; the locks on the inner doors still need to be correctly installed by the developer.
Mistake
Secrets management means you should never write down a password, but you can store API keys in environment variables or config files.
Correct
Environment variables and config files are better than hardcoding, but they are not secure. Secrets must be stored in a dedicated secrets vault (like Azure Key Vault) with access logging and rotation policies.
People think 'I'm not hard-coding it, so it's fine'. They don't realise that environment variables can be read by any process on the same server, and config files are often checked into version control accidentally.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
DevOps focuses on collaboration between developers and operations to release software quickly. DevSecOps adds security as a core part of that collaboration, integrating automated security checks into every step of the pipeline instead of treating security as a separate stage at the end.
No, but you need to understand the basic categories of security testing (static analysis, dynamic analysis, dependency scanning) and how to integrate them into a CI/CD pipeline. The tools automate most of the work; your job is to decide which tools to use and how to respond to their findings.
Shift left means performing security activities (like threat modelling, code review, and vulnerability scanning) as early as possible in the development lifecycle. In practice, it means running security scans on every code commit rather than waiting until the code is in a staging environment.
Use an API gateway (like Azure API Management) which handles authentication, rate limiting, and throttling efficiently. These gateways are designed for high throughput and can cache responses. Also, only apply heavy security checks to endpoints that handle sensitive data; other endpoints can use lighter validation.
The most common mistake is buying a security scanning tool and assuming the job is done. Teams forget to change their processes (like making failing scans block a release) and their culture (like training developers to fix vulnerabilities rather than ignoring them). Without process and culture change, the tool is just noise.
Microsoft Entra ID (formerly Azure AD) provides a central identity and access management service. For applications, it handles authentication—verifying that users are who they claim to be—using industry-standard protocols (OAuth 2.0, OpenID Connect). It also allows you to define conditional access policies (e.g., require MFA for sensitive apps) and manage app permissions.
You've finished Designing Application Security and DevSecOps Solutions. Continue through the SC-100 study guide to build a complete picture of the exam.
Done with this chapter?