Software Development Security practice questions

Answer: A) An integrated product team

• AAn IPT brings stakeholders together so requirements, including security, are addressed throughout development.
• BA CAB reviews proposed changes rather than building products.
• CA red team emulates attackers.
• DAudit teams review controls; they don't build the product.

Answer: A) Runtime application self-protection

• ARASP monitors application behavior from within and can block attacks in real time.
• BStatic analysis reviews code without running it.
• CAn SBOM lists components.
• DA code freeze stops changes for a period.

Answer: A) Ship the remote interface turned off with MFA required, so customers must take a deliberate step to enable or relax it

Secure by default means a product ships in its most protective state, with protections on and enforced without extra effort, so that reducing security requires a deliberate action. Opt-in hardening, warnings or optional strong settings do not meet this principle.

• ACorrect. Secure by default means the product's out-of-the-box state is protective. Customers get the protection without extra effort, and reducing security takes an explicit, deliberate action.
• BIncorrect. This makes security optional and dependent on extra customer effort. Many deployments never apply hardening guides, so they stay exposed.
• CIncorrect. A reminder still leaves the default state permissive. The product stays insecure until someone acts on the warning, which is the reverse of secure by default.
• DIncorrect. Making strong options available is not the same as making them the default. If the protection is opt-in, systems whose administrators never change the configuration keep weaker settings.

Answer: A) Agile sprints with automated security tests built into the CI/CD pipeline so each increment is checked on every build

Agile's short sprints combined with automated security testing in CI/CD (DevSecOps) give every small increment security validation. Waterfall and the V-model are sequential models with long release cycles, and annual penetration testing is infrequent by design.

• ACorrect. Agile delivers work in short sprints, and CI/CD automation runs tests on every build. Adding security tests to the pipeline (DevSecOps) validates every increment continuously.
• BIncorrect. Phase-gate reviews add security checkpoints, but waterfall plans large projects up front and has long release cycles. It cannot support validated releases every two weeks.
• CIncorrect. The V-model improves test traceability, but it is still a sequential, plan-driven model. Testing happens after each corresponding build phase, not on frequent, small production increments.
• DIncorrect. A periodic penetration test is useful assurance, but it is exactly the large, infrequent assessment the manager wants to move away from. It does not validate each two-week increment.

Answer: A) Replace the key with short-lived credentials from a role scoped to only the deployment actions the pipeline needs

For pipeline credentials, the best control is to replace long-term secrets with short-lived, role-based credentials scoped to least privilege. Rotation, encryption at rest and log masking are only partial measures.

• ACorrect. This fixes both problems at once. Temporary, automatically expiring credentials remove the long-term secret, and a narrowly scoped role enforces least privilege, which limits the blast radius if the pipeline is compromised.
• BIncorrect. Rotation and monitoring help, but the credential is still long-lived and has full administrator rights. A leaked key stays fully usable until the next rotation.
• CIncorrect. Storing long-term credentials in source code or configuration files is a recognized anti-pattern, even when encrypted. The key also keeps its excessive permissions.
• DIncorrect. Masking stops one way the key can leak, but it does nothing about the key's broad privileges or long lifetime. Anyone who can change the pipeline can still use the key.

Answer: A) Infrastructure as code (IaC)

Keeping firewall rules, security groups and access policies as version-controlled declarative definitions that a pipeline applies automatically is infrastructure as code. It makes security configuration consistent, reviewable and repeatable, and prevents drift.

• ACorrect. IaC uses versioning and a descriptive model, preferably declarative definition files, to define and deploy infrastructure such as networks and their security settings. Release pipelines apply the definitions, and teams make changes by editing the source rather than the target. This makes environments repeatable, reviewable and resistant to configuration drift.
• BIncorrect. SOAR automates security operations and incident response workflows through playbooks across security tools. It does not hold an environment's desired configuration in version control or deploy it through a release pipeline.
• CIncorrect. A CMDB is a repository that records configuration items and their relationships for IT service management. It documents configuration but does not define and automatically apply it to environments from reviewed code.
• DIncorrect. SDN separates the network control plane from the data plane so that a controller can manage network behavior centrally and programmatically. It is a network architecture, not the practice of keeping versioned, reviewed configuration definitions that a pipeline deploys.

Answer: A) Type-safe parameterized queries for SQL injection; context-appropriate encoding of untrusted data at output for XSS

Parameterized queries keep user input as data, not SQL code, and output encoding for the specific context stops the browser from running injected script. Escaping, deny lists, WAFs and storing pre-encoded data are partial or flawed substitutes.

• ACorrect. With parameterized queries, user input is treated as a literal value, not executable SQL. Encoding untrusted data for the context it is written into (HTML, HTML attribute, JavaScript or URL) at the point of output stops the browser from running it as script. Input validation is a useful extra layer but does not replace either control.
• BMicrosoft says filtering or escaping characters is not a reliable defense against SQL injection, because many characters can cause problems. A WAF is a useful extra layer, but it does not fix the underlying flaw of writing unencoded output, and it can be bypassed.
• CStored procedures that concatenate unfiltered input into dynamic SQL are still vulnerable to injection. Accepted practice is to encode at the point of output, for the specific output context, and not to store encoded values.
• DDeny lists are easy to bypass with alternative encodings and syntax. Microsoft's XSS guidance says never to rely on validation alone and to encode untrusted data before output. Parameterization is still needed for SQL.

Answer: A) Have the pipeline digitally sign each approved artifact, and have the deploy stage reject any artifact whose signature fails verification

Signing artifacts in the pipeline and verifying signatures before deployment proves where each artifact came from and that it is unaltered. Location restrictions, unsigned hashes stored with the artifact, and code scanning can't prove an artifact is an approved, untampered build.

• ACorrect. A digital signature made with a key only the trusted pipeline controls proves where the artifact came from and that it hasn't changed. Checking the signature at deploy time blocks anything unsigned or tampered with. AWS Signer works this way with Lambda, ECR and EKS.
• BIncorrect. Limiting the location narrows the source, but it proves nothing about the contents. Anyone with write access to that path can drop in or replace an artifact, and it will still be deployed.
• CIncorrect. A hash detects accidental corruption, but it has no key and isn't tied to an identity. Someone who can replace the artifact can also replace the hash stored beside it, so it doesn't prove the pipeline approved the file.
• DIncorrect. SAST finds flaws in source code, but it does nothing to make sure the artifact that reaches production is the one the pipeline built. A substituted or modified binary would go undetected.

Answer: A) Inference; use polyinstantiation and restrict queries through views and query controls

Deducing classified facts from permitted lower-level queries is the inference problem. It is countered by limiting what can be queried and combined (views, query controls) and by polyinstantiation.

• AInference means deducing restricted information from data you are allowed to see. Polyinstantiation shows lower-cleared users different records at different classification levels, and views or query controls limit which results can be combined. Together they reduce what can be deduced.
• BEncryption at rest protects stored media, but it does nothing against an authorized user whose queries the database answers normally. The stem also describes deducing a fact, which is inference, rather than a collection of data becoming more sensitive as a whole.
• CData remanence is residual data left on media after deletion. Here the user reasons over live query results, so sanitizing deleted data would not help.
• DA lost update is a concurrency integrity problem in which one transaction overwrites another's change. Locking prevents it, but the stem describes a confidentiality problem.

Answer: A) Enable push protection that blocks pushes containing detected secrets, and have the application load credentials at runtime from a secrets vault

Preventive controls stop secret leaks at the source: push protection blocks pushes that contain secrets, and a secrets vault keeps credentials out of code. Encoding, access restriction, and deleting in a later commit all leave the secret exposed in repository history.

• ACorrect. Push protection checks incoming pushes and rejects any that contain recognized secrets. A secrets vault (for example, Azure Key Vault) keeps credentials out of the code, so there is nothing to commit.
• BIncorrect. Base64 is a reversible encoding, not encryption. Anyone who can read the repository can decode the key, so the secret is still committed and exposed.
• CIncorrect. Limiting access shrinks the audience but does not stop secrets from being committed. Every clone, fork, backup, and insider with access can still see them, and they stay in the history.
• DIncorrect. A later commit does not remove the secret from earlier commits in history. Once a secret is committed it should be treated as compromised and rotated, so this approach reacts after the fact and is incomplete.