Free Apigee-API-Engineer Practice Test Questions and Answers (2026)

The security team's concern is about access control—specifically, that any internal service can call the backend APIs, not just the intended website. The current architecture bypasses any policy enforcement point. Recommending a design change to place an Apigee microgateway in front of the backend APIs directly solves this problem. The microgateway acts as a lightweight, containerized policy enforcement point for internal ("east-west") traffic. This allows the Apigee team to apply standard security policies like API key validation, OAuth, or IP-based access control, ensuring that only authorized clients (like the website) can access the backend services.

A. You should recommend an Apigee Edge Access Control policy: This policy would be ineffective because the question states the website calls the backend APIs directly, meaning traffic does not pass through the Apigee Edge gateway where policies are enforced.

B. You should recommend that the backend API's use TLS v12 to secure their APIs: TLS encrypts data in transit, protecting against eavesdropping. However, it does not solve the access control problem; an unauthorized internal client could still establish a valid TLS connection and call the API.

C. You should recommend the use of custom secure headers with time stamp verification: This creates a custom, non-standard security solution that is difficult to manage, scale, and audit. It is better to use a standard API management component like a microgateway for this purpose.

---

1. Google Cloud - Apigee Documentation

"About Apigee hybrid": This document explains the role of the hybrid runtime plane

which is based on a microgateway architecture. It states

"All API traffic passes through and is processed within the runtime plane... This allows you to leverage Apigee API management capabilities like security

traffic management

and analytics...". This supports using a microgateway as the policy enforcement point for API traffic.

Reference: Google Cloud Documentation > Apigee > Hybrid > gcp/apigee/hybrid/v1.8/about-hybrid

2. Google Cloud - Apigee Documentation

"Microgateway versus API proxy": This section clarifies the use case for a microgateway. It highlights that a key reason to use a microgateway is for "low latency for services that run in close proximity

" which is typical for internal traffic between a website's backend and other backend services within the same network or cloud environment.

Reference: Google Cloud Documentation > Apigee > Edge > private-cloud/v4.50.00/edge-microgateway-overview#microgatewayversusapiproxy

3. Google Cloud - Apigee Documentation

"Access Control policy": The documentation for this policy states

"The AccessControl policy lets you allow or deny access to your APIs by specific IP addresses." This confirms its function is access control

but its placement within an API proxy flow means it is only effective if traffic is routed through the Apigee gateway.

Reference: Google Cloud Documentation > Apigee > Edge > api-platform/reference/policies/access-control-policy

The Flow Callout policy is used to invoke a Shared Flow from within an API proxy or another Shared Flow. It can be attached to the PreFlow, PostFlow, or any conditional Flow within a ProxyEndpoint or TargetEndpoint. It can also be used inside one Shared Flow to call another, a practice known as "chaining." The only location where it cannot be used is the PostClientFlow, which executes after the response is sent to the client and has a restricted set of allowable policies that does not include Flow Callout.

C. Only in the Flow phase of ProxyEndpoint or TargetEndpoint: This is incorrect because a Flow Callout can also be used in the PreFlow and PostFlow phases, not just conditional Flows.

D. Anywhere except another Shared Flow: This is incorrect. The official documentation explicitly states that Shared Flows can be "chained" by using a Flow Callout policy within one Shared Flow to execute another.

E. Only in ProxyEndpoint PreFlow or TargetEndpoint PostFlow: This is too restrictive. A common use case is to place a Flow Callout within a conditional Flow to execute reusable logic for a specific API resource.

1. Google Cloud

Apigee Documentation

"Shared flows": "You can also chain shared flows together

that is

have a Flow Callout policy execute another shared flow." This supports answer B and refutes answer D.

2. Google Cloud

Apigee Documentation

"Flow Callout policy": "You can use a Flow Callout policy in a ProxyEndpoint or TargetEndpoint." This general statement supports its use in various flow locations.

3. Google Cloud

Apigee Documentation

"Configuring flows"

Section: PostClientFlow: This section lists the specific policies that can be attached to the PostClientFlow. The FlowCallout policy is not on this list

which includes AccessControl

KeyValueMapOperations

MessageLogging

ServiceCallout

and StatisticsCollector. This supports the exclusion mentioned in answer A.

In Apigee, to prevent sensitive data from being exposed in trace or debug sessions, you must assign it to a private variable. The private. prefix is a specific mechanism used to designate a variable as private. When a value is retrieved from an encrypted Key Value Map (KVM) using the KeyValueMapOperations policy and assigned to a variable with this prefix (e.g., private.mysecret), Apigee's trace tool will not capture or display its value. This is a critical security practice for handling credentials, tokens, or other confidential information.

A. encrypted: This term describes the state of the KVM itself, not a variable prefix used to hide data in a trace session.

B. mask: While related to the concept of data masking, private. is the specific, required prefix for the variable name to prevent its capture.

C. kvm: This is a common, conventional prefix for KVM-related variables but provides no inherent security or masking functionality in trace.

E. hidden: This is not a recognized or functional variable prefix within Apigee for masking data in trace sessions.

1. Google Cloud

Apigee Documentation

"KeyValueMapOperations policy": Under the section for the element

the documentation explicitly states: "To retrieve the value into a private variable that will not be visible in a Trace session

use the private. prefix on the variable name in the assignTo attribute."

2. Google Cloud

Apigee Documentation

"Working with key value maps": In the section "Retrieving values from a KVM

" the documentation notes the use of the private. prefix for sensitive data: "If the data is sensitive

use the private. prefix in the variable name... The private. prefix masks the variable in Trace and debug sessions."

Edge Microgateway-aware proxies are standard Apigee proxies that serve as a configuration source for a Microgateway instance. A key feature of Apigee proxies is the ability to use conditional flows to apply logic and policies to specific request paths, verbs, or other conditions. This feature is fully supported for microgateway-aware proxies. It allows developers to define granular enforcement rules, such as applying a stricter quota policy to a write operation (POST /resource) and a more lenient one to a read operation (GET /resource) within the same proxy, which Microgateway will then download and enforce locally.

A. Edge Microgateway-aware proxies must point to a Node js ScnptTarget

This is incorrect. Microgateway-aware proxies often have no target at all (a "no target" proxy) because their primary purpose is to bundle policies for Microgateway, not to route traffic.

B. Edge Microgateway-aware proxies should at least contain a quota or OAuth2 policy

This is not a requirement. A microgateway-aware proxy could validly contain only a Spike Arrest policy or just be used for API key validation without other specific policies.

D. Edge Microgateway-aware proxies must use HTTPTargetConnection in the TargetEndpoint

This is incorrect. As these proxies are not primarily for routing traffic to a backend, they typically do not use an HTTPTargetConnection. A "no target" configuration is common.

---

1. Google Cloud

Apigee Documentation

"Operations and flows": This document explicitly states

"You can attach policies to flows in the microgateway-aware proxy

giving you the ability to apply fine-grained policy enforcement on a per-resource basis." It provides a clear XML example of a conditional flow () being used in a microgateway-aware proxy. This directly supports option C.

2. Google Cloud

Apigee Documentation

"Set up and configure Edge Microgateway"

Step 3: Create a microgateway-aware proxy: This tutorial section notes

"The proxy can be a simple 'no target' proxy... The proxy's TargetEndpoint must be configured with a element

but it does not have to resolve to a real target..." This confirms that a specific

functional HTTPTargetConnection or ScriptTarget is not required

invalidating options A and D.

3. Google Cloud

Apigee Documentation

"What is Edge Microgateway?": Under the section "What policies are enforced by Edge Microgateway?"

the documentation lists Spike Arrest

Quota

OAuth v2

and Verify API Key. It does not state that a proxy must contain a Quota or OAuth2 policy

invalidating the strict requirement implied in option B.

Apigee provides two primary techniques for dynamically selecting a target endpoint at runtime. The first is a declarative approach using conditional RouteRules within the ProxyEndpoint. Apigee evaluates these rules sequentially, and the first rule whose condition evaluates to true directs the flow to the specified TargetEndpoint. The second is a programmatic approach, typically using a JavaScript policy. This policy can execute code to determine the appropriate target URL and then dynamically set the target.url flow variable, which overrides the statically configured URL in the TargetEndpoint definition.

A: "Routing tables" is not a standard Apigee configuration object. While you use the Management API to configure RouteRules, the API itself is a configuration tool, not the runtime mechanism that makes the dynamic choice.

D: By default, an API proxy has a static route to a single, pre-configured target endpoint. Dynamic routing requires explicit configuration and is not a default behavior.

1. Google Cloud Apigee Documentation

"Conditional routing": This document explicitly describes the use of RouteRule elements with conditions to achieve dynamic routing. It states

"You can add routing logic to your API proxy flow by adding conditional routes to your TargetEndpoint configuration... A RouteRule forwards a request to a particular TargetEndpoint if the condition in the route rule evaluates to true." (See the section on "Conditional routes").

2. Google Cloud Apigee Documentation

"Flow variables reference": The documentation for the target.url variable states

"In a JavaScript policy

you can read and set this variable." This confirms that scripts can programmatically alter the target URL at runtime.

3. Google Cloud Apigee Documentation

"Route requests to the proper backend server": This guide provides a clear example of dynamic routing. Under the section "Dynamically routing to a target with a script

" it demonstrates using a JavaScript policy to set the target.url variable. It states

"You can dynamically set a target URL with code... the script overrides the static URL... configured in the TargetEndpoint XML block."

The most appropriate and standard method in Apigee to implement a hot-warm (active-passive) failover is by using the built-in load balancing capabilities of the TargetEndpoint. This involves defining each datacenter endpoint as a TargetServer. Within the TargetEndpoint's LoadBalancer configuration, the warm datacenter's TargetServer is marked with the true property. Apigee will then direct all traffic to the primary (hot) server(s). If the health monitor detects that all primary servers are unavailable, Apigee automatically fails over and routes traffic to the designated fallback (warm) server. This declarative approach is the intended design pattern for this scenario.

A. Using a Java Callout is an overly complex, imperative approach that bypasses Apigee's built-in, optimized routing features, making the proxy harder to maintain and less performant.

B. A FaultRule's primary purpose is to catch errors and return a customized error response to the client, not to re-route the original request to a different backend.

C. Service Callouts are designed for invoking external services from within a proxy flow (e.g., for enrichment), not for handling the primary target request and its failover logic.

1. Google Cloud

Apigee Documentation

"Load balancing across backend servers": This official documentation explicitly describes the use of fallback servers for failover scenarios. In the section "Configuring fallback servers

" it states

"When Apigee determines that all your primary servers are unavailable

it automatically routes all traffic to your fallback servers...". The provided XML configuration example clearly shows the use of the true element within a definition to designate a server for failover.

Reference Location: Google Cloud > Apigee > Documentation > Reference > API proxy configuration reference > Endpoint properties reference > Load balancing across backend servers.

2. Google Cloud

Apigee Documentation

"TargetEndpoint configuration": This document details the structure of a TargetEndpoint. The element is shown as a child of

and it supports one or more elements. This confirms that load balancing and server definition are integral parts of the TargetEndpoint configuration

which is the correct place to manage backend routing and failover.

Reference Location: Google Cloud > Apigee > Documentation > Reference > API proxy configuration reference > Endpoint properties reference > TargetEndpoint configuration.

The Apigee ExtractVariables policy uses JSONPath to extract data from a message payload that is in JSON format. For Apigee's parser to correctly interpret the message body as JSON, the Content-Type header of that message (either the request or response) must be explicitly set to application/json. If the header is missing, incorrect, or set to another value (e.g., text/plain), the policy will not treat the payload as a JSON object. Consequently, the JSONPath expression will fail to find any matching paths, resulting in the query not returning the expected value.

A. The Accept header indicates the media types the client can process in a response; it does not describe the format of the current payload being parsed.

B. The Accept header is irrelevant for parsing the current message's payload. It is a client-side header used for content negotiation for the response.

C. While Content-Type is the correct header, text/json is an obsolete and non-standard media type. The official standard specified by IETF RFC 8259 is application/json.

1. Google Cloud Apigee Documentation

"Extract Variables policy": Under the element description

the documentation states: "The message must be parsed as JSON by Apigee. If the message is not valid JSON

or if the message is not parsed as JSON for other reasons (such as the Content-type header not being application/json)

the policy will not be able to extract any variables." This directly confirms that the Content-Type header must be application/json.

Source: Google Cloud Documentation > Apigee > Reference > Policies > Extract Variables policy reference.

2. IETF RFC 8259

"The JavaScript Object Notation (JSON) Data Interchange Format": This official standard defines the media type for JSON.

Section 11

"IANA Considerations": "The MIME media type for JSON text is application/json." This establishes application/json as the correct and standard value.

A data dictionary serves as a centralized, authoritative source of truth for data definitions, including field names, data types, and business rules. Creating a data dictionary directly addresses the root cause of confusion by establishing a clear, consistent, and shared understanding of data elements across the project. This is a foundational practice in data governance and API design that scales effectively as the project grows. It provides the standard against which developers can code and reviewers can validate, ensuring clarity and consistency in the API contract and its implementation.

A. A static code analysis tool is for enforcing a convention, not for creating it. The rules and definitions must be established first, which is the purpose of a data dictionary.

B. Relying solely on code reviews is inefficient and subjective without a documented standard. Reviewers may have different interpretations, failing to solve the core consistency problem.

D. Creating a unified data model for all possible use cases is often an overly complex and rigid approach that can lead to "analysis paralysis" and hinder agile development.

1. Google Cloud - API design guide (AIP-140): This guide emphasizes the critical importance of consistent and predictable naming conventions for API fields. It states

"Field names should be snakecase... By using consistent field names

users who are familiar with one part of the API can more easily understand other parts of the API." A data dictionary is the formal mechanism for defining and documenting these conventions.

Source: Google Cloud

API design guide

AIP-140 Field names.

2. Apigee Documentation - API-first approach: The API-first philosophy

central to Apigee's methodology

prioritizes designing a clear and stable API contract before writing code. A data dictionary is a key artifact in this design phase

ensuring all stakeholders agree on the data model and its naming.

Source: Apigee Docs

"Develop an API-first strategy".

3. University Courseware - Database Design: Foundational computer science and database design principles teach that a data dictionary is the central repository of metadata about the database. It contains the "data about the data

" including names

definitions

and data types

to prevent ambiguity and ensure consistency.

Source: Stanford University

CS 145: Introduction to Databases

Course Notes on Data Dictionaries.

The recommended solution is to use a TargetServer configuration. TargetServers are environment-scoped objects in Apigee that decouple the concrete backend endpoint URLs from the API proxy's TargetEndpoint definition. You can define a TargetServer with the same name (e.g., 'backend-service') in each environment (dev, test, prod), but with a different host/IP address for each. The API proxy then references this named TargetServer. When the proxy is deployed to an environment, it resolves to the backend configured for that specific environment, allowing the same proxy bundle to be promoted without modification.

A. Java/JavaScript/Python callout: This is not recommended as it adds unnecessary code complexity and mixes configuration with runtime logic, making the proxy harder to maintain.

B. TargetEndpoint configuration: Hardcoding a URL directly in the TargetEndpoint is bad practice because it requires changing the proxy bundle for each environment.

C. RouteRules: RouteRules are used for conditional routing based on request characteristics (e.g., path, headers), not for managing environment-specific backend endpoints.

1. Google Cloud Apigee Documentation

"Load balancing across backend servers": This document explicitly states

"A TargetServer decouples concrete endpoint URLs from TargetEndpoint configurations. Instead of defining a concrete URL in your configuration

you can configure one or more named TargetServers... The TargetServer definition itself is stored in the environment..." This directly supports using TargetServer for environment-specific backends.

2. Google Cloud Apigee Documentation

"TargetEndpoint configuration reference": Under the element section

the documentation shows how to use to reference a TargetServer by name ()

which is the mechanism for implementing this pattern. It contrasts this with using a direct .

3. Google Cloud Apigee Documentation

"About environments and environment groups": This document clarifies that an environment is a "runtime execution context for the API proxies" and that certain configurations

like TargetServers and Key Value Maps (KVMs)

are scoped to these environments. This reinforces that TargetServer is the correct construct for environment-specific configurations.

The XMLToJSON policy is the most appropriate choice for converting a SOAP response to a JSON response. SOAP (Simple Object Access Protocol) messages are fundamentally structured in XML format. The XMLToJSON policy is specifically designed to parse an XML payload, such as a SOAP message body, and transform it into a corresponding JSON structure. This policy provides various options to control the conversion process, handling XML elements, attributes, and text content to produce a well-formed JSON output, making it the best tool for this specific task.

A. AssignMessage: This policy creates or modifies messages but does not have built-in logic for format transformation between XML and JSON.

B. Message Validation: This policy is used to validate message formats against a schema (e.g., XSD or JSON Schema), not to convert them.

C. SOAPToJSON: This is not a standard, existing policy type within the Google Apigee platform; it is a plausible but incorrect distractor.

1. Google Cloud Apigee Documentation

"XML to JSON policy": "The XMLtoJSON policy lets you convert messages from the Extensible Markup Language (XML) format to JavaScript Object Notation (JSON)." This directly confirms that XMLToJSON is the correct policy for converting XML-based messages like SOAP into JSON.

Source: Google Cloud

Apigee Documentation

Policy reference

XML to JSON policy.

2. Google Cloud Apigee Documentation

"Assign Message policy": "The AssignMessage policy changes or creates new request and response messages during an API proxy flow. It lets you perform...Set the payload of a message." While it can set a payload

it does not perform the complex logic of format conversion itself.

Source: Google Cloud

Apigee Documentation

Policy reference

Assign Message policy.

3. Google Cloud Apigee Documentation

"Message Validation policy": "The MessageValidation policy validates a request or response message against a defined schema...For XML messages

Apigee uses the XML Schema Definition (XSD)." This clearly defines its purpose as validation

not transformation.

Source: Google Cloud

Apigee Documentation

Policy reference

Message Validation policy.

4. Google Cloud Apigee Documentation

"Policy reference overview": A review of the complete list of available policies in the official Apigee documentation confirms that a policy named SOAPToJSON does not exist.

Source: Google Cloud

Apigee Documentation

Policy reference overview.

An OAuth 2.0 refresh token is a credential used to obtain new access tokens. Its primary purpose, as defined in the OAuth 2.0 framework, is to allow a client application to get a new access token when the current one expires, without requiring the end-user to re-authenticate. Depending on the authorization server's policy, a refresh token may be long-lived and reusable multiple times. However, for enhanced security, a server may also implement refresh token rotation, where a new refresh token is issued each time one is used.

B. The issuance of a refresh token is optional and depends on the grant type and authorization server configuration; for example, the Implicit grant type does not include a refresh token.

C. Refresh tokens are used exclusively for obtaining new access tokens; they are not involved in the process of resetting a user's primary credentials, such as their password.

1. Internet Engineering Task Force (IETF) RFC 6749

The OAuth 2.0 Authorization Framework.

Section 1.5

"Refresh Token": "Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires..." This directly supports option A.

Section 6

"Refreshing an Access Token": "The authorization server MAY issue a new refresh token

in which case the client MUST discard the old refresh token and replace it with the new refresh token." The use of "MAY" indicates that a new token is not always issued

implying the original can be reused if a new one is not provided. This supports option D.

Section 4.2.2

"Access Token Response" (Implicit Grant): "A refresh token SHOULD NOT be included." This directly refutes the claim in option B that a refresh token is always issued.

2. Google Cloud

Apigee Documentation

"OAuthV2 policy".

"Generating an access token" section: The documentation describes the element within the GenerateAccessToken block. This element's existence as a configurable option demonstrates that issuing a refresh token is a deliberate policy choice and not an automatic action for every access token generation

which refutes option B.

Apigee Edge already organizes system-defined variables into logical “namespaces” (request., response., oauth., etc.) separated by a period.

The same convention is recommended for any custom variables you create: choose a unique prefix (for example, mycompany.order.) and use “.” to subdivide it.

This immediately groups related variables, avoids naming collisions, and makes large proxies easier to read in the Trace UI or policy condition syntax.

Changing the letter-case of names or hand-maintaining a dictionary does not address collision/readability inside the execution context, and proxy chaining modularizes logic, not the variable set within a single proxy.

B. External documentation helps humans but does not reduce in-proxy naming clutter or collision risk.

C. camelCase vs snakecase is stylistic; it neither namespaces nor reduces the total number of identifiers.

D. FlowCallout/proxy chaining splits logic across proxies but each proxy can still have many variables; it does not solve naming organization within one proxy’s scope.

1. Google Cloud (Apigee) Documentation – “Working with variables”

section “Variable naming conventions” & “Custom variable namespaces”

https://cloud.google.com/apigee/docs/api-platform/reference/variables (see “Use dotted notation to create your own variable namespace”).

2. Google Cloud (Apigee) Best Practices – “Designing readable

maintainable proxies”

subsection “Namespace your custom variables to avoid conflicts”

2021-11-10 edition.

3. Google Cloud (Apigee) “Trace tool guide”

page “Filtering by variable namespace” (demonstrates why dot-separated namespaces aid debugging).

Apigee's API design best practices advocate for URI path versioning as the most straightforward and common approach. Placing the major version indicator at the beginning of the URL path (e.g., /v1) makes the API version explicit and unambiguous for consumers. This method simplifies routing logic within the Apigee gateway, as different versions can be directed to different API proxies or target endpoints based on the base path. It also ensures that URIs for specific resources remain unique across versions, which benefits caching and browser history.

A. GET /customers/{customend}/v1: Placing the version at the end of the path is unconventional and breaks the hierarchical structure of a RESTful URI, making it less intuitive.

B. GET /customers/v1/{customerid}: Inserting the version in the middle of the resource path is not a standard practice and can complicate parsing and routing rules within the API proxy.

D. GET /customers?customend={customerid}&version=v1: While versioning via a query parameter is a valid technique, it is not the primary method recommended by Apigee. It can complicate caching, as some caches ignore query parameters, and makes routing within the proxy less direct than path-based routing.

1. Apigee

"Web API Design: The Missing Link" Ebook: In the chapter on "Versioning

" the guide states

"The most straightforward approach to versioning is to include the version number in the URI path... This is the most common approach..." It provides the example http://api.example.com/v1/users

which directly supports the structure in option C.

2. Google Cloud Apigee Documentation

"Create an API proxy": In the tutorial for creating a new proxy

the example base path provided is /v1/weather. This demonstrates the recommended practice of including the version as the first segment of the URI path for clear identification and routing. (See the "Configure the proxy" section of the tutorial).

3. Google Cloud Apigee Documentation

"API proxy development overview": This document explains how the proxy.basepath flow variable is populated from the incoming request URL. Using a base path like /v1/customers allows for easy implementation of conditional flows based on the API version

which is a core Apigee development pattern.

Security Assertion Markup Language (SAML) 2.0 assertions inherently support a limited lifetime and are self-verifiable. The lifetime is enforced by the element, which specifies NotBefore and NotOnOrAfter timestamps, defining the assertion's validity period. The self-verifiable nature comes from the use of XML Signature. The identity provider (issuer) digitally signs the assertion, and the service provider (recipient) can independently verify its authenticity and integrity using the issuer's public key without needing to contact the issuer directly for verification.

B. Managed key rotation: This is a critical operational security practice for systems using SAML, but it is not a feature defined or managed by the SAML 2.0 protocol itself.

D. Compact data representation: SAML assertions use XML, which is known for being verbose. This contrasts with more compact formats like JSON, which is used by JWTs.

E. Refresh without a new challenge: This is a core feature of the OAuth 2.0 framework, which uses refresh tokens to obtain new access tokens. SAML does not have a native concept of refresh tokens.

1. Google Cloud Apigee Documentation

"Validate SAML Assertion policy": This document describes the policy's function

stating

"The policy validates that the assertion has not expired" (supporting limited lifetime) and "The policy validates the digital signature in the assertion" (supporting self-verifiable content).

Source: Google Cloud Apigee Documentation

policies/validate-saml-assertion-policy.html.

2. OASIS Security Services Technical Committee

"Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0"

March 2005:

Section 2.5.1

"Element ": This section defines the NotBefore and NotOnOrAfter attributes that "specify the time interval during which the assertion is valid." This directly supports the "Limited token lifetime" requirement.

Section 5

"SAML Profiles of XML Signature": This section details how SAML assertions MUST be digitally signed for many profiles

making them verifiable by the recipient. This supports the "Self-verifiable content" requirement.

Source: OASIS Standard

saml-core-2.0-os.pdf.

3. Google Cloud Apigee Documentation

"Securing APIs with SAML": This guide explains the flow where Apigee validates an incoming SAML assertion. It notes

"Apigee acts as a service provider (SP)... It extracts a digitally signed SAML assertion... and validates the assertion." This confirms the standard use of verifiable signatures.

Source: Google Cloud Apigee Documentation

api-platform/security/securing-apis-saml.html.

The PopulateCache policy is a general-purpose caching policy used to write the value of any flow variable, which is treated as a string, into the cache. This makes it highly flexible for caching arbitrary data within an API proxy flow.

The ResponseCache policy is a specialized policy designed for performance optimization. It automatically caches the entire HTTP response message from a target, including the status code, headers, and body. When a subsequent identical request is received, Apigee serves the response directly from the cache, avoiding a round trip to the backend.

A. The element in the PopulateCache policy supports TimeoutInSec, TimeOfDay, and ExpiryDate, but not a TimeOfYear option.

C. The ResponseCache policy is a single, unified policy that handles both cache lookups and population. In contrast, general-purpose caching uses separate policies: LookupCache, PopulateCache, and InvalidateCache.

1. Google Cloud Apigee Documentation

"PopulateCache policy":

Regarding option B: The documentation for the element states

"The variable whose value will be written to the cache." This confirms it caches the content of a variable

which is treated as a string.

Regarding option A: The documentation for the element lists only ExpiryDate

TimeOfDay

and TimeoutInSec as valid child elements for controlling cache entry expiration.

2. Google Cloud Apigee Documentation

"ResponseCache policy":

Regarding option D: The overview section explicitly states

"The ResponseCache policy caches the full response from a backend target

including headers

and status code."

Regarding option C: The documentation presents the ResponseCache policy as a single configuration. The section "Element reference" shows a single element that contains all configuration for both lookup and population logic

contrasting with the separate policies used for general-purpose caching.

Apigee evaluates RouteRules within a ProxyEndpoint sequentially from top to bottom. The first RouteRule whose condition evaluates to true is executed, and all subsequent RouteRules are ignored for that transaction. The issue described occurs when a more general RouteRule is placed before a more specific one. If an incoming request matches the conditions of both, the general rule will be executed first, preventing the proxy from ever evaluating the intended specific rule. Reordering the rules to place the most specific conditions first ensures they are evaluated and executed correctly.

A. Modify the RouteRules to be more specific.

This is incorrect because the problem is not the specificity of the rule itself, but its position in the evaluation order. A matching rule already exists.

B. Create a new proxy for this special condition.

This is an inefficient solution and an anti-pattern. RouteRules are designed specifically to handle conditional routing within a single API proxy.

D. Add a new TargetServer to handle your specific condition.

This is incorrect because a TargetServer defines a backend instance. The problem lies in the routing logic (RouteRule) that selects a TargetEndpoint, not the backend server configuration itself.

1. Google Cloud Apigee Documentation

"Conditional routing":

Under the section "Conditional routing

" the documentation states: "Apigee evaluates the conditions in the order they are defined in the ProxyEndpoint configuration. The first route whose condition evaluates to true is executed." This directly supports the explanation that order matters and the first match wins.

2. Google Cloud Apigee Documentation

"API proxy configuration reference":

In the section describing the ProxyEndpoint configuration

the RouteRule element is detailed. The documentation on processing multiple rules implicitly confirms their sequential evaluation. The examples show a default (no-condition) rule placed last

which is best practice

reinforcing the concept of ordered evaluation where specific rules must come before general or default rules.

Two-way TLS, or mutual TLS (mTLS), enhances the security of a connection by requiring both the client and the server to prove their identities to each other using digital certificates. In the context of an Apigee target endpoint connection, Apigee acts as the client and the backend service is the server. With mTLS, Apigee verifies the backend's certificate, and the backend service verifies Apigee's certificate. This mutual authentication ensures that both parties are trusted before any data is exchanged, preventing unauthorized systems from connecting to the backend and protecting Apigee from man-in-the-middle attacks.

A. Sensitive data presented to end users will be encrypted

This is incorrect because mTLS on the target endpoint (southbound) connection encrypts data between Apigee and the backend, not directly for the end user.

C. End users can use the name of the system to verify that they are connecting to a trusted system.

This describes a benefit of standard one-way TLS on the client-to-Apigee (northbound) connection, not mutual TLS on the Apigee-to-target (southbound) connection.

D. All of the above

This is incorrect because options A and C are not benefits of mTLS for target endpoint connections.

---

1. Google Cloud Apigee Documentation

"Configuring TLS from Edge to the backend (Cloud and Private Cloud)": This document explicitly describes the process of mutual authentication. It states

"In two-way TLS

in addition to the server-side TLS authentication

the client also presents its certificate to the server for authentication... Two-way TLS is also called mutual TLS." This directly supports that both Apigee (as the client) and the target endpoint (the server) verify each other's identity.

2. Google Cloud Apigee Documentation

"About TLS/SSL": In the section "About two-way TLS/SSL

" the documentation clarifies the process: "For two-way TLS

the process is the same [as one-way TLS] except that the client also sends its certificate to the server for the server to verify." This confirms that the identity verification is mutual

involving both parties.

According to Apigee and Google's API design best practices, consistency is a foundational principle for creating a usable and predictable API. While the initial choice of a name is important for intuitiveness, the most critical practice is to apply that name consistently across the entire API surface. An inconsistent API (e.g., using customerId, customerid, and custID for the same concept in different places) increases the cognitive load on developers and leads to errors. Therefore, establishing a naming convention and adhering to it rigorously is paramount.

A. Allow each developer to make their own choice.

This approach leads directly to inconsistency, making the API difficult to learn, use, and maintain. It is a recognized anti-pattern in API design.

B. Use the same field name as in the back end system.

This practice tightly couples the API to the backend implementation, exposing internal details that may be cryptic or irrelevant to the consumer and hindering future backend refactoring.

C. Survey typical consumers to determine which common name to use.

While designing for the consumer is a key principle and surveying is a good method to achieve intuitiveness, consistency is a more fundamental and non-negotiable rule. An API must be consistent, even if user surveys are not conducted.

1. Google Cloud API Design Guide

Naming Conventions: This guide

which informs Apigee's philosophy

states

"To provide a consistent developer experience across a large number of APIs and over a long period of time

all names used by an API should be: simple

intuitive

consistent." It further emphasizes

"Within a given API

names must be used consistently." This highlights consistency as a mandatory rule.

Source: Google Cloud. (n.d.). API Design Guide: Naming Conventions. Retrieved from https://cloud.google.com/apis/design/namingconvention

2. Apigee

Web API Design: The Missing Link (e-book): This official Apigee publication lists "Strive for Consistency" as a core design principle. It explains

"Consistency in your API design will make it easier for developers to learn and use. ... Be consistent in your use of name casing (camelCase or underscores)." This directly supports the mandate for consistency presented in the correct answer.

Source: Marsh

D. (2016). Web API Design: The Missing Link. Apigee. (Specifically

the chapter on "Design Principles").

3. Stanford University

CS193P - Developing Apps for iOS: Course materials on API design frequently emphasize the "Principle of Least Astonishment

" where consistency is a key component. An API should not have surprising or unpredictable behavior

which includes consistent naming for similar concepts.

Source: Stanford University. (2021). CS193p - Developing Apps for iOS. Lecture materials on API Design. (General principle taught in software engineering and API design modules).

A backlog grooming (or backlog refinement) session is a recurring meeting in Agile development methodologies like Scrum. Its primary purpose is for the development team and the product owner to review, discuss, and refine items in the product backlog. This involves clarifying requirements, breaking down large user stories (Epics) into smaller, more manageable stories, estimating the effort required (e.g., using story points), and ensuring that items at the top of the backlog are well-understood and ready for an upcoming sprint. The focus is on the detailed preparation of user stories and their associated tasks.

A. Review the Epics and meet the cross functional team: While reviewing Epics can be part of grooming, the focus is on breaking them down into ready user stories. Meeting the team is typically a kickoff activity, not a recurring grooming task.

C. Review the high level design document and ask questions: A high-level design document is an input to the backlog grooming process, providing context. The session's activity is not to review the document itself, but to refine the backlog items (user stories) derived from it.

D. Update support tickets that have been sitting for x number of days: This describes a support or operations-focused task. While bugs from support tickets may become backlog items, the grooming session is for planning future development, not managing active support queues.

---

1. Bjarnason

E.

Wnuk

K.

& Regnell

B. (2011). A case study on challenges in creating shared understanding in large-scale requirements engineering. Information and Software Technology

53(7)

675-690. In section 4.2

"Product backlog grooming

" the authors describe the activity: "The product backlog grooming meetings were used to discuss

estimate

and break down requirements into smaller pieces." This directly supports the activities mentioned in option B.

(DOI: https://doi.org/10.1016/j.infsof.2010.09.006)

2. Lucassen

G.

Lammers

T.

& van der Werf

J. M. E. (2016). The use and effectiveness of user stories and a-priori mock-ups in practice. 2016 IEEE 24th International Requirements Engineering Conference (RE)

174-183. The paper discusses backlog refinement as a key practice where user stories are detailed: "During backlog refinement sessions

the product owner and development team discuss user stories to clarify and estimate them." This aligns with the detailed review and update of user stories.

(DOI: https://doi.org/10.1109/RE.2016.29)

3. University of California

Berkeley. (n.d.). CS 169A

Software Engineering

Lecture 4: Agile/Scrum/XP. Courseware. The lecture slides describe the Product Backlog Refinement process as including activities such as "adding detail

estimates

and order to items in the Product Backlog." This directly corresponds to reviewing and updating user stories in detail.

The OpenAPI Specification (OAS) 2.0 defines a root document structure called the Swagger Object. This object has several properties, but only three are mandatory for a specification to be valid. These are swagger, which specifies the OAS version (must be "2.0"); info, which provides metadata about the API; and paths, which defines the available API endpoints and their operations. All other top-level properties listed in the options are optional and provide additional context like the host, base path, or default MIME types.

B. host: This is an optional property that specifies the host (name or IP) serving the API. If omitted, the host is assumed to be the same as where the spec is served.

D. license: The license object is an optional field within the required info object, not a required top-level property of the Swagger Object itself.

F. basePath: This is an optional property that defines the base path relative to the host. If not provided, it defaults to /.

G. produces: This is an optional property that declares a global list of MIME types the API can produce. It can be overridden at the operation level.

H. consumes: This is an optional property that declares a global list of MIME types the API can consume. It can be overridden at the operation level.

1. OpenAPI Initiative

OpenAPI Specification v2.0: The official specification explicitly lists the required fields for the root "Swagger Object". The table in this section indicates that swagger

info

and paths are required.

Source: OpenAPI Specification v2.0

Section: "Swagger Object"

Link: https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#swagger-object

2. Google Cloud

Apigee Documentation: Google's documentation on the fundamentals of the OpenAPI specification provides a minimal example that demonstrates the required structure

including only the swagger

info

and paths top-level properties.

Source: Google Cloud Apigee Docs

"What is an OpenAPI specification?"

Link: https://cloud.google.com/apigee/docs/api-platform/fundamentals/what-openapi-specification#a-minimal-openapi-specification