it’s safe to store a database password in a private GitHub repo.

• True

• False

Which practice helps prevent SQL injection vulnerabilities?

• Using eval() on inputs

• Strict input validation and parameterized queries

• Giving the DB user full admin rights

What is the purpose of Azure Key Vault?

• Store large BLOBs

• Perform automated database backups

• Manage and audit encryption keys/secrets safely

What is the main risk of using eval() on user input in Python?

• It’s slow

• It can execute arbitrary code from the user

• It can’t handle strings

• It doesn't support variables

Why shouldn’t you log user passwords or API keys?

• There is no problem with that

• Because people with log access can see them breaking least privilege rule

• Because logs are often accessible and can leak secrets

Which of the following is the best practice for storing a production API key?

• In a .env file committed to the repo

• As a plaintext string in your source code

• In Azure Key Vault with restricted access

• Inside a shared Excel file on SharePoint

What does “principle of least privilege” help prevent?

• Data duplication

• Time zone issues

• Code duplication

• Lateral movement in case of a breach

You see this in a Python repo: password = "mydbpass123" — what's the first thing you do?

• Shrug, it’s just dev code

• Escalate to your manager

• Replace it with os.getenv("DB_PASS") and store it in Key Vault

• Rename the variable

Which of the following is a bad idea when handling secrets in CI/CD?

• Using a vault to retrieve secrets dynamically

• Hardcoding credentials in the pipeline YAML

• Masking secrets in logs

• Using GitHub Secrets to pass credentials

What’s the recommended way to avoid logging sensitive data accidentally?

• Use structured logging with filters/masking

• Turn off logging entirely

• Only log in production

• Print everything to stdout