Apigee Interview Question: What Is the Access Control Policy in Apigee? (With XML Example)

The Access Control policy is a security policy in Apigee that allows or denies API requests based on IP addresses. It helps API developers restrict access to trusted networks, block unwanted IP addresses, and add an extra layer of security to API proxies.

In this article, we will cover how the Access Control policy works, how to configure it using XML, how IP masks work, and how to use it in a real-world payment API scenario.

1. What Is the Access Control Policy in Apigee?

The Access Control policy allows you to control which client IP addresses can access your APIs.

It supports two main actions:

• ALLOW: Permits requests from matching IP addresses to continue through the API proxy.
• DENY: Blocks requests from matching IP addresses.

For example, imagine you have a Payment API that should only be accessible from your company's trusted network. You can configure an Access Control policy to allow requests from that network and deny requests from other IP addresses.

The policy can be attached at different points in the API proxy flow, but it is commonly placed in the ProxyEndpoint request PreFlow so that IP restrictions are evaluated early.

2. How Does the Access Control Policy Work?

The request flow is straightforward:

1. A client sends a request to the Apigee API proxy.
2. The Access Control policy evaluates the relevant client IP address against the configured rules.
3. If a rule matches, Apigee applies its ALLOW or DENY action.
4. If no rule matches, Apigee applies the configured noRuleMatchAction.

For example, if only a trusted corporate network is allowed, requests from that network can proceed while requests from other networks are denied.

3. Access Control Policy XML Example

Suppose we want to allow requests only from the 192.168.1.10 IP address and deny all other IP addresses.

We can configure the policy as follows:

<AccessControl name="AC-AllowTrustedIPs">
    <IPRules noRuleMatchAction="DENY">
        <MatchRule action="ALLOW">
            <SourceAddress mask="32">
                192.168.1.10
            </SourceAddress>
        </MatchRule>
    </IPRules>
</AccessControl>

Explanation of the configuration

AccessControl

Defines the policy and its name.

IPRules

Contains the IP matching rules and specifies what to do when no rule matches.

noRuleMatchAction="DENY"

Denies requests that do not match an explicit rule.

MatchRule action="ALLOW"

Allows requests matching the specified IP address.

SourceAddress mask="32"

Matches one specific IPv4 address.

With this configuration, requests from 192.168.1.10 are allowed, and requests from other IP addresses are denied.

Note: The IP address above is an illustrative example. Use the actual client IP addresses and network ranges from your environment.

4. How Do You Deny a Specific IP Address?

Suppose you want to block requests from 198.51.100.10 but allow requests from all other IP addresses.

<AccessControl name="AC-BlockUntrustedIP">
    <IPRules noRuleMatchAction="ALLOW">
        <MatchRule action="DENY">
            <SourceAddress mask="32">
                198.51.100.10
            </SourceAddress>
        </MatchRule>
    </IPRules>
</AccessControl>

Here, the policy denies requests from 198.51.100.10. Since noRuleMatchAction is set to ALLOW, requests from other IP addresses are allowed by this policy.

This configuration is useful when you need to block a known unwanted IP address without restricting all other clients.

5. What Is the Difference Between mask="32" and mask="24"?

The mask attribute determines the IP address range that the policy matches.

Mask	Example	Meaning
32	192.168.1.10	One specific IPv4 address
24	192.168.1.10	The 192.168.1.0/24 network
16	192.168.1.10	The 192.168.0.0/16 network

For example:

<SourceAddress mask="24">192.168.1.10</SourceAddress>

This matches addresses in the 192.168.1.* range, not just 192.168.1.10.

Interview tip: A mask of 32 represents a single IPv4 address, while a mask of 24 represents a subnet containing 256 IPv4 addresses.

6. Where Should You Attach the Access Control Policy?

A common approach is to attach the policy to the ProxyEndpoint request PreFlow.

Why?

• It evaluates IP restrictions early in the request lifecycle.
• Requests from disallowed IP addresses can be rejected before normal authentication and quota processing.
• It helps prevent unnecessary processing for requests that should not be accepted.

The policy can be attached elsewhere in the proxy flow if the use case requires it.

7. Real-World Example: Securing a Payment API

Imagine you are working on a payment-processing platform that exposes the following endpoint:

POST /payments

The security requirements are:

• Only trusted corporate IP addresses can access the endpoint.
• Only registered applications can call the API.
• Requests must include a valid OAuth 2.0 access token.
• Traffic must be controlled to protect the backend.

You can use multiple Apigee policies to meet these requirements:

1. Access Control: Restricts access based on IP addresses.
2. VerifyAPIKey: Validates the application's API key.
3. OAuthV2 VerifyAccessToken: Validates the access token and, when configured, its required scope.
4. Quota: Enforces a defined request allowance over a period.
5. SpikeArrest: Helps smooth traffic and protect the backend from sudden bursts.

The Access Control policy does not replace API-key validation or OAuth authentication. Instead, it provides an additional network-level restriction within the API proxy.

8. Can You Use a KVM with the Access Control Policy?

Yes. You can store IP addresses and mask values in an Apigee Key Value Map (KVM), retrieve them using the KeyValueMapOperations policy, and reference the resulting flow variables in the Access Control policy.

For example:

<AccessControl name="AC-BlockConfiguredIP">
    <IPRules noRuleMatchAction="ALLOW">
        <MatchRule action="DENY">
            <SourceAddress mask="{kvm.mask.value}">
                {kvm.ip.value}
            </SourceAddress>
        </MatchRule>
    </IPRules>
</AccessControl>

In this example:

• kvm.ip.value contains the IP address.
• kvm.mask.value contains the mask.
• Both variables must be populated before the Access Control policy executes.

This approach can make IP restrictions easier to manage without changing the policy XML every time an IP address or mask needs updating.

For security-sensitive configurations, ensure that the source of these values is controlled and that invalid or missing values are handled safely.

9. Important Consideration: Client IP Address and Forwarded Headers

One common production challenge is identifying the actual client IP address.

Requests may pass through load balancers, reverse proxies, or NAT gateways. In such cases, the IP address visible to Apigee may differ from the original client's address.

Apigee can evaluate addresses from forwarding headers such as X-Forwarded-For, depending on the policy configuration and request path.

Security best practice: Do not blindly trust client-supplied forwarding headers. Ensure your network topology and trusted proxies are configured appropriately, and verify which IP address the policy actually evaluates.

Misidentifying the client IP can result in legitimate clients being blocked or unwanted clients being allowed.

10. Frequently Asked Apigee Interview Questions

Q1. What is the Access Control policy in Apigee?

It is a policy used to allow or deny API requests based on configured IP addresses or IP ranges.

Q2. What is noRuleMatchAction?

It defines the action taken when an IP address does not match any configured rule. Its valid values are ALLOW and DENY.

Q3. What happens when an IP address matches a DENY rule?

The policy raises a fault, and the request does not continue through the normal proxy flow. The final HTTP status and response body depend on fault handling configuration.

Q4. Can the Access Control policy allow multiple IP addresses?

Yes. You can configure multiple SourceAddress elements within a matching rule to cover multiple IP addresses or ranges.

Q5. Does the Access Control policy replace VerifyAPIKey?

No. Access Control restricts requests based on IP addresses, whereas VerifyAPIKey validates an API key associated with an application.

Q6. Does the Access Control policy replace OAuth 2.0?

No. It does not validate OAuth access tokens. It can be combined with OAuth policies to enforce both IP-based restrictions and token-based authentication.

Q7. Can you use Access Control with Apigee X?

Yes. The Access Control policy is supported in Apigee and Apigee hybrid. Always verify the applicable documentation for your specific deployment.

Q8. What is the difference between an allowlist and a denylist?

An allowlist permits explicitly trusted IP addresses or ranges. A denylist blocks specified IP addresses or ranges while allowing other addresses according to the configured rules.

11. Access Control Policy vs. VerifyAPIKey

Feature	Access Control	VerifyAPIKey
Primary purpose	IP-based access restrictions	API-key validation
Checks	Client IP address or configured IP source	API key
Identifies the application	Not by itself	Yes, through the registered key
Can be combined with OAuth	Yes	Yes

Conclusion

The Access Control policy is an important component of API security in Apigee. It allows developers to control API access using IP addresses and ranges through ALLOW and DENY rules.

For interviews, remember these key points:

• Access Control is used for IP-based restrictions.
• noRuleMatchAction defines what happens when no rule matches.
• The mask attribute determines the IP range.
• The policy is commonly placed in the ProxyEndpoint request PreFlow.
• It complements API-key validation, OAuth 2.0, and traffic-management policies rather than replacing them.

Understanding these concepts, along with the XML examples and client-IP considerations, will help you explain the Access Control policy confidently in an Apigee Developer interview.

Official documentation: Apigee Access Control policy