Contemporary Backend Development and Future Directions

Introduction

Backend development has moved beyond the traditional model of a continuously running application server connected to a database. Modern backend systems may execute only when an event occurs, place computation close to users, expose strongly typed service contracts, or assemble capabilities from managed cloud platforms. At the same time, backend teams are increasingly responsible for software supply-chain security, privacy, environmental impact, and the responsible use of artificial intelligence.

For developers working with Node.js and Django, these developments do not replace established principles such as HTTP, authentication, data modelling, testing, observability, and secure coding. Instead, they extend the design space. A contemporary backend engineer must select an architecture according to workload, latency, reliability, security, cost, team capability, and regulatory obligations.

This chapter examines serverless and edge computing, GraphQL, gRPC, platform engineering, zero-trust architecture, supply-chain security, sustainable computing, AI-assisted development, and secure integration of AI services. The emphasis is not on fashionable technologies but on informed architectural judgment.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the operational and architectural characteristics of serverless and edge computing.
2. Compare REST, GraphQL, and gRPC for appropriate backend use cases.
3. Describe how platform engineering improves developer experience and operational consistency.
4. Apply zero-trust and software supply-chain security principles to Node.js and Django systems.
5. Evaluate sustainability concerns in backend architecture.
6. Assess benefits and risks of AI-assisted software development.
7. Design a secure integration involving model APIs, vector stores, privacy controls, evaluation, and responsible-AI governance.

1. From Application Servers to Distributed Platforms

A conventional backend commonly consists of an application process, a reverse proxy, a database, and supporting services. The application may run on a virtual machine or container, and the team manages deployment, scaling, patching, logging, and recovery.

Contemporary architectures distribute these responsibilities across several layers:

• Application code: business rules, validation, authorization, and integration logic.
• Runtime platform: virtual machines, containers, functions, or edge runtimes.
• Managed services: databases, queues, object storage, identity systems, and observability tools.
• Delivery platform: source control, continuous integration, deployment automation, and policy enforcement.
• Governance layer: security, compliance, privacy, cost, sustainability, and risk management.

This distribution creates advantages but also introduces dependency and coordination risks. A system may have fewer servers to administer while depending on more external services, APIs, credentials, and configuration policies. Consequently, architectural quality must be evaluated at system level rather than by examining application code alone.

A useful decision principle is to place each responsibility at the layer best able to perform it. For example, a managed identity provider may implement authentication more reliably than application-specific password handling, while domain authorization usually remains a responsibility of the application because it depends on business context.

2. Serverless Computing

2.1 Meaning and characteristics

Serverless computing does not mean that servers disappear. It means that infrastructure provisioning and many operational responsibilities are abstracted from the development team. The provider allocates execution resources, often automatically, and charges according to use or an agreed service plan.

Two major serverless forms are:

1. Function as a Service (FaaS): short-lived functions execute in response to HTTP requests, messages, schedules, or database events.
2. Backend as a Service (BaaS): managed services provide capabilities such as authentication, databases, storage, messaging, and notifications.

A serverless function is typically stateless from one invocation to another. Persistent state is stored in external services. Functions may also experience a cold start, in which a runtime must be initialized before processing a request. Subsequent invocations may reuse a warm runtime, but this reuse cannot generally be assumed for correctness.

2.2 Benefits

Serverless architectures can provide:

• automatic or elastic scaling;
• reduced infrastructure administration;
• rapid deployment of small capabilities;
• cost alignment with variable demand;
• convenient integration with event-driven services; and
• improved isolation between independently deployable functions.

A Django application can be deployed through a serverless adapter, while Node.js is a common runtime for functions. However, simply placing a monolithic application inside a function does not automatically create a good serverless architecture. Function boundaries should reflect meaningful events or capabilities, not arbitrary source-code divisions.

2.3 Limitations

Serverless systems introduce several trade-offs:

• Latency variability: initialization and network calls may increase response time.
• Execution limits: providers may impose limits on duration, memory, payload size, or concurrency.
• Distributed debugging: one user request may cross several managed services.
• State management: sessions, transactions, and workflows require explicit design.
• Vendor dependence: proprietary triggers, APIs, and deployment models may reduce portability.
• Cost uncertainty: high volume, inefficient invocations, or excessive inter-service traffic can produce unexpected charges.

Transactions deserve particular attention. A database transaction inside one function is relatively straightforward, but a workflow spanning a function, queue, payment provider, and email service cannot normally rely on one atomic transaction. It requires idempotency, retries, compensation, and durable workflow state.

2.4 Design practices

Good serverless design includes:

• keeping functions focused and independently testable;
• making event handlers idempotent;
• using dead-letter queues for repeatedly failing messages;
• externalizing configuration and secrets;
• setting explicit timeouts and concurrency limits;
• applying least-privilege identity policies;
• tracing requests across asynchronous boundaries; and
• testing provider failure and partial completion.

Idempotency means that processing the same logical request more than once produces the same intended business result. A payment operation, for example, should use a unique operation key so that a retry does not create duplicate charges.

3. Edge Computing

Edge computing moves computation, caching, or request processing closer to end users or data sources. An edge runtime may operate at a content-delivery location rather than in a central region. This can reduce network distance and improve responsiveness for suitable workloads.

Edge computing is useful for:

• request routing and personalization;
• authentication checks and rate limiting;
• content transformation;
• geographically distributed applications;
• Internet-of-Things data filtering; and
• low-latency user experiences.

Edge execution environments often have restricted runtimes, limited memory, short execution periods, and limited access to traditional operating-system features. A full Django deployment with a persistent relational database may therefore remain centralized, while selected functions such as caching, token validation, or request classification operate at the edge.

The central design challenge is data locality. If edge code must call a distant database for every request, much of its latency advantage disappears. Replication and local caching improve speed but create consistency questions. Strong consistency may be expensive or unavailable across regions, whereas eventual consistency may be acceptable for product catalogues but inappropriate for account balances.

A practical architecture often combines layers: a global edge layer for delivery and protection, regional application services for domain processing, and carefully controlled primary data stores for authoritative state.

4. API Styles: REST, GraphQL, and gRPC

4.1 REST

REST-style APIs commonly use HTTP methods, resource-oriented URLs, representations such as JSON, and standard response codes. They are widely understood and integrate well with browsers, proxies, caches, and external clients. Django REST Framework and Node.js frameworks such as Express or NestJS support this model.

REST is often appropriate for public APIs, CRUD-oriented services, and systems where broad interoperability is important. Its weaknesses can include over-fetching, under-fetching, inconsistent endpoint design, and documentation drift.

4.2 GraphQL

GraphQL exposes a typed schema through which clients specify the fields they require. A query might request a user, selected profile fields, and recent orders in one operation. This can reduce over-fetching and allow different clients to evolve independently.

GraphQL introduces responsibilities that do not disappear merely because the API has one endpoint:

• schema design and version evolution;
• authorization at field and object level;
• query depth, complexity, and rate controls;
• prevention of resolver-related N+1 database queries;
• caching strategy; and
• protection against expensive or recursive queries.

A common optimization is batching related data requests. In Node.js, a DataLoader-style mechanism can collect several resolver requests and issue one database query. Django implementations require similar attention to query planning and eager loading.

GraphQL is especially useful when multiple clients need different views of interconnected data. It is less attractive when simple resource operations, strong HTTP caching, or straightforward observability are primary requirements.

4.3 gRPC

gRPC is a remote procedure call framework commonly based on HTTP/2 and Protocol Buffers. A service contract defines methods and message types, and tools generate client and server code. Binary serialization is compact and strongly typed, while streaming supports continuous communication.

gRPC is well suited to internal service-to-service communication, high-throughput systems, and polyglot environments. Its limitations include more difficult browser integration, the need for generated tooling, and less familiar debugging for teams accustomed to JSON APIs. A common architecture exposes gRPC internally and a REST or GraphQL gateway externally.

4.4 Comparative view

The correct choice depends on client diversity, contract stability, performance, caching, observability, and organizational capability. Combining styles is legitimate when boundaries are explicit and translation is tested.

5. Platform Engineering and Internal Developer Platforms

Platform engineering treats the development platform as a product for internal users. A platform team provides reusable capabilities such as service templates, deployment pipelines, secrets integration, observability, database provisioning, and security controls.

The goal is not to hide all infrastructure from developers. It is to create a golden path: a well-supported route for common tasks that reduces cognitive load while preserving escape paths for unusual requirements.

An internal developer platform may include:

1. a source repository template;
2. automated testing and dependency scanning;
3. standard container or serverless deployment;
4. environment and configuration management;
5. dashboards, logs, and distributed tracing;
6. policy checks for identity and network access; and
7. documented ownership and support processes.

Platform engineering differs from simply creating a central operations team. It uses product thinking: developers are users, platform capabilities have service-level expectations, and feedback is measured. Useful indicators include deployment lead time, failure recovery time, adoption of secure defaults, platform satisfaction, and the frequency of work performed outside approved paths.

The risk is platform over-centralization. A platform that imposes unnecessary complexity becomes a bottleneck. Teams should therefore provide documented interfaces, self-service workflows, versioned templates, and transparent ownership.

6. Zero-Trust Backend Systems

Zero trust is a security model based on the assumption that no user, device, service, or network location is automatically trustworthy. Access is continuously evaluated using identity, device or workload context, resource sensitivity, and policy.

Its principles include:

• verify explicitly;
• apply least privilege;
• assume breach;
• segment systems and workloads;
• authenticate service-to-service calls; and
• record and analyze security-relevant activity.

Zero trust does not mean repeatedly asking human users for passwords. It means designing authorization so that network location alone is not evidence of legitimacy. A request from an internal subnet may still be malicious or compromised.

In Node.js and Django systems, implementation can include:

• short-lived access tokens and carefully validated claims;
• mutual TLS or workload identity for service communication;
• authorization checks at the domain boundary;
• separate identities for deployment, runtime, and administration;
• secrets stored in a managed vault rather than source code;
• database roles restricted to required operations; and
• administrative access protected by strong authentication and audit logging.

Authentication answers “Who or what is making the request?” Authorization answers “What is that identity allowed to do to this resource under these conditions?” Confusing the two is a common security defect.

7. Software Supply-Chain Security

A backend application depends not only on its own code but also on frameworks, packages, container images, build tools, operating-system components, and deployment actions. A vulnerability or compromise in any of these can affect the final system.

Supply-chain controls should cover the entire path from source to production:

1. Source integrity: protected branches, reviewed changes, signed commits where appropriate, and strong repository access controls.
2. Dependency governance: lockfiles, approved package sources, vulnerability scanning, update policies, and review of transitive dependencies.
3. Build integrity: isolated and reproducible builds, protected CI credentials, and minimal build permissions.
4. Artifact integrity: immutable artifact repositories, provenance records, signatures, and verification before deployment.
5. Deployment control: policy checks, separation of duties, rollback capability, and audit trails.
6. Runtime monitoring: detection of unexpected processes, network destinations, permissions, or package behavior.

Lockfiles improve reproducibility but do not prove that a package is safe. Vulnerability scanners also produce both false positives and false negatives. A mature process combines automated tools with risk-based human review.

A software bill of materials (SBOM) records the components included in an artifact. It supports vulnerability response and regulatory reporting, but its value depends on accuracy, freshness, and the organization’s ability to act on findings.

8. Sustainable Backend Computing

Sustainable computing considers energy use, carbon emissions, hardware life cycle, water consumption, and electronic waste. Backend decisions influence sustainability through compute intensity, storage volume, network traffic, redundancy, and hardware utilization.

Practical strategies include:

• reducing unnecessary data transfer and payload size;
• caching content when consistency permits;
• selecting efficient algorithms and database queries;
• scaling resources according to demand;
• shutting down non-production environments when idle;
• choosing efficient serialization and compression;
• extending hardware life where possible; and
• considering regional energy characteristics when selecting infrastructure.

A simplified operational view of energy is:

where E is energy in watt-hours, P is average power in watts, and t is operating time in hours. This relationship assumes power is reasonably constant over the interval. For variable power, energy is the integral of power over time, so the simple equation is an approximation.

Efficiency must be interpreted carefully. A faster system may consume more instantaneous power but less total energy if it completes work substantially sooner. Conversely, aggressive caching can reduce computation while increasing storage and invalidation complexity. Sustainability is therefore a systems optimization problem rather than a single metric.

9. AI-Assisted Development

AI-assisted development tools can generate code, tests, documentation, database queries, infrastructure configuration, and migration suggestions. They can help developers explore unfamiliar APIs and reduce repetitive work.

However, generated output is a proposal, not an authority. Common risks include:

• insecure authentication or authorization logic;
• hallucinated libraries and APIs;
• outdated framework assumptions;
• vulnerable dependency suggestions;
• leakage of proprietary code or personal data through prompts;
• licensing uncertainty; and
• tests that confirm implementation details without checking behavior.

A professional workflow treats AI output like code from an inexperienced contributor: review it, test it, scan it, and verify its assumptions. Human developers remain accountable for correctness, security, accessibility, and compliance.

Useful controls include approved tools, enterprise privacy settings, prohibition of secrets in prompts, code review, automated testing, static analysis, dependency scanning, and documentation of material AI assistance. Teams should also measure whether AI tools improve delivery quality rather than only increasing code volume.

10. Secure Integration of AI Services

10.1 Model APIs

A backend may call a hosted language, vision, speech, or embedding model through an API. The integration should be treated as an external service with uncertain availability, cost, output quality, and data-handling implications.

Important controls include:

• server-side storage of API credentials;
• strict input and output size limits;
• timeouts, retries, and circuit breakers;
• tenant isolation;
• structured output validation;
• filtering of sensitive information;
• logging that avoids unnecessary prompt retention; and
• quotas and budget alerts.

Model output must not automatically be treated as a trusted instruction. If output is used to construct SQL, HTML, shell commands, permissions, or financial actions, it must pass normal validation and authorization controls. Prompt injection can cause a model to follow malicious instructions embedded in retrieved documents or user input.

10.2 Retrieval-augmented generation and vector stores

Retrieval-augmented generation (RAG) combines a model with a search process. Documents are divided into chunks, transformed into embeddings, stored in a vector store, and retrieved when a user asks a question. Retrieved content is then included as context for generation.

A typical pipeline is:

1. collect and classify source documents;
2. remove or protect sensitive content;
3. divide documents into meaningful chunks;
4. generate embeddings using an approved model;
5. store vectors with tenant, permission, and provenance metadata;
6. retrieve candidate passages;
7. apply authorization filtering and, if needed, reranking;
8. generate a response constrained by the retrieved evidence; and
9. record evaluation data and operational metrics.

A vector similarity score is useful for ranking but is not an authorization decision. Every retrieved item must still be checked against the requesting user’s permissions. Metadata leakage can occur even when the generated answer appears harmless.

10.3 Privacy and data governance

Before sending data to an AI provider, an organization should determine:

• what data is collected;
• whether it contains personal, confidential, or regulated information;
• where processing occurs;
• how long prompts and outputs are retained;
• whether provider training uses the data;
• how deletion and access requests are handled; and
• whether cross-border transfer restrictions apply.

Data minimization is preferable to sending complete records. Pseudonymization can reduce exposure but does not guarantee anonymity, especially when auxiliary information permits re-identification. Privacy impact assessments and records of processing may be required depending on jurisdiction and context.

10.4 Evaluation

AI systems need evaluation beyond ordinary unit tests. Evaluation should reflect the intended use and include representative, difficult, and adversarial cases.

Relevant measures may include factual correctness, groundedness in retrieved sources, refusal of unauthorized requests, toxicity, latency, cost, and user satisfaction. For a classification task, a confusion matrix distinguishes true positives, false positives, true negatives, and false negatives. Accuracy alone can be misleading when classes are imbalanced.

Evaluation data must be governed carefully. Test prompts may contain sensitive information, and benchmark performance may not represent real users. Continuous monitoring is necessary because documents, models, user behavior, and threats change.

10.5 Responsible AI governance

Responsible governance assigns ownership and defines acceptable use. A practical governance process includes:

• use-case approval based on risk;
• documentation of purpose, data, model, limitations, and human oversight;
• security and privacy review;
• testing for bias and disparate impact where relevant;
• incident response and user appeal mechanisms;
• monitoring after deployment; and
• retirement criteria when performance or risk becomes unacceptable.

Human review is especially important for decisions affecting employment, education, credit, healthcare, legal status, safety, or access to essential services. Governance should not be limited to a policy document; it must appear in architecture, workflows, logs, and accountability structures.

11. Illustrative Case: A Secure Student Support Platform

Background

A university operates a Django-based student support portal. Students submit questions about enrolment, fees, and academic policies. The existing system uses a central application server and a manually maintained knowledge base.

Problem

During registration periods, traffic increases sharply. Students receive slow responses, support staff repeat answers, and some documents contain personal information that should not be exposed to every user. The university wishes to add an AI assistant without allowing it to make unauthorized decisions.

Analysis

A fully serverless rewrite would create unnecessary migration risk. The team identifies separate concerns: public content delivery, authenticated student queries, document retrieval, staff escalation, and authoritative account operations. Account changes must remain in existing transactional systems.

Approach

The team implements an edge cache for public policy pages and rate limiting. The Django application remains the system of record for identity, authorization, and support cases. A separate retrieval service indexes approved policy documents in a vector store. Each document chunk includes department, audience, version, and access metadata.

The AI service receives a minimized question and only passages that pass an authorization filter. It must cite source documents and respond that it cannot answer when evidence is insufficient. Its output is validated as structured data containing an answer, citations, confidence category, and escalation recommendation. It cannot directly update fees, enrolment status, or student records.

Node.js workers process document updates asynchronously. Queue messages contain identifiers rather than unnecessary personal data, and handlers are idempotent. CI pipelines generate an SBOM, scan dependencies, test authorization rules, and deploy signed artifacts. Observability records latency, retrieval failures, escalation rates, and model costs without retaining full sensitive conversations by default.

Outcome

The architecture improves peak-time responsiveness and reduces repetitive staff work while preserving human control over consequential actions. The university can replace the model or vector store without changing core student records. Periodic evaluations test outdated policies, malicious document instructions, cross-student data leakage, and unsupported questions.

Learning points

1. AI should be an additional capability, not an authority over protected records.
2. Retrieval permissions must be enforced before generation.
3. Edge, serverless, and conventional services can coexist when responsibilities are clear.
4. Security, privacy, cost, and sustainability must be designed together.
5. Evaluation and incident response continue after deployment.

12. Architectural Decision Framework

When selecting a contemporary backend approach, teams should ask:

• What latency and availability does the user require?
• Is the workload steady, bursty, asynchronous, or geographically distributed?
• Which state must be strongly consistent?
• Who owns identity, authorization, data, and operational response?
• What are the provider lock-in and exit costs?
• How will failures, retries, and partial completion be handled?
• Can the system be observed and tested at every boundary?
• What data may be sent to third parties?
• What are the security, regulatory, accessibility, and sustainability consequences?
• Is the team capable of operating the proposed design?

Architecture is a set of trade-offs, not a contest to use the newest technology. A simple, well-understood Django or Node.js service may be superior to a distributed platform when traffic, organizational scale, and risk do not justify additional complexity.

Challenges and Limitations

Contemporary backend development increases flexibility but also increases the number of interacting failure modes. Distributed systems make timing, retries, and consistency visible. Managed services reduce infrastructure work but create contractual and portability dependencies. GraphQL and AI systems provide expressive interfaces but require sophisticated authorization and abuse controls. Platform engineering can improve productivity but may become bureaucratic. Sustainability metrics can be difficult to compare because providers report energy and emissions differently.

Students and professionals should therefore resist technology determinism. No framework guarantees security, privacy, reliability, or responsible outcomes. These properties emerge from architecture, implementation, testing, operations, governance, and organizational behavior.

Best Practices Checklist

• Select architecture according to workload and risk, not novelty.
• Treat every external service as a dependency with failure and privacy implications.
• Make asynchronous operations idempotent and observable.
• Enforce authorization at domain and data boundaries.
• Use short-lived credentials, least privilege, and protected secrets.
• Maintain lockfiles, SBOMs, provenance, and controlled build pipelines.
• Minimize data collection, retention, and transfer.
• Validate all AI-generated content before using it operationally.
• Evaluate AI systems with realistic, adversarial, and privacy-safe data.
• Provide human oversight for high-impact decisions.
• Measure cost, performance, reliability, security, and sustainability together.

Chapter Summary

Contemporary backend development extends traditional application-server practices into serverless, edge, distributed API, platform, and AI-enabled environments. Serverless functions and managed services reduce infrastructure administration but require explicit handling of statelessness, retries, cold starts, and vendor dependence. Edge computing can reduce latency, although data locality and consistency remain central concerns.

REST, GraphQL, and gRPC represent different interface strategies. GraphQL provides client-controlled data selection but requires query governance and resolver optimization. gRPC offers strongly typed, efficient service communication, especially internally. Platform engineering creates reusable, secure developer pathways, while zero trust replaces implicit network trust with explicit identity, least privilege, segmentation, and continuous verification.

Supply-chain security covers source, dependencies, builds, artifacts, deployment, and runtime. Sustainable backend design considers energy, hardware, traffic, storage, and infrastructure utilization. AI-assisted development can increase productivity but requires human review, secure tooling, and testing. Secure AI integration requires protected credentials, data minimization, permission-aware retrieval, output validation, evaluation, monitoring, and responsible governance. The central professional skill is not adopting every new technology; it is making evidence-based architectural decisions that balance capability with security, reliability, privacy, cost, sustainability, and human accountability.

Key Terms

Serverless computing: A model in which infrastructure management is abstracted and execution is provisioned by a provider.

Function as a Service: Event-triggered execution of short-lived functions in a managed runtime.

Cold start: Initialization delay when a serverless runtime is started or resumed.

Edge computing: Processing or caching performed close to users or data sources.

GraphQL: A typed API query language and execution system in which clients request selected fields.

gRPC: A contract-driven remote procedure call framework commonly using HTTP/2 and Protocol Buffers.

Platform engineering: The practice of building and operating internal platforms for development teams.

Golden path: A supported, standardized route for completing common engineering tasks.

Zero trust: A security model that assumes no implicit trust based on network location.

Least privilege: Granting only the permissions required for an identity or process.

Software supply chain: The people, tools, code, dependencies, artifacts, and processes used to build and deliver software.

SBOM: A software bill of materials listing components contained in an artifact.

Sustainable computing: Designing and operating systems with attention to environmental impact and resource efficiency.

Model API: A network interface through which an application invokes an artificial-intelligence model.

Vector store: A system that stores embeddings and supports similarity-based retrieval.

Retrieval-augmented generation: A method that supplies retrieved external context to a generative model.

Prompt injection: Manipulation of model instructions through malicious or untrusted input.

Data minimization: Collecting, processing, or retaining only data necessary for a defined purpose.

Groundedness: The degree to which an AI response is supported by reliable supplied evidence.

Responsible AI governance: Policies, controls, accountability, and monitoring for safe and ethical AI use.

Review Questions

Short Answer Questions

1. What is the difference between serverless computing and the absence of servers?
2. Why can edge computing create data-consistency challenges?
3. State one strength and one limitation of GraphQL.
4. What does “assume breach” mean in a zero-trust architecture?
5. Why is an SBOM useful in software supply-chain security?

Long Answer Questions

1. Compare REST, GraphQL, and gRPC for a system serving a browser application, mobile clients, and internal services.
2. Explain how platform engineering can improve developer productivity without eliminating developer responsibility.
3. Describe a complete supply-chain security process from source commit to production deployment.
4. Discuss the privacy, security, and evaluation requirements of a retrieval-augmented generation system.
5. Evaluate the advantages and limitations of serverless and edge computing for a geographically distributed application.

Analytical / Application Questions

1. A payment workflow uses serverless functions, a queue, a payment provider, and an email service. Design an approach for idempotency, retries, compensation, and observability.
2. A vector store returns a document that is semantically relevant but belongs to another tenant. Explain where the architecture should block access and why similarity ranking is not sufficient.
3. A university wants an AI assistant to recommend support actions but not make decisions about student eligibility. Propose controls for authorization, human oversight, evaluation, logging, and incident response.

Multiple Choice Questions with Answers

Question 1

Which characteristic is most fundamental to a serverless function?

A. It must run continuously on a dedicated physical server.

B. It is commonly invoked by an event and should not depend on in-memory state persisting between invocations.

C. It cannot access managed databases.

D. It always has predictable zero-latency startup.

Correct Answer: B. It is commonly invoked by an event and should not depend on in-memory state persisting between invocations.

Question 2

Which workload is generally most suitable for edge computing?

A. A globally distributed request-routing or caching operation

B. A single authoritative accounting transaction requiring centralized serial ordering

C. A long-running batch job requiring unrestricted operating-system access

D. A database backup that must remain in one central region

Correct Answer: A. A globally distributed request-routing or caching operation

Question 3

What is a distinctive feature of GraphQL?

A. Clients select the fields they require from a typed schema.

B. It prohibits nested data relationships.

C. It requires Protocol Buffers for every response.

D. It eliminates the need for authorization.

Correct Answer: A. Clients select the fields they require from a typed schema.

Question 4

Why is gRPC often selected for internal service-to-service communication?

A. It provides strongly typed contracts and efficient binary serialization.

B. It is designed only for static web pages.

C. It does not require service definitions.

D. It guarantees that networks never fail.

Correct Answer: A. It provides strongly typed contracts and efficient binary serialization.

Question 5

Which statement best expresses a zero-trust principle?

A. All requests from an internal network are trusted.

B. Authentication is unnecessary after a user enters the corporate network.

C. Access is explicitly verified and limited according to identity and policy.

D. Only the public internet requires security controls.

Correct Answer: C. Access is explicitly verified and limited according to identity and policy.

Question 6

What is the primary purpose of a software bill of materials?

A. To list the components included in a software artifact

B. To replace all application testing

C. To increase the runtime memory of an application

D. To encrypt every user request

Correct Answer: A. To list the components included in a software artifact

Question 7

In a retrieval-augmented generation system, what must happen before retrieved content is supplied to a model?

A. Similarity ranking should automatically grant access.

B. The content should be checked against the requesting user’s authorization.

C. All metadata should be removed regardless of purpose.

D. The model should be allowed to execute document instructions.

Correct Answer: B. The content should be checked against the requesting user’s authorization.

Question 8

Which is an appropriate control when integrating a hosted model API?

A. Place the provider credential in browser-side JavaScript.

B. Allow unlimited prompt size and unrestricted spending.

C. Use server-side credential storage, limits, timeouts, and output validation.

D. Treat every model response as an authorized command.

Correct Answer: C. Use server-side credential storage, limits, timeouts, and output validation.

Question 9

Why can accuracy be misleading when evaluating an AI classifier?

A. Accuracy cannot be calculated for any classifier.

B. Class imbalance may allow a model to appear successful while performing poorly on a minority class.

C. Accuracy measures only network latency.

D. Accuracy automatically proves fairness.

Correct Answer: B. Class imbalance may allow a model to appear successful while performing poorly on a minority class.

Question 10

Which practice best supports sustainable backend computing?

A. Run all development environments continuously regardless of use.

B. Increase payload sizes to reduce the number of requests.

C. Reduce unnecessary computation and data transfer while matching resources to demand.

D. Treat energy consumption as unrelated to architecture.

Correct Answer: C. Reduce unnecessary computation and data transfer while matching resources to demand.